Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!mordor!lll-tis!ptsfa!vixie!paul From: paul@vixie.UUCP (Paul Vixie Esq) Newsgroups: comp.mail.misc Subject: address writing by gateways (was: NO NO NO NO NO) Message-ID: <684@vixie.UUCP> Date: Sun, 28-Jun-87 20:28:04 EDT Article-I.D.: vixie.684 Posted: Sun Jun 28 20:28:04 1987 Date-Received: Sun, 28-Jun-87 23:45:21 EDT References: <654@vixie.UUCP> <8120004@hpfclp.HP.COM> Reply-To: paul@vixie.UUCP (Paul Vixie Esq) Organization: Vixie Enterprises, San Francisco Lines: 104 In article <8120004@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes: >All these [RFC{822,920,976}] >standards explicitly require "@" precedence, and indeed, the whole point of >SMAIL was to make the UUCP world RFC compliant. This was my observation; I want to quote it here to help drill in two points: 1- every known Internet RFC that mentions it at all requires @-precedence; 2- SMAIL is compliant with the RFC's -- that's its reason for existing. >[Paul Vixie writes:] >> There is also no need rewrite the envelope unless the destination CANNOT >> deal with it, so only gateways should have to do it, right? And a UUCP to >> RFC822 gateway can always produce a <> route, and a RFC822 to UUCP gateway >> can always produce a ! route, right? > >I wish it were that simple. Obviously, this is what you would have in an >ideal world (only gateways worry about address translation), but it isn't >that simple, unfortunately. > >First of all, RFC-822 source routes can only be >used if each element is a registered domain (there are subtle points in the >wording of RFC-822 which mandate this). This means, unregistered UUCP hosts >cannot be put in source routes. Feh. I hadn't read this anywhere, but it sounds like a nasty. I gateway between UUCP and SMTP internally all the time, and I certainly don't check any list to see if the site is registered before writing it into an RFC822 route-addr. Perhaps this restriction only applies to real live Internet mail, and is a political thing meant to keep DDN from being used as a carrier for non-DDN-destined messages? I know that that political restriction exists (though it is widely, er, "bent" :-)); is this just another form of it? I expect that a lot of sites use RFC822-style route-addrs at some point in their internal networks without checking to see that each element of the route is a registered domain. Thanks for bringing this up, John. Now, can we discuss it some? >One more problem is how to handle "%." Since >it isn't specified by any standard, it must remain untouched, which might work >O.K. if the precedence everywhere were always "@", "!", any other characters >(including "%"), but some sites don't know anything about "!" and so interpret >"%" as higher precedence than "!." Gag me with a hetrogeneous network. This IS a problem -- % is widely used, but undocumented. This is a major hole in the Internet mail standards, and it's what lets SMTP be ambiguous about what it will do with an address. Still, the % operator is not absolutely neccessary in a pure RFC822 or UUCP world -- there is a way in each standard to specify a route unambiguously. Therefore a gateway from a net that had local usage of "%" could do whatever the local users expect when parsing the "%"'s, and put out either a !-path or a route-addr when passing the message into the RFC-compliant network. If there are networks which have members that put out ambiguous addresses, the members should be encouraged not to do that. Internet and UUCPnet differ somewhat in this respect -- UUCPnet is a free-for-all. But even in UUCPland, an address/route that contains only words, dots, and bangs will be very hard to misunderstand. A gateway (or even a single site) that wants to be able to accept addresses with @'s or %'s in it can rewrite according to local customs when putting the message out onto the UUCPnet. Or the Internet. >When you translate from "!" addresses to >RFC style addresses, how do know whether to use a source route or a "%?" I'd say always use a source route. Is this unfeasable? Are there Internet sites (here I mean DDN-only sites) that don't grok source-routes, and need %-routes? This sounds like the point to push, if so. >[Paul Vixie again:] >> It is much more likely that we can get fixed gateways than asking all >> sites in the universe to perpetuate the confusion between a route and an >> address. What Rahul is asking is a new way to write routes, and we already >> have perfectly unambiguous ways to do that. > >It certainly would be easier if all we needed is to get only gateways fixed, >but I don't know how to hide all this from the non-gateway machines. If we take "gateway" to mean a mail transport program on some host that generates messages into a network (UUCP or SMTP, in this discussion) where the source of the messages is either a local user or a non-public (i.e., internal) network, then the "gateway" is responsible for rewriting the source and destination addresses into something acceptable to the public network (UUCP or SMTP). The major public networks, UUCP and SMTP, have (as far as I know) unabiguous syntaxes for full source routes -- either UUCP: host1!host2!host3!finalhost!user or SMTP: <@host1,@host2,@host3:user@finalhost> Addresses containing operators or combinations of operators which have no standard meaning in the public network (like %, or combinations of %/@, or %/!, or !/@) can rewrite according to local (host or internal network) custom. Okay, pour it on: what am I missing? >John Diamant >TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant >Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM >Fort Collins, CO -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013