Re: [EAI] [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

[Brandon Long <[e-mail]>]

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 <[e-mail]> 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
> [e-mail] 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
>
>