(adding the EAI list to the distribution -- there are people who
hang out there who need to see, and check on, this)
--On Monday, November 07, 2016 15:08 -0800
ned+ietf@xxxxxxxxxxxxxxxxx wrote:
>> Absent that, there's the small question about how the EAI
>> group would have the authority to make such a major change to
>> such a basic email feature...
>
> RFC 6854 can speak for itself as to the rationale for allowing
> no address.
>
> The EAI connection was, as I recall, for use in downgrade
> formats used to
> present EAI messages to non-EAI clients via POP3 and IMAP4.
Yes.
IIR, 6854 was written the way it was in order to avoid getting
tangled up with normative dependencies on the EAI specs.
However, I find the combination of its Section 3 ("Applicability
Statement") and Security Considerations rather clear as to both
the motivation and the "don't do this if you don't need to and
especially don't originate a message with this" advice.
"Limited Use" is really very restrictive.
The problem (and tradeoff) are as follows:
A message gets delivered and gets as far as a mailstore with a
backward-pointing address that looks like:
"Non ASCii Name Phrase" <non-ascii-local-part@domain-part>
Note that, if the message got that far, the delivery MTA
advertised itself as fully SMTPUTF8-complaint.
Then a POP or IMAP client comes along that does not support
non-ASCII addresses or headers. Now, there are probably three
plausible choices for the IMAP server (other than just dying a
horrible death):
(a) Trash the message on the theory that any users who would get
themselves into that situation deserve it. However, remember
the important case is a backward-pointing address and, in the
general case, the delivery server doesn't know what client(s)
the user is going to use (and there might be more than one).
(b) Figure out how to respond to any IMAP request that involves
that message with some flavor of "I have this message for you,
but you can't get it and I can't tell you about it until you
show up with an upgraded client".
(c) Convert "Non ASCii Name Phrase" to encoded words and then do
something unpleasant to the address, of which using group syntax
was by far the least problematic solution anyone could come up
with. If the Return-path in the mailstore is the same as the
address in the "From:" and/or "Sender:" header fields, it is
going to be trashed, so a competent IMAP server doing this is
going to figure out how to warn the user and the user, perhaps
after consulting support personnel the first time one of these
happens to her, is going to figure out that doing anything with
the message other than broadly getting its gist is going to
require using an upgraded client.
IIR, these issues are discussed at some length in RFCs 6855-6858.
Now, coming back to the "identification of ... author" problem
and remembering the "Limited Use" bit, if I were designing a
submission server and something reached me with a group name in
the "From:" (or "Sender:") field, I'd probably return it to
whence it came. I'd probably do the same thing if I were a
relay or delivery server, noting that there is no equivalent to
group syntax in SMTP. Both are entirely consistent with
Limited Use -- if one uses it in a context in which it makes no
sense or poses a security threat, one refuses to accept it.
If anyone things that needs to be said more clearly in one of
the EAI-related documents and wants to suggest language, I, and
I assume others, anxiously await an I-D.
john