Also note that the requirement Keith calls "Opacity" (and which, as he
points out, is already a firm requirement) prevents most, if not all,
schemes in which either (i) a user types an encoded string for a remote
address which is transformed to, say, 8bit or UTF for the sending-SMTP
to use or (ii) A user types in UTF and the MTA converts it to some
encoded form before opening the connection. You simply cannot assume
that anything used as an introducer-character isn't part of a legitimate
address and, while you might be able to invent quoting conventions for
local use, they would certainly drive users crazy (and violate Keith's
principles d and e).
My proposal uses a type (ii) approach, but it has no problem
with quoting conventions. Take my own name as an example. I
admit that it's theoretically possible that the local-part
olle_j*5A'rnefors
can be used by someone who wants exactly this sequence of ASCII
characters. Such a person will have to live with the fact that
his address will be displayed with an a-umlaut instead of "*5A'"
for users with modern mail programs. Or his postmaster will
have to rethink his principles for forming cryptic mailbox
names. There is no need for quoting conventions to allow
displaying or writing addresses with "real" "*" characters,
because such addresses are _identical_ to the corresponding
addresses with non-ASCII characters.
I don't think that this is a big practical problem. Asterisks
are very rare in local-parts. And there is no natural reason to
use them.
As part of this, remember that, under normal "one-to-one" mail
circumstances, mailbox names that go into RFC822 address fields are
going off to the MTA to be used as envelope addresses. While we can
fuss with the RFC822 headers quite a lot (although I think we are risky
ground here), the transport address environment is much more constrained
and much harder to change.
Do you mean that any of the characters "*", "&", "'" or "_" are
dangerous to use in envelope addresses? My proposal doesn't put
any other demands on the MTA than these characters and a
moderate increase in address length. (The longest envelope
address I personally have encountered was:
SATO_TAKAYUKI_K/HP8900_HQ////////HPMEXT1/TAKAYUKI#b#K#b#SATO#o#HP8900#o#HQ(_at_)opnmail1(_dot_)corp(_dot_)hp(_dot_)com
)
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>