We have to pick a single character,
Why?
What interoperability problems are you trying to solve?
One of the reasons for qmail's growing popularity is its simple user
interface for subaddresses. But what does this have to do with the IETF?
Why should the IETF be trying to control user interface competition?
Throw away all the user interface stuff, and your document appears to
collapse down to a single requirement:
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've seen "=" used before.
MMDF.
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?
The idea is if my MUA and final delivery MTA are "subaddressing compliant",
If you simply want to define ``subaddressing compliant,'' go take it to
some group that publishes standards for user interfaces. (Maybe Apple.)
The choice is either to require "canonically quoted" form which is what
users see currently
Again you're confusing content with encoding. The address
a,b,c(_at_)heaven(_dot_)af(_dot_)mil
is perfectly valid. It is _encoded_ as RCPT TO:<"a,b,c"@heaven.af.mil>
in SMTP. It may be _encoded_ in some way for user display. (Some people
use addresses with commas for spam control.)
The more basic question here is why you're bothering to talk about
quoting in a document about subaddresses.
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.
---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html