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(_at_)d(_dot_)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(_at_)d(_dot_)e is NOT legal in SMTP.
The address is actually a,b+c(_at_)d(_dot_)e(_dot_) 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 ``joe(_at_)isp(_dot_)net'' address and registers a
``joe+haha(_at_)isp(_dot_)net''
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