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
matt@oddjob.uchicago.edu (Matt Crawford) (12/13/88)
Paul A Vixie sez: ) 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, ... I stand by my practice of jumping ahead when 'c' is fully qualified. Since I am at an internet site, my route to 'c' ought to be almost as up-to-date as humanly possible, unless the authority for c's domain Just Doesn't Care. And if the authority Doesn't Care, I don't feel guilty for Not Helping. (Also, I think that jumping to a fully-qualified 'c' does More Good Than Harm - i.e., it wins in more cases than it loses.) Matt Crawford
vixie@decwrl.dec.com (Paul A Vixie) (12/13/88)
I understand that various people have me in their KILL files because they don't care about rerouting. May their mail be rerouted to Italy because of their intentional ignorance and lack of participation :-(. [Crawford] # I stand by my practice of jumping ahead when 'c' is fully qualified. # Since I am at an internet site, my route to 'c' ought to be almost as # up-to-date as humanly possible, Unless it's an MX that's on the other side of some slow IP or frequently congested IP links or mailbridges, in which case the UUCP path you were given could be better. # (Also, I think that jumping to a fully-qualified 'c' does More Good Than # Harm - i.e., it wins in more cases than it loses.) But when it loses, it loses BIG. And the wins? The problem peeking or any kind of RE-routing is designed to solve can be better solved at the source -- write good source routers and teach news software, news admins, and news users how to use them. This is mostly done already, and if anyone has effort for solving problems caused by replies which travel over reversed news paths, I humbly suggest that they spend that effort making the problem go away rather than making room for unpredictable lossage further downstream. And for the record, it isn't clear to me that it _is_ a win more often than not. -- 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
romkey@asylum.sf.ca.us (John Romkey) (12/13/88)
In article <1144@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >Paul A Vixie sez: >) 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'". >I stand by my practice of jumping ahead when 'c' is fully qualified. >Since I am at an internet site, my route to 'c' ought to be almost as >up-to-date as humanly possible, unless the authority for c's domain >Just Doesn't Care. Internet-centrism. (Take that from an Internet-hacker). It may not be an Internet route, and you won't be able to tell. If 'b' is a mail gateway and 'c' is a name in another namespace hidden on the other side of the mail gateway, jumping ahead to resolve 'c' and ignore 'b' will lose. 'c' can look like anything it wants, it might resemble a fully qualified domain name or be a real domain from Andromeda. -- - john romkey romkey@asylum.uucp romkey@xx.lcs.mit.edu romkey@asylum.sf.ca.us Find the cost of freedom, buried in the ground Mother Earth will swallow you, lay your body down.