parmelee@wayback.cs.cornell.edu (Larry Parmelee) (01/08/90)
Excuse me for jumping in in the middle of things... In article <9001060126.AA11937@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: > > [...], I'd argue the gateway should have sent stuff > out as user%hidden@host, [...] . > > Craig I still think the writers of the Host Requirements RFC screwed up when they encouraged the "%-hack" over Route-Addresses. Has anything been published yet to officially state what the "%-hack" is? In particular, how does it relate to the other mail address operators "@" and "!"? How do you interpret "foo!bar%baz@blef"? RFC 976 defines how to translate back and forth between uucpish pure "!" addresses and internet address form, including route-addresses; and also defines the interpretation of "hybrid" forms containing both "@" and "!". It recommends avoiding "%". I fully agree: because the "%-hack" is not defined, hosts can handle it however they wish, and what they do may not be what you intended. Until something/someone officially defines the "%-hack", I will strongly resist using it, prefering route-addresses as the only un-ambiguous alternative. Unfortunately, the Host Requirements RFC will undoubtedly eventually cause trouble with this approach. Hopefully someone will come up with a unified definition of "%", "!", and "@" before things get too bad. -Larry Parmelee parmelee@cs.cornell.edu
braden@VENERA.ISI.EDU (01/09/90)
I still think the writers of the Host Requirements RFC screwed up when they encouraged the "%-hack" over Route-Addresses. Has anything been published yet to officially state what the "%-hack" is? In particular, how does it relate to the other mail address operators "@" and "!"? How do you interpret "foo!bar%baz@blef"? Please see the DISCUSSION part of Section 5.2.16 for an answer to this question. Bob Braden
cjsv@cs.adfa.oz.au (Christopher J S Vance) (01/09/90)
In article <35783@cornell.UUCP> parmelee@cs.cornell.edu (Larry Parmelee) writes: > Excuse me for jumping in in the middle of things... Me too? > Until something/someone officially defines the "%-hack", I will > strongly resist using it, prefering route-addresses as the only > un-ambiguous alternative. Unfortunately, the Host Requirements RFC > will undoubtedly eventually cause trouble with this approach. Hopefully > someone will come up with a unified definition of "%", "!", and "@" > before things get too bad. But it seems to me that you're only allowed to use route-addresses when all the hosts are registered with the NIC. Since they won't want to register every PC in the world, or even every mainframe on lots of networks which are not on the Internet, it seems you've got to break some rules to make things work. Personally, I think source-routes are nasty since they aren't pure left-to-right or right-to-left. But then I've never had to use them....
randall@uvaarpa.virginia.edu (Randall Atkinson) (01/10/90)
In article <836@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) writes: >But it seems to me that you're only allowed to use route-addresses when all >the hosts are registered with the NIC. Since they won't want to register >every PC in the world, or even every mainframe on lots of networks which are >not on the Internet, it seems you've got to break some rules to make things >work. Personally, I think source-routes are nasty since they aren't pure >left-to-right or right-to-left. But then I've never had to use them.... Actually, any node on the GE internal DECnet can be reached as node.DNET.GE.COM and there are no A records or in fact IP addresses for virtually all of the machines on that network. The RFC states that you are only allowed to use route-addresses with fully-qualified domain names in registered domains. GE's solution is fairly general and requires only a single MX record pointing *.DNET.GE.COM to a relay-host directly on the Internet. There are special cases that won't be covered, but this solution DOES handle the case of PCs on an internal network or any other such situation. The main case it won't (legally) handle is gatewaying to a network whose machines aren't under your theoretical administrative control. NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and I heartily approve of NASA's solution even though many nodes on that DECnet aren't owned or operated by NASA. The %-hack is widely overused and I'd like to see it used only when really necessary because it causes a lot of mail delivery problems. Ran
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (01/10/90)
>There are special cases that won't be covered, but this solution DOES >handle the case of PCs on an internal network or any other such situation. >The main case it won't (legally) handle is gatewaying to a network whose >machines aren't under your theoretical administrative control. >NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and >I heartily approve of NASA's solution even though many nodes on that >DECnet aren't owned or operated by NASA. This was/is a hack to enable reasonable functionality for mail relay to SPAN systems. It's not the right thing to do, but was expedient. The reason it's not right is that SPAN is not run by a single organizational unit (to use OSIspeak). The right way of skinning the cat would be to use individual MX records for machines at sites to map them into the local domain name space of the facility. For example, a DECNET node named SAT located at Ames, should not be addressed at user@sat.span.nasa.gov, but user @sat.arc.nasa.gov. This way, if the machine happens to speak IP (as it does), it could be considered a CNAME for it's full hostname, or an MX record could be used that points mail at an Ames local MAIL-11 relay system. If you use an MX record for *.span.nasa.gov, then all of it has to go through a single mail relay. You can get into the case of a JPL host sending internet mail to a JPL DECNET host via a relay at ARC or GSFC. If the JPL DECNET host had an MX record in the jpl.nasa.gov subdomain, a more optimal path could be taken. I think JPL actually does this, but the point is the obvious. The problem with this is that it means having all the individual system administrators interacting with all the site domain managers and whoever runs a relay at the site to fix things so they work right, which is harder than fixing it once using the span.nasa.gov pseudodomain. The same reason holds why a .BIT.NET or .CS.NET (or maybe .ONE.NET these days I guess) is a bad idea. Those systems really should reside in a site's name local namespace. If people obeyed these rules, Internet mail delivery would be much more transparent, and the fact that a particular network (SPAN,BITNET,CSNET, etc...) was being used as transport would be hidden from the users. And that makes life easier on them. Why should 3 different forms of different address specifications be used to talk to 3 machines connected in different ways at one site? Thanks, Milo PS All the usual disclaimers about the government not being responsible for anything I say apply of course...