andrew@stl.stc.co.uk (Andrew Macpherson) (07/14/88)
This SMM:07 etc is not something that is generally known, however: You have brought up a nasty. In fact you are highlighting two of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. It remains around for historical compatibility (RFC7?? --- read the first page of 822 if you really want to know which). Having got that off my chest, here is the associated nasty: mcvax uses it as a 'local-part' operator, and hands on addresses of the form a!b!u%l, which any Internetted (and probably any JANET) host will treat as send to 'l' for uucp forwarding. UK1.? will resolve it as @l,@a:u@b (using 822 legal representation), on the assumption that the % constitutes a mal-formed domain address. This is not usually a problem but occasionally we recieve US mail which has hopped to the arpanet and been strangely delt with... Now the other point... Mixed addresses. If you live in the uucp world only you have no trouble. If in 822 land likewise. I understand the JNETters allow % as a source-routing so they also have a consistent rule-set. All 3 have a route specification method, therefore there is neither need nor justification for mixed-mode addressing. UK1.? will attempt to gateway on the basis of rules reasonable to a host on a network, from the bits of this SMM doc quoted I assume the suggested rules are for use in uucp-land, and seem reasonable IN THAT CONTEXT. but the major caveat must be that UNDER NO CIRCUMSTANCES OTHER THAN MAINTAINING YOUR NEIGHBOURS MAIL ROUTER CAN YOU ASSUME ANYTHING WHATSOEVER ABOUT THE PRIORITY HE WILL PLACE ON THE VARIOUS SYMBOLS. The only safe and reasonable course to take is to provide the destination address in the format required by the network you are using. Now if only the whole world would get it's act together and magically supply domain based mailers to everyone... -- Andrew Macpherson andrew@stl.stc.co.uk - or - ...!mcvax!ukc!stl!andrew "It is always a great mistake to treat the individual on the chance that he may become a crowd" -- Mr Justice Codd: (A.P.Herbert)
rick@seismo.CSS.GOV (Rick Adams) (07/19/88)
> You have brought up a nasty. In fact you are highlighting two > of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. > It remains around for historical compatibility (RFC7?? --- read the > first page of 822 if you really want to know which). Nonsense. It is perfectly legal under RFC822 (look at the grammar). The fact that you are mucking with the LOCAL-PART, which you are supposed to leave totally alone, is the cause of the problem. Anyone who gives % precedence over ! should fix their mailer. % is NOT a synonym for @. It is a valid part of the local-part of the address and should not be interpreted my any site save the destination machine. --rick
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/19/88)
> You have brought up a nasty. In fact you are highlighting two > of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. > It remains around for historical compatibility (RFC7?? --- read the > first page of 822 if you really want to know which). It is also not illegal RFC822. It is legal as part of the local-part, but can only be interpreted by the destination machine. It would probably be wrong for any gateway to interpret it in that light. > Having got that off my chest, here is the associated nasty: mcvax > uses it as a 'local-part' operator, and hands on addresses of the form > a!b!u%l, which any Internetted (and probably any JANET) host will treat > as send to 'l' for uucp forwarding. UK1.? will resolve it as > @l,@a:u@b (using 822 legal representation), on the assumption that > the % constitutes a mal-formed domain address. Sorry, that's not more legal (RFC822 explicitly states that only registered domain addresses may be listed in the components of a source route -- presumably the hosts in your example are not registed domain addresses). > UNDER NO CIRCUMSTANCES OTHER THAN MAINTAINING YOUR NEIGHBOURS MAIL > ROUTER CAN YOU ASSUME ANYTHING WHATSOEVER ABOUT THE PRIORITY HE WILL > PLACE ON THE VARIOUS SYMBOLS. The only safe and reasonable course > to take is to provide the destination address in the format required > by the network you are using. That's not as safe or reasonable as you might think. It isn't always possible to convert to the local routing format given the restrictions in RFC822 (source routes only valid for registered domains, "%" only interpretable in local part, not real routing character). What happens when you take a "!" route and try to convert it to the 822 world -- do you use "%" or source routing -- both have problems? > Now if only the whole world would get it's act together and magically > supply domain based mailers to everyone... Yes, this would be nice. Then we have to get you guys on JANET to use the same ordering for your domains as everyone else. I don't think one ordering is inherently better than any other, but, frankly, you're outnumbered, and "standard is better than better." John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
blarson@skat.usc.edu (Bob Larson) (07/19/88)
In article <44378@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: [quoting from another article]: >> Firstly '%' as an address character. IT IS NOT LEGAL RFC822. >Nonsense. It is perfectly legal under RFC822 (look at the grammar). >The fact that you are mucking with the LOCAL-PART, which you are supposed >to leave totally alone, is the cause of the problem. >% is NOT a synonym for @. It is a valid part of the local-part >of the address and should not be interpreted my [by?] any site save >the destination machine. Right so far. >Anyone who gives % precedence over ! should fix their mailer. Both % and ! are legal in the local-part acording to rfc822. Therefore, with an rfc822 conforming mailer I can do anything I want with addresses with my machine name to the right of the @ . There are two separate conventions about ! and % that have no relitive priority. (Neither is a documented Internet standard.) [The only mailer I have written handles the % routing hack (after first checking for a local user with a % in their name) but has no special treatment of !. The users have enough trouble with arpanet and bitnet mail without the oddities of uucp mail. Fixing it to understand rfc822 routing is a higher priority. Even in the mail groups rfc822 routing is frequently misundersood: the angle brackets are not optional in an rfc822 route.] Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
vixie@palo-alto.DEC.COM (Paul Vixie) (07/19/88)
(Andrew Macpherson writes:) # You have brought up a nasty. In fact you are highlighting two # of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. # It remains around for historical compatibility (RFC7?? --- read the # first page of 822 if you really want to know which). (Rick Adams writes:) # The fact that you are mucking with the LOCAL-PART, which you are supposed # to leave totally alone, is the cause of the problem. (which I agree with, but then Rick says:) # Anyone who gives % precedence over ! should fix their mailer. # % is NOT a synonym for @. It is a valid part of the local-part # of the address and should not be interpreted my any site save # the destination machine. I agree that % is not a defined pseudonym for @ and that anyone who tries to say it is can be ignored. It is, indeed, part of the "local part", and there is no written standard that says it has to be processed one way or another. But, um, has anybody got users on their systems with "%" as part of the user identifier? Probably a few, but vastly: no. "%" _is_ intepreted by most large sites, after all standard address characters have been processed, stripped off, and yet the message is still unresolved. The usual processing of "%" is: locate the rightmost % change it to an @ go back and do what @ requires This is a _HACK_. But it's widely implemented. It has the same level of "pseudo standardization" that "!" has, though the two characters evolved on different planets. So when Rick said: # Anyone who gives % precedence over ! should fix their mailer. I say: uh-uh, nothing's wrong with my mailer. If I'm to interpret % at all, I'll be doing it mostly by the seat of my pants -- since there's no standard for it, it's in the local-part after all. It has a common meaning, which is very similar to the meaning of "@" -- the thing to the right of it is a host or domain or something, and the thing to the left of it is an address or a route or some such that the thing to the right of it can be halfway depended upon to understand. I'll say again: % is just another character if there's an @ anywhere in an address. @ is spoken of in RFC822, % is not. % should be treated like "a" or "b" or "c" if there's an @ anywhere in the address (really route-addr but you know what I mean). The UUCP "!" is in the same state -- it's just another character if there's an @ anywhere to be found. So, shall I fix my mailer to send back mail that gets here looking like "xyzzy!bar" or "bar%xyzzy" after I've stripped off the "@dec.com"? I'd rather not just bounce things, since there is something of a standard for what these LOCAL-PART characters mean. I give ! precedence over %, because I've already got a character that does what % does -- that is, @. % begins to have great value as a low-precedence @ that will be treated as an @ once all @'s and !'s have been stripped out. (Andrew Macpherson continues:) # Having got that off my chest, here is the associated nasty: mcvax # uses it as a 'local-part' operator, and hands on addresses of the form # a!b!u%l, which any Internetted (and probably any JANET) host will treat # as send to 'l' for uucp forwarding. Bleah. Seriously. If I want it to go to "l" first, I can use "@l". If I say "%l", it probably means that I want to do something that @ can't do -- namely, not be evaluated until it reaches "b". # This is not usually a problem but occasionally we recieve US mail which # has hopped to the arpanet and been strangely delt with... "Strangely"? Our conventions are different, that's true. John Diamant @HP once sent me an unfinished RFC that dealt with this issue, but like him, I could never figure out quite how to resolve everything into one neat little package. But I do think that after the one, Crocker-given symbol has been processed and we are down to our nitty-gritties trying to hand off a piece of mail based on the local-part, that ! usefully precedes % in what little decoding is possible. # Now the other point... Mixed addresses. If you live in the uucp world only # you have no trouble. If in 822 land likewise. I understand the JNETters # allow % as a source-routing so they also have a consistent rule-set. All 3 # have a route specification method, therefore there is neither need nor # justification for mixed-mode addressing. [...] The only safe and reasonable # course to take is to provide the destination address in the format required # by the network you are using. I agree completely. The rules I use for local-part precedence are worst-case, and properly generated mail messages don't get that far into the bowels of my mailers. If something comes to me over UUCP, the envelope recipients can easily be coded, each and every one, in pure !-notation. If I want to submit a message into a UUCP transport system, I can bloody well code up all the envelope recipients in pure !-notation. Likewise, if something comes in over SMTP, the envelope recips can and should be in straight route-addr notation (i.e., @a,@b,@c:u@d, and gosh that sure is ugly, Dave), and I can certainly be expected to submit things in that form. As Diamant (am I spelling that right, John?) points out, though, RFC822 and its friends imply or demand that all domains named in a route-addr be registered with the NIC. This is silly and inconvenient and everybody ignores it. But it does mean that if something comes to you over UUCP with an envelope recip of a!b!c!d and you decide to reach "a" via SMTP and you want to rewrite the envelope recip into route-addr and you rewrite it to be @a,@b:d@c and either "b" or "c" is not registered with the NIC, you've just broken another silly regulation. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/21/88)
[ I apologize for not cross-posting this to the original list of groups, but I use notes, not news, and it doesn't support cross-posting, so this article is posted to the group with the most discussion on this topic -- even though it is probably not the best match] > I agree that % is not a defined pseudonym for @ and that anyone who tries > to say it is can be ignored. It is, indeed, part of the "local part", and > there is no written standard that says it has to be processed one way or > another. Yes, but if not stated explicitly by the standards, at least implicitly, "%" may not be interpreted on even the final destination machine with higher priority than any official routing character. > But, um, has anybody got users on their systems with "%" as part of the > user identifier? Probably a few, but vastly: no. I think bitnet has users with "%" in their name. It is, at least, legal on bitnet. > This is a _HACK_. But it's widely implemented. It has the same level of > "pseudo standardization" that "!" has, though the two characters evolved on > different planets. As both Rick Adams and Rich Salz have also stated, this is not correct. "!" is officially registered in RFC976 and indeed it says how to handle "@" and "!" (@-precedence but avoid both in the same address if at all possible). > > So when Rick said: > # Anyone who gives % precedence over ! should fix their mailer. > > I say: uh-uh, nothing's wrong with my mailer. If you only claim to be RFC822 compliant, then you're right, but if you are supposed to be RFC976 compliant then you're hosed. Unfortunately, there is no way to tell who is RFC976 compliant, and many 822 hosts don't know anything about 976, so this is a tough problem (you can't expect a non-UUCP machine to give "!" precedence over "%" when it doesn't know anything about "!"). > I give ! precedence over %, because I've already got a character that does > what % does -- that is, @. % begins to have great value as a low-precedence > @ that will be treated as an @ once all @'s and !'s have been stripped out. I still say this is wrong. If you understand "@" and "!" then you should conform to RFC976. It does not explicitly state that "%" must have lower precedence. I have had several discussions with Mark Horton on this, and it was the intent of RFC976 to require that. The abortive RFC attempt made by me (and Scott McGregor, also of HP) attempted to clarify the rules for dealing with "%", source routing, and UUCP routing correctly, but we discovered that it was impossible to define simple rules thanks to some extreme corner cases (a!b%c@d) and the fact that source routes have obnoxious restrictions on them. > As Diamant (am I spelling that right, John?) Yup. > points out, though, RFC822 and > its friends imply or demand that all domains named in a route-addr be > registered with the NIC. This is silly and inconvenient and everybody > ignores it. But it does mean that if something comes to you over UUCP with > an envelope recip of a!b!c!d and you decide to reach "a" via SMTP and you > want to rewrite the envelope recip into route-addr and you rewrite it to be > @a,@b:d@c and either "b" or "c" is not registered with the NIC, you've just > broken another silly regulation. Absolutely correct and I agree with your assesment. It is a major annoyance. Maybe the answer is to get this restriction dropped and then the abortive RFC could be reinstated with that change and the rules could be much simpler. It would at least allow UUCP routes to be converted always to source routes at RFC976 gateways, and to have "%" never touched at such a gateway. I'm willing to take a stab at rewriting the RFC with that restriction removed to see if it will resolve the ambiguity. The fact that this discussion keeps cropping up (about every 6 months) is reason enough to do the RFC if indeed, an answer can be provided. What do you think? John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant