Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!hplabs!hpcea!hpfcdc!hpfclp!diamant From: diamant@hpfclp.HP.COM (John Diamant) Newsgroups: comp.mail.misc Subject: Re: address writing by gateways (was: NO NO NO NO NO) Message-ID: <8120005@hpfclp.HP.COM> Date: Wed, 1-Jul-87 01:38:26 EDT Article-I.D.: hpfclp.8120005 Posted: Wed Jul 1 01:38:26 1987 Date-Received: Fri, 10-Jul-87 00:41:25 EDT References: <684@vixie.UUCP> Organization: HP, Fort Collins, CO Lines: 151 > / hpfclp:comp.mail.misc / paul@vixie.UUCP (Paul Vixie Esq) / 6:28 pm Jun 28, 1987 / > In article <8120004@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes: > > 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. It is not a political restriction. It is to avoid having things that look like domains but can't be replied to because they aren't properly registered (in other words, machines won't know who they are or be able to look them up). Allow me to quote from RFC-822: route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference [...] 6.2.1. DOMAINS A name-domain is a set of registered (mail) names. A name- domain specification resolves to a subordinate name-domain specification or to a terminal domain-dependent string. Hence, domain specification is extensible, permitting any number of registration levels. Notice that the syntax specification refers to the word domain and that the definition of domain says "registered." This is pretty explicit. If it isn't registered, it isn't legal in a source route. > > Thanks for bringing this up, John. Now, can we discuss it some? Sure. > > 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. Yup! It is, however, compatible with the RFCs. The "%" is part of the local part, and thus subject to interpretation by the final destination only. That's what makes it lower precedence. > > 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. I'm not sure this is right. It depends what you mean by local user. The "%" has to be interpreted as part of the "local part" of the address, by the destination machine. In other words, with local-user%localhost@domain, the "%" must be interpreted by domain, not by the sender's machine. It sounds like you are advocating having the sender's machine attach an interpretation to "%," which is wrong, I think. > > 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. Again, I don't think you are allowed to apply local interpretation to "%" since only at the point where you are ready to interpret the local-part (on the final destination) can you break it apart. > > >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. Well, one of the main reasons for using "%" is for unregistered machines. Given what I said about source routes not allowing unregistered domains, this creates a bit of a dilema. Also, if a "%" came in and was translated to "!" and then left again, but was now as source route, then you've illegally applied an interpretation to it. I think there are many machines that don't handle source routes properly. However, that by itself is only an argument to get those machines fixed, not a reason to use "%." The reason "%" appears to be needed is to handle unregistered hosts. > > 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> If you are allowed to randomly switch back and forth between source routes and UUCP routes (when you switch transports, of course) and "%" aren't allowed, then I think this would work. But again, this requires that unregistered hosts be allowed in source routes. > > 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. See objection above. > > Okay, pour it on: what am I missing? I gave it a shot. What do you think now? This situation is deceptive. Scott McGregor (also of HP) and I tried to write an RFC to clarify this problem and we discovered the deeper we got, the more complicated the RFC got, and the worse the problem became. We did convince Mark Horton (author of RFC-976) the a real problem did exist with "%" and some ambiguities in RFC-976, but we never came up with a satisfactory additional RFC to resolve the issues (though we did write one that isn't satisfactory). The basic problem was that no matter how you looked at it, you needed to know too much about your next hop machine to know how it would interpret addresses (foo!bar%baz@foobar -- is the "%" interpreted before or after the "!"?). > > >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 John Diamant again -- see signature above!