Re: objections, again

[Chris Newman <[e-mail]>]

On Sun, 3 Aug 1997, D. J. Bernstein wrote:
> > it can still be configured to handle them.
> 
> Do these people have to change their e-mail addresses when they install
> your ``compliant'' software?

If they choose to use this variety of subaddressing, then they'd have to
change those addresses or configure in a special MTA alias.

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

If it is an administrative mailbox name for a mailing list "widget", then
then RFC 2142 clearly requires that it be "widget-request".

> 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.

You're correct that X isn't required.  But if X is part of service Y and
saying "MUST do X by default" makes service Y work consistantly between
implementations, then it is entirely reasonable.

> When your MUA replies to
> 
>    From: "a,b+c"@d.e
> 
> it will incorrectly pass "a,b+c"@d.e to the MTA.

There is nothing incorrect about that.  The address encoding used in SMTP
is "a,b+c"@d.e for that address.  Yes, the alternate encoding a\,b+c@d.e
is also permitted but that's generally believed to be a mistake in the
formal grammar and probably won't be permitted on generation in 821bis.
The format a,b+c@d.e is NOT legal in SMTP.

> 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.

Agreed.  So does all this have a point?

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

The vast majority of MUAs submit via SMTP.  Thus they have to parse
addresses and generate valid SMTP encodings of the address. 

> > >    * 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.''

My previous response was to a statement to the effect that MUAs may wish
to validate certain subaddresses.  "bizarre" is not a technical point and
does not belong in a technical discussion.

> 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.

I asked to have the spec reviewed because I don't write perfect specs the
first try.

> 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.

This is an interesting scenario.  The obvious thing to do is allow
different posting/control and subscription addresses and associate the key
with the posting/control address.  The other option would be to disallow
registration of PGP keys with subaddresses at the MLM.

> Your denial of this security issue is despicable.

Why does this make me think of Daffy Duck?

> 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.''

Linking the proposal to a single product when it is already in multiple
products is deceptive.

> > 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?

I double-checked and found I was incorrect on this point.  Pine in
IMAP/SMTP mode does no recipient address validation beyond address book
lookup.  It was simply relaying RCPT TO errors from the SMTP submit
server.

Pine has a compile-time option to allow the from address to be edited,
although I had to create a personal version to use subaddresses in MAIL
FROM.

		- Chris