mike@turing.unm.edu (Michael I. Bushnell) (12/08/88)
Unmvax.unm.edu currently routes all mail for foo@baz.UUCP to uunet.uu.net, and assumes that uunet can find host baz. We are, however, on USEnet, and it would be good if we routed UUCP mail ourselves. I understand that uunet supports a rather large mail load, and we would like to do our part to diminish that. The problem is that we like sendmail, and we like Internet. We want to route *only* mail destined for *.UUCP with pathalias. Does anyone know of a convenient way to integrate them? Pathalias produces a nice voluminous output file, but we would like to avoid having to use smail, and we would like to route our outgoing UUCP mail. Any suggestions? -- Michael I. Bushnell \ This above all; to thine own self be true HASA - "A" division GIG! \ And it must follow, as the night the day, mike@turing.unm.edu /\ Thou canst not be false to any man. Numquam Gloria Deo / \ Farewell: my blessing season this in thee!
deke@socrates.ee.rochester.edu (Dikran Kassabian) (12/08/88)
In article <2189@unmvax.unm.edu> mike@turing.unm.edu writes: > >[....] > >The problem is that we like sendmail, and we like Internet. We want >to route *only* mail destined for *.UUCP with pathalias. You don't specify much about your mail configuration and the transport mechanisms you have available to you. I hope I am interpreting your question correctly. My short answer is: Add another "mailer" definition to your sendmail.cf, and then just recognize user@site.UUCP and resolve it to that mailer. >Does anyone know of a convenient way to integrate them? Pathalias >produces a nice voluminous output file, but we would like to avoid >having to use smail, and we would like to route our outgoing UUCP >mail. Any suggestions? Why avoid using smail? We have a machine known as "ee.rochester.edu" on both the Internet and in the UUCP maps. We let this machine handle all the mail from within our domain in the following way. Any address with the right-hand side of an '@' that we can resolve gets mailed via SMTP. Mail of the form user@site.UUCP gets "smail'ed". We also recognize other forms such as user@site.UUNET and user@site.BITNET and others, in which case we see that the mail gets sent to the appropriate gateway for further handling. This is an extreme oversimplification of what is really happening, but it accomplishes exactly what we want. Might be what you want, too. Good luck, ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
emv@a.cc.umich.edu (Ed Vielmetti) (12/09/88)
>In article <2189@unmvax.unm.edu> mike@turing.unm.edu writes: >>The problem is that we like sendmail, and we like Internet. We want >>to route *only* mail destined for *.UUCP with pathalias. A couple of alternatives come to mind. You could bring up smail, and pass off all of the uucp stuff to it. It's a full-blown mailer, so there's a fair amount of overhead involved in learning up, but they say it's pretty reasonable. You could bring up uumail, a small mailer that only handles rewriting of uucp mail. It's more or less a drop-in replacement for your uux mailer, and it does a reasonable job of adding pathalias lookups to sendmail. The lookups happen after everything is resolved, so your flexibility is limited. You could bring up the IDA patch kit to sendmail, which provides for direct pathalias lookups within the sendmail.cf. Several of my neighbors run this, and they seem to like it. You could bring up the 'uucpdomain' modifications to sendmail that uunet runs, which provide a similar direct lookup facility. I can't think of any other alternatives, if someone could come forward with a different way of working this out (short of dropping sendmail entirely and running upas, peter) I'd like to hear about it. BTW, mailrus, umix, and sharkey all run uumail. It handles well-formed addresses quite nicely. --Ed
mike@turing.unm.edu (Michael I. Bushnell) (12/10/88)
Well, we now do UUCP routing. Here were some of the suggestions I got: 1: Run smail. 2: Run smail. 3: Run smail. 4: Run uumail. 5: Use the IDA enhancements. 6: Use the same enhancements that UUNET does (similar to the ida ones). Since (1), (2), and (3) are vastly overblown solutions to a very simple problem, and (5) and (6) are a pain to integrate easily to new releases of sendmail, and since Win Strickland (win@gatech.edu) was very willing to assist me in getting what I needed, I chose (4). Here's what we do. We take mail addressed like a!b and turn it into b@a.uucp. All *.uucp mail which is not to a neighbor of ours or destined for our domain (we are the domain gateway in the maps) is sent to uumail for routing. This allows us to handle two cases of passive routing: where we are given only an address and no path at all, and where the next hop of the path is unreacheable. In the second case, we are justified in rerouting since the original path was invalid. Thanks to everyone for all their help. -- Michael I. Bushnell \ This above all; to thine own self be true HASA - "A" division GIG! \ And it must follow, as the night the day, mike@turing.unm.edu /\ Thou canst not be false to any man. Numquam Gloria Deo / \ Farewell: my blessing season this in thee!
vixie@decwrl.dec.com (Paul A Vixie) (12/10/88)
[ Followups to comp.mail.uucp ] [Bushnell] # This allows us to handle two cases of passive routing: where we are given # only an address and no path at all, and where the next hop of the path is # unreacheable. In the second case, we are justified in rerouting since the # original path was invalid. You are certainly justified in finding a route to the first host in the path (or the only host in an address) is not a direct neighbor. There is great controversy over the practice of peeking ahead, beyond the first host in the path, no matter what kicked your mailer into that mode. Canonically, this is usually put: "given a!b!c!user, go ahead and get to 'a' by any means available, but don't assume that your 'c' is the same as the 'c' known to 'b'". Details such as 'c' being a fully qualified domain are not really that interesting, since your route to that fully qualified domain may not be as good as the one that's being chosen, and you have no way of knowing that unless you monitor all the links as they go through their daily dance of the yo-yo. Forgive me, everyone, if this seems like I'm picking nits. The word "reroute" in the above-quoted text can be taken two ways. I support one way, and oppose the other. The difference seems very important to me. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013