Re: objections, again

["D. J. Bernstein" <[e-mail]>]

> it can still be configured to handle them.

How?

Consider, for example, the following two accounts (names changed to
protect the innocent):

   [e-mail]
   [e-mail]

These are project accounts for completely different groups.

According to your proposal, mail for widget+x MUST be delivered to
widget by default, except that widget MAY be allowed to reconfigure the
delivery.

Now you seem to be claiming that software can be configured to do

   widget+(x+*) -> (widget+x)+*

Is that capability required by your document? Yes, qmail could pull
this sort of trick even if it didn't do the right thing by default, but
what about other MTAs?

More importantly, your rules violate foo.com's security policy.

It is unacceptable for the widget people to receive the widget+x mail.

It is unacceptable for the widget people to control the widget+x mail.

Do these people have to change their e-mail addresses when they install
your ``compliant'' software?

  [ -request vs. the artificially inconsistent ``+'' separator ]
> However, it is naming hierarchy rather than subaddressing and it uses a
> different separator.

I'm still waiting for an answer to my question on this topic: Is it
widget-request or widget+request?

> Therefore there is no inconsistancy. 

Answer the question.

> The keywords are used to get interoperation between

How can ``MUST do X by default'' be required for interoperation? X isn't
even required! It's indistinguishable from ``MUST NOT do X by default''
from an interoperability perspective. Other software can't rely on X and
can't rely on not-X.

> >    * Chris's syntax requirements prohibit MUAs from sending mail to
> >      some valid addresses.
> Only when using subaddresses.

The point remains: Your rules prohibit MUAs from sending mail to some
valid addresses.

> >    * Chris's syntax requirements produce misdirected mail for _all_
> >      quoted addresses when the MTA handles quoting correctly (as, e.g.,
> >      MMDF does).
> I see no reason why.  Please explain.

When your MUA replies to

   From: "a,b+c"@d.e

it will incorrectly pass "a,b+c"@d.e to the MTA.

The address is actually a,b+c@d.e. It can be _encoded_ as "a,b+c"@d.e
under RFC 821 and RFC 822, but the quotes are not part of the address.

The incorrect address will work with sendmail, but that doesn't make it
right. sendmail violates the quoting rules in RFC 821 and RFC 822.

It's much better in practice for the MUA to avoid address parsing. The
MTA's submission agent can take care of it.

> >    * Chris's validation restriction is bizarre.
> This is not a technical complaint and thus has no merit.

Amusing---your previous response to this criticism was ``good point.''

Let me rephrase. Your validation restriction has so many obviously wrong
effects that it can't possibly be what you meant. It is, like your many
unclear requirements, a result of bad writing; the fact that it's clear
is merely an accident.

> But this is
> not a real security issue as anyone can generate email from "a", "a+b" or 
> "a+c" regardless.

Wrong.

I've seen a list that, before calling the MLM software, invokes PGP to
verify that the message is PGP-signed by the sender. The MLM then checks
the sender address against the subscription list. Subscribers have to be
preapproved (though there are some open sublists for lurkers).

Your requirement destroys this security mechanism. An attacker takes an
approved ``[e-mail]'' address and registers a ``[e-mail]''
PGP key; PGP is satisfied; but an MLM following your rules has to ignore
the +haha when it's checking the address.

Your denial of this security issue is despicable.

> >    * Chris's MLM requirement prohibits cryptographic applications of
> >      subaddresses.
> How does the MLM requirement conflict with RFC 2015?

I said ``cryptographic applications of subaddresses,'' not ``RFC 2015.''
I already gave cookies as an example. It's a _different_ mechanism, see?

  [ proposal is not the de facto standard ]
> Thus I have previously agreed to alter the wording.

Inadequate. Your use of the term ``subaddressing'' is still deceptive.
Choose a phrase that accurately identifies your subaddressing system,
such as ``The AMS Subaddressing System.''

> Out of curiosity, which MTAs other than qmail support your flavor of
> subaddressing?

Do you mean using dash as a separator, or the more advanced features?

Reportedly both sendmail and exim can be configured to handle dash.

MMDF, the only popular MTA that has had this feature for a long time,
appears to break addresses at "=", "/", or "|"; not configurable.

On the MUA side, apparently mutt, elm, trn, slrn, nn, gnus, knews, and
mh allow the user to configure arbitrary From addresses. (Of course,
qmail can set the From even if the MUA doesn't.)

> And I was surprised to find that Pine
> supported the user-validation subaddressing feature.

Which version? Where is this documented? Are you sure you haven't been
surprised by a local hack?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html