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