On Wed, 30 Jul 1997, D. J. Bernstein wrote:
1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by
several measures. (The separator is configurable by the sysadmin, but
most people stick to dash, which I recommend for a variety of reasons.)
This is the first I've heard of using "-". I've seen "=" used before. We
have to pick a single character, and I picked "+" because it is already
supported or partially supported by several vendors including:
sendmail, CMU Cyrus IMAP server, AMS, PMDF, and Pine.
I'll replace the words "de-facto standard" with "one common practice for"
in the intro since that's more accurate.
I also think "-" is a poor choice since it is already used for "-list",
"-owner", and "-request" primary addresses (the latter of which is a
proposed standard). Overloading symbols is bad.
3. The requirement that foo-bar be delivered to foo ``by default'' is
violated by any delivery agent that doesn't support subaddressing. What
is the point of a requirement that nobody can rely on?
The idea is if my MUA and final delivery MTA are "subaddressing
compliant", then everything works as expected without sysadmin
intervention. The idea is to create a new level of conformance (subaddress
conformance) which users will find valuable.
5. The ``canonically quoted'' section confuses content with encoding.
Any delivery agent that uses your syntax is almost certainly violating
RFC 822, section 3.4.4. The correct rule is very simple: any nonempty
string of ASCII characters is a valid local part. RFC 821 and RFC 822
specify encodings of those strings for SMTP and mail headers.
The choice is either to require "canonically quoted" form which is what
users see currently in their user interfaces (unfortunately), or to
require "raw form" and define the mapping algorithm to RFC 821 and RFC 822
addressing. As users never see "raw form" and it can't be left-to-right
parsed, I'm not comfortable using it at this point.
I'd certainly welcome suggested text which makes it clear that the quoting
is part of the encoding rather than the content.
6. Your restrictions on MUA quoting outlaw some valid addresses.
It does prevent the use of subaddresses with local parts that use
or contain control characters or NUL. Is this a problem?
It also doesn't "outlaw" -- it only forbids generation of such addresses
and subaddress processing of such addresses in subaddress compliant
software.
8. ``MUST ignore subaddresses for the purposes of such validation'' is
bizarre. If an MUA understands subaddresses, why shouldn't it validate
them?
Good point. How about "MUST ignore subaddresses for the purpose of
user validation"?
9. The requirement that list servers ignore subaddresses effectively
prohibits the use of cryptographic cookies in return-path addresses for
sender authentication.
I don't understand what you're saying. Is there an RFC or Internet Draft
I can read on this topic? Is there some reason cookies can't be computed
only on the primary address?
10. ``Delivered to that primary address'' is unclear.
11. ``Owner of that primary address'' is unclear.
12. ``Rewriting'' is unclear.
13. ``Folder'' is unclear.
14. ``Command line interpretor'' is unclear.
Ok, I'll work on clarifying those in the next draft.
If this is all you disagree with, then I gather this isn't a bad start on
the problem?
- Chris