I think the EAI discussion took a turn a bit, but my point was:
EAI sender sends mail to an EAI capable mailing list which has members
which are not EAI capable is a similar scenario to what we're discussing
here for DMARC.
Ie, in order to resend the message, the choices are:
1) Do nothing and maybe the receiver allows the EAI message despite it not
conforming to RFC 5322 and despite the receiving mail server not
advertising SMTPUTF8... or maybe it rejects it.
2) Downgrade the message such that everyone on the list receives something,
even if not what we'd prefer they receive
3) Don't forward EAI messages to non-EAI capable members
4) Don't accept any EAI messages to the mailing list if there are any
non-EAI capable members
Now, it turns out that the majority of mail software is probably fine with
#1 with some level of degradation, so we're less likely to see #2 than we
are in the DMARC case. Even so, at least this is an ability one could
probe, so we could know when to downgrade and when not to, theoretically...
a mailing list could also interpret DMARC rejects, I guess, and learn when
to downgrade and not on a per-recipient basis.
I would think that both #3 and #4 are less polite choices, and ditto with
applying them to DMARC.
In any case, I'm sure the EAI folks discussed what to do in this scenario,
but I'm not really discussing whether or not #2 is within spec as much as
I'm talking about the better support for your users in an imperfect world
and drawing a parallel to DMARC.
Brandon
On Mon, Nov 7, 2016 at 7:25 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
(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(_at_)mauve(_dot_)mrochek(_dot_)com 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