generous@daitc.daitc.mil (Curtis Generous) (06/28/89)
More and more, I'm seeing UUCP mail going through my host of the format:
uucp1!uucp2!uucp3!domain.name!user
Since we have both Internet and UUCP connections, what's the best way to
handle this situtation if your host is capable of sending mail directly to
'domain.name'? Or should it be done?
We run sendmail with smail as a backend. I don't see how the '-R' option
to smail would help since the pathalias database doesn't know about
all non-UUCP domains.
{I}relevant Information:
Host: Pyramid 98x running OSx4.4 (4.2/3 BSD derivative)
Sendmail: Version 5.61 with IDA kit
Misc: bind 4.8
Thanks for any assistance.
--curtis
--
Curtis C. Generous
DTIC Special Projects Office (DTIC-SPO)
ARPA: generous@daitc.mil
UUCP: {uunet,vrdxhq}!daitc!generouskarl@giza.cis.ohio-state.edu (Karl Kleinpaste) (06/28/89)
generous@daitc.daitc.mil writes:
More and more, I'm seeing UUCP mail going through my host of the format:
uucp1!uucp2!uucp3!domain.name!user
Since we have both Internet and UUCP connections, what's the best way to
handle this situtation if your host is capable of sending mail directly to
'domain.name'? Or should it be done?
#
# Strip many-hop !-paths to the right-most domain spec.
#
R$*.$*!$*@$* $1.$2!$3 lose @-portion
R$*!$*.$*!$* $2.$3!$4 strip excess left-hand
R$*.$*!$* $3@$1.$2 invert to @-formatmatt@oddjob.uchicago.edu (Matt Crawford) (06/28/89)
Curtis Generous poses a question very near and painful to my heart: ) More and more, I'm seeing UUCP mail going through my host of the format: ) uucp1!uucp2!uucp3!domain.name!user ) Since we have both Internet and UUCP connections, what's the best way to ) handle this situtation if your host is capable of sending mail directly to ) 'domain.name'? Or should it be done? I used to take the position that bang-paths should always by short- circuited to the rightmost fully-qualified domain name, and I set my sendmail to do this by placing two rules in the "machine dependent part of ruleset zero" area. When the rules are invoked, a bang-path address "x!stuff" will be in the form "stuff<@x.UUCP>". I think the rules looked something like: R$+.$=P!$+<@$-.UUCP> $:<$1.$2!$3> if found, drop first hop R<$*!$+.$=P!$+> <$2.$3!$4> look further R<$+.$=P!$+> $:$3<@$1.$2> use internet form Where class P consists of the words ARPA EDU COM GOV MIL NET ORG and the top-level country domains AU, AT, BE, etc. However, there was one bad side-effect. There turn out to be some UUCP-only sites which have registered domain names and forwarders, but whose forwarders DO NOT talk directly to the registered site. Instead they route mail to the registered site with pathalias, sometimes passing through my site. So mail for joe-blow@registered.site.com would go to the MX-designated forwarder forwarding.host.edu which would pass it on by UUCP (often UUCP-over-TCP for some hops) to oddjob!more!names!registered.site.com!joe-blow Oddjob got that, skipped ahead to registered.site.com, looked up the MX record, and closed a mail loop. I think that it is "bad and wrong" for forwarding.host.edu not to take the mail out of the internet once and for all, but it was not in my power to enforce this opinion. A next-best cure would have been for the forwarder to use registered.site.com's 1-component UUCP name instead of its internet name in the generated bang path. But in the absence of such cooperation, what I did was to short-circuit only if the first hop was not a known UUCP neighbor. This reduces the efficiency gains but keeps me on good terms with my UUCP/TCP neighbor, forwarding.host.edu. The rules I use now are # if host is not in the class Q (class of valid uucp hosts), then # look for a special case ... R$*<@$*$~Q.UUCP>$* $:$>11$1<@$2$3.UUCP>$4 # ... then look for an embedded !d.om.ain! (would be easier in S3) ... R$+.$=P!$+<@$~Q.UUCP> $:<$1.$2!$3> if found, drop first hop R<$*!$+.$=P!$+> <$2.$3!$4> look further R<$+.$=P!$+> $:$3<@$1.$2> use internet form # ... finally, assume it goes by SMTP R$*<@$*$~Q.UUCP>$* $1<@$[$2$3$]>$4 Class Q consists of my UUCP neighbors and ruleset 11 lets a few other hosts on the internet appear to be UUCP neighbors. ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu
steve@polyslo.CalPoly.EDU (Steve DeJarnett) (06/29/89)
In article <562@daitc.daitc.mil> generous@daitc.daitc.mil (Curtis Generous) writes: >More and more, I'm seeing UUCP mail going through my host of the format: > > uucp1!uucp2!uucp3!domain.name!user > >Since we have both Internet and UUCP connections, what's the best way to >handle this situtation if your host is capable of sending mail directly to >'domain.name'? Or should it be done? As it's been told to me (and from what I've read), it's always safe to take the rightmost fully-qualified domain name and dump everything to the left of it (in the bang-path sense). Thus, in your sendmail.cf, you can put in a rule that strips down to the rightmost FQDN when the address is composed of UUCP bang-paths. Thus, the above could be rewritten as: user@domain.name Try the following (no guarantees, your mileage may vary, etc.) to do it: # Transmorgrify R$+!$+.$D!$+ $2.$D!$3 stuff!h.d!u => h.d!u R$+.$D!$+ $@$2<@$1.$D> h.d!u => u@h.d >--curtis ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
woods@ncar.ucar.edu (Greg Woods) (06/29/89)
In article <4140@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >I think that it is "bad and wrong" for forwarding.host.edu not to take >the mail out of the internet once and for all, but it was not in my >power to enforce this opinion. As one of the forwarding.host.edu's that Matt refers to, I must point out that it is not always POSSIBLE to do as he suggests. Many domains have MORE THAN ONE connect point to the Internet, and are not fully connected within themselves. It is a lot of work to ask an Internet host to maintain a whole database of MX records for a domain which is not itself directly on the Internet. I do MX forwarding and name service for non-Internet domains, but only if they have one host I can UUCP everything to, so that I only need *1* MX record for their domain which never changes. A domain like fidonet.org has DOZENS of connect points on the Internet, but they themselves don't have access to the Internet so they must depend on some friendly site to maintain name service for them. These friendly sites would be a lot less friendly if they had to maintain dozens of ever-changing MX records. As it is now, all the Fidonet folks have to do is get their gateway sites to post new UUCP map entries when something changes. This way, the people benefitting are the ones doing the work. >A next-best cure would have been for the >forwarder to use registered.site.com's 1-component UUCP name instead of >its internet name in the generated bang path. This doesn't work either, because one connect point for a domain may handle multiple subdomains. Without dots in the bang path address there is no way to specify this. >But in the absence of such cooperation, what I did was to short-circuit >only if the first hop was not a known UUCP neighbor. THANKS! I guess I can mark oddjob as undead now? I see nothing wrong with doing this, because there would be no way for you to deliver the message otherwise. --Greg
win@gatech.edu (Win Strickland Jr) (06/29/89)
In article <3570@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: #In article <4140@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: ##... what I did was to short-circuit only if the first hop was not a ##known UUCP neighbor. # # THANKS! I guess I can mark oddjob as undead now? I see nothing wrong with #doing this, because there would be no way for you to deliver the message #otherwise. This, in fact, has been the policy at gatech for some time. Without starting a religious debate, I'd be interested in any arguments against this policy (e-mail please). -- Win Strickland Jr School of ICS, Georgia Tech, Atlanta GA 30332 Internet: win@gatech.edu root@gatech.edu postmaster@gatech.edu UUCP: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!win Phone: 404 894 3086 (msgs 404 894 3152)
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (06/29/89)
I've been spending some time reading RFCs today, looking for more complete references on what an MX host may do. I didn't find what I wanted (either for or against MX hosts doing such stuff); and this question seems to have left sendmail itself behind, being more of a general question of what MX hosts may do. So I've posted my confusion to comp.protocols.tcp-ip.domains - any interested folk might want to check in there. --Karl
pcg@aber-cs.UUCP (Piercarlo Grandi) (06/29/89)
In article <562@daitc.daitc.mil> generous@daitc.daitc.mil (Curtis Generous) writes:
More and more, I'm seeing UUCP mail going through my host of the format:
uucp1!uucp2!uucp3!domain.name!user
Since we have both Internet and UUCP connections, what's the best way to
handle this situtation if your host is capable of sending mail directly to
'domain.name'?
The best solution is to ensure that people generating such routes have up to
date maps, that show that you have direct internet links. Otherwise source
routes ought to be religiously observed. The *only* reasonable action on a
source route is to *add* to it, and *only* at its beginning.
Or should it be done?
NO! Leave those routes alone. If you try to short circuit, you will find that
a lot of domainized names are NOT on the internet, or there are good reasons
to use a UUCP channel to get at them, etc... Altering a source route for
such cases may well create loops.
Let's repeat for the zillionth time that "a.b.c" is a *name*, and does not
imply *anything* on the connectivity of "a.b.c" to any network, e.g. the
internet (as it should be; that is why top level domains that are network
names, e.g. bitnet or uucp, are very much frowned upon). Domainization is
only a scheme to generate reliably unique names, not to give routing hints;
these should be based on maps. And you should never try to second guess
somebody's else's maps...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpcg@aber-cs.UUCP (Piercarlo Grandi) (06/29/89)
In article <3570@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: In article <4140@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >But in the absence of such cooperation, what I did was to short-circuit >only if the first hop was not a known UUCP neighbor. THANKS! I guess I can mark oddjob as undead now? I see nothing wrong with doing this, because there would be no way for you to deliver the message otherwise. Actually you have more freedom than this; you can *always* add components to the *beginning* of a route, even if its first component is directly attached to you (e.g. if the direct link is slow or temporarily dead and the sender's maps have not been updated yet). On the other hand, every site should only add the minimum number of components to the beginning of a route. If everybody stuck to this rule, one could have a full spectrum between source routing and aggressive (dynamic) routing; if you want the former, just specify the full route, if you want the latter just specify the first hop (and rely on it and every other hop to keep specifying only the hop and target) and the target (in UUCP this, to be unambiguous, may need to be a relative name, i.e. a route... :->), if you want in between, specify a few hops between you and the target, and let them figure out the routes among themselves. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
lear@NET.BIO.NET (Eliot Lear) (06/30/89)
> Domainization is only a scheme to generate reliably unique names, not > to give routing hints; these should be based on maps. And you should > never try to second guess somebody's else's maps... I'm not sure who is missing the point... If a name is unique, then one should be able to short circuit to it, and then use routing information, as declared SOMEHOW. SOMEHOW can be one of two methods: o If one is not connected to the Internet, one can use the map data. o If one is connected to the Internet, there are a number of standards (rfc974,rfc103[4,5]) to determine what Internet host to deliver a message. I think what Greg Woods is doing is borderline dangerous because there are standards which call for a specific method to determine where to deliver a message based on a domainized name [RFC974]. My belief is that it is not safe to be a forwarder for a domain unless all parties between forwarder and forwardee are agreed on the method. If you want to forward for a site by using the map data, using a different name might not be a bad method (see an article from Charles Hedrick <Jun.28.17.21.55.1989.6042@geneva.rutgers.edu> on this and another method). Finally, if you are indeed forwarding to the appropriate fidonet gateways via map data, I would consider it desirable to derive separate zones/forwarders based on the map data, and advertise different MX forwarders based on that information. This would, coincidentally, eliminate the shortcircuiting problem. Of course, it would help if ncar was authoritative for fidonet.org... -- Eliot Lear [lear@net.bio.net]
mcb@ncis.tis.llnl.gov (Michael C. Berch) (06/30/89)
In article <1039@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > NO! Leave those routes alone. If you try to short circuit, you will find that > a lot of domainized names are NOT on the internet, or there are good reasons > to use a UUCP channel to get at them, etc... Altering a source route for > such cases may well create loops. > > Let's repeat for the zillionth time that "a.b.c" is a *name*, and does not > imply *anything* on the connectivity of "a.b.c" to any network, e.g. the > internet (as it should be; that is why top level domains that are network > names, e.g. bitnet or uucp, are very much frowned upon). Domainization is > only a scheme to generate reliably unique names, not to give routing hints; > these should be based on maps. And you should never try to second guess > somebody's else's maps... I beg to differ, and hold the following as tenets: 1. The Domain Name System, as implemented in the U.S. by the set of root name servers operated on behalf of DDN and NSFNet, and implemented in other countries via central naming authorities, has preempted the field of host naming and mail forwarding. Thus the "c" in "a.b.c" must be an approved top-level domain, and "b.c" must be a domain known to the root name servers. Otherwise the address is illegal and I do not feel any compunction about bouncing it. (Note to Mr. Grandi, this implies nothing about connectivity or routing.) 2. Fully-qualified domain names (FQDNs) shall predominate in any hybrid or mixed-mode address, including a source route. The legitimate forms of address are those implied by reading the appropriate Internet RFCs. Other forms of address, including UUCP bang paths, are obsolete, and are honored only as a matter of comity and backward compatibility by Internet hosts. 3. Source routes are not favored, since they make assumptions about connectivity outside the local domain of the sender, and may operate to increase costs for forwarding hosts and delay messages. To manage these costs and reduce delays, forwarding hosts should attempt to be maximally efficient in routing, including maximum use of the DNS MX/forwarder distributed database. I guess this qualifies as strong Domain Absolutism, but heck, I think it's the only way to get people to get rid of obsolete stuff and join the commmunity. -- Michael C. Berch mcb@tis.llnl.gov / uunet!tis.llnl.gov!mcb
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/01/89)
In article <Jun.29.16.07.11.1989.10968@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: > Domainization is only a scheme to generate reliably unique names, not > to give routing hints; these should be based on maps. And you should > never try to second guess somebody's else's maps... I'm not sure who is missing the point... If a name is unique, then one should be able to short circuit to it, And generate interesting mail loops... Again, names may be relative or absolute, and routing may be source or dynamic, but the two issues are TOTALLY unrelated. Relative names (a la UUCP net) may LOOK like routes, but they need not be; conversely absolute names don't imply anything about routing. and then use routing information, as declared SOMEHOW. SOMEHOW can be one of two methods: o If one is not connected to the Internet, one can use the map data. o If one is connected to the Internet, there are a number of standards (rfc974,rfc103[4,5]) to determine what Internet host to deliver a message. When you do anything other than prepend to a route, you are second guessing the original router, and to do that reliably you need to know that your maps are better (whether Internet or not). This is hard... At the very least it requires a distributed database update algorithm, and even the Internet one does fail occasionally. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/01/89)
In article <266@ncis.tis.llnl.gov> mcb@ncis.tis.llnl.gov (Michael C. Berch) writes: In article <1039@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: [ ... on names and routes and their differences ... ] I beg to differ, and hold the following as tenets: 1. The Domain Name System, as implemented in the U.S. by the set of root name servers operated on behalf of DDN and NSFNet, and implemented in other countries via central naming authorities, has preempted the field of host naming and mail forwarding. Thus the "c" in "a.b.c" must be an approved top-level domain, Agreed... (if you say "ought to" instead of "must") and "b.c" must be a domain known to the root name servers. Otherwise the address is illegal and I do not feel any compunction about bouncing it. Hear hear. Since when the British NRS is part of the internet domain server scheme (they even use a different ordering for domains! :->)? There are loads of networks that use approved standardized host/domain names that are not registered in the *Internet* domain servers. You want to dump all mail from/to Germany or Italy? What about Japan? (Note to Mr. Grandi, this implies nothing about connectivity or routing.) 2. Fully-qualified domain names (FQDNs) shall predominate in any hybrid or mixed-mode address, including a source route. Agreed... The legitimate forms of address are those implied by reading the appropriate Internet RFCs. If only... :->. But the British NRS and its coloured books do exist, and hold sway in the 51st state. And similar things in other countries. Other forms of address, including UUCP bang paths, are obsolete, and are honored only as a matter of comity and backward compatibility by Internet hosts. Are honored because a lot of people use them, and you don't want to cut the Internet off them. Irrespective of the relative merits of the two schemes. 3. Source routes are not favored, since they make assumptions about connectivity outside the local domain of the sender, But dynamic routing, *except* when limited to prepending, does exactly the same, and in addition tries to second guess the sender's routing maps. I guess this qualifies as strong Domain Absolutism, but heck, I think it's the only way to get people to get rid of obsolete stuff and join the commmunity. Well, this is strong *US Govt. Darpa Internet* Domain Absolutism. As such it has its merits; central administration and adherence to mandated standards clearly makes life much more orderly. Too bad that a lot of people cannot or don't want to buy into that. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
news@amms4.UUCP (news administration) (07/06/89)
In article <1047@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <Jun.29.16.07.11.1989.10968@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: > > > Domainization is only a scheme to generate reliably unique names, not > > to give routing hints; these should be based on maps. And you should > > never try to second guess somebody's else's maps... > > I'm not sure who is missing the point... > > If a name is unique, then one should be able to short circuit to it, > >And generate interesting mail loops... Again, names may be relative or >absolute, and routing may be source or dynamic, but the two issues are >TOTALLY unrelated. Relative names (a la UUCP net) may LOOK like routes, but >they need not be; conversely absolute names don't imply anything about >routing. Ok - here's my $.02 worth. It seems to me that the UUCP maps, when viewed from 'above', constitute a network (a la graph theory), and the Domain name system is a tree. A string of connected nodes in a network constitutes a path from one to the other. A string of nodes in a tree simply constitutes a unique name for that leaf node. The domain name tree says absolutely NOTHING about which machines talk to which other machines. It just says that a message destined for a machine with the name A.B.C.D can be delivered if it can be given to a machine that knows all of the .C. nodes that hang off of the .D qualifier. It seems to me that trying to short-circuit a !path is a bad thing, unless there is a way to guarantee that all the names in the path are unique. Why? Well, since there is no _guarantee_ that all names in the maps are unique, you just might pick _different_ machine foo than the one targeted by the specified path. Also, _your_ list of just who talks to whom could very easily be older than the connectivity data used by the originator of the message. The path A!B!C!D!E just might be the only way from A to E now that B and E no longer talk to each other. If every name in the maps was a fully qualified domain name, there would be no problem. The machine foo.bar.com would be totally different from the machine foo.bar.edu or foo.bar.mil, etc. Unfortunately, not all sites have FQDN's (including me :-). If the day ever arrives when this state of affairs does exist, then short-circuiting !paths would be ok - on the other hand, it would no longer be necessary :-). Anyway, that's how I see it - any comments? -- Harry | reserved for | something really Internet: hjg@amms4.UUCP (we're working on registering)| clever - any UUCP: {jyacc, qtny, rna, bklyncis}!amms4!hjg | suggestions?
exspes@gdr.bath.ac.uk (P E Smee) (07/07/89)
Short-circuiting also causes problems if there are multiple domains involved in the path. For example, people who try to mail me on JANET from UUCP or ARPA who follow the addresses I send them can get through. If they try being clever because they know a shorter path to a gateway, they're likely not to get through, because I am only authorised to *receive* mail which comes in via particular gateways. So, it's an even more terrible thing to do if several domains are involved.