On Wed, 30 Jul 1997, D. J. Bernstein wrote:
We have to pick a single character,
Why?
What interoperability problems are you trying to solve?
Interoperability between MUAs, final delivery agents and mailing list
servers from different vendors.
I want to be able to subscribe to list foo as
<chris(_dot_)newman+foo(_at_)innosoft(_dot_)com> and have it delivered to me.
In order for
this to work, I need user agents which let me type the "+foo" in the from
and envelope sender address, I need mailing list software which doesn't
reject postings from <chris(_dot_)newman(_at_)innosoft(_dot_)com> if I'm
subscribed as
<chris(_dot_)newman+foo(_at_)innosoft(_dot_)com>, and I need a final delivery
agent which
won't reject "+foo" addresses.
If this isn't a need for multi-vendor interoperability, what is?
Mailing list managers must disregard foo in deciding whether
joe+foo(_at_)host can send messages to the mailing list.
But that's a bad requirement. It prohibits cryptographic uses of the
subaddress string. It also ignores the fact that joe+37(_at_)host might be a
different user, with no right to use the mailing list; you have no way
to tell whether the subscriber's delivery agent supports subaddresses.
I don't consider this a big deal. People don't use "+" in addresses most
of the time, unless they're using it as a subaddress separator. The
failure mode is to allow someone to post who otherwise might not be able
to -- not a big deal given how rarely + is used in addresses for other
reasons.
I also think "-" is a poor choice since it is already used for "-list",
"-owner", and "-request" primary addresses
This is one of the reasons that dash is a _good_ choice: it continues
the tradition of a dash-separated address hierarchy. Using a different
character for the top level is a pointless inconsistency.
For example, the main mailing list for a project commonly coincides with
the project's account name. Is the owner's address project-owner or
project+owner?
I'd argue that current uses of "-" do not have subaddress semantics. The
"foo-list-request" address is not under management control of the entity
with the address "foo-list". The common use of "+" is to separate address
management hierarchy. Addresses before "+" are managed by the sysadmin,
addresses after the "+" are managed by the entity before the plus. I
think most current uses of "-" are simply naming hierarchy and not
subaddressing.
Again you're confusing content with encoding. The address
No I'm not. I understand the distinction well. But the distinction is
not clear to implementors of 821/822 and most Internet mail users so I see
little point in making the proposal more complex in order to make the
distinction clear. The "raw" format for a mail address doesn't really
exist anywhere, except possibly as an internal aid to certain
implementation strategies.
The more basic question here is why you're bothering to talk about
quoting in a document about subaddresses.
Because a good standard needs complete formal grammar for what it's
discussing.
I don't understand what you're saying.
Envelope sender addresses are easily forged. One solution is to have
each sender use
Return-Path: <sender-dsn-cookie(_at_)his(_dot_)host>
where ``cookie'' is some sort of secret string---for example, a
subscriber-specific secret supplied by the MLM. This obviously doesn't
work if the MLM is required to ignore the cookie.
This is another case where MUA, final delivery agent and list exploder
need to interoperate. There's also no reason this has to use the same
delimiter. But in order to be practical for wide deployment, this would
have to be standards track.
- Chrsi