Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!hp-sdd!hplabs!hpda!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.mail.sendmail
Subject: Re: Re: mixed addresses
Message-ID: <1410008@hpfclp.SDE.HP.COM>
Date: 21 Jul 88 06:54:59 GMT
References: <8807142016.dusip.andrew@stl.stc.co.uk>
Organization: HP SDE, Fort Collins, CO
Lines: 84

[ 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