Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

From: Franck Martin <[email-masked]>
Date: Tue, 9 Jun 2015 05:16:33 -0500 (CDT)

----- Original Message -----
> From: [email-masked]
> To: "John Levine" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Sent: Saturday, May 23, 2015 7:59:07 AM
> Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt
> 
> (chair hat off)
> 
> > >Please submit "stuff" that needs to be fixed
> 
> > The worst problem is still section 3.1.2.3 which needs to be deleted,
> > since most of what it says is wrong, and what little isn't wrong is
> > irrelevant.
> 
> > RFC 6854 is not about EAI, since an ASCII MUA can create mail with an
> > empty group From: as easily as an EAI MUA.  The assertion that RFC
> > 6854 allows empty groups "during the transition period to SMTPUTF8" is
> > false.
> 
> RFC 6854 does mention EAI, but only as one of its possible uses. The primary
> stated use is for "utomated systems that wish to send email but cannot handle
> replies".
> 
> > Empty group syntax has nothing to do with DMARC since there is no
> > domain on the From: line to check.  From a DMARC point of view, there
> > is no difference between a From: with an empty group and one with an
> > address in a domain that publishes no DMARC record.
> 
> Agreed.
> 
> > This sentence is completely false.  EAI MTAs never downgrade mail in
> > transit:
> 
> >    If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
> >    aware MTA, the EAI/SMTPUTF8-aware system may transform the
> >    RFC5322.From header field of the message to include group syntax to
> >    allow the non-aware MTA to receive the email.
> 
> Specifically, this sort of downgrading is only defined in the context of an
> EAI-aware POP or IMAP server returning a message to a non-EAI-aware client.
> While it's  true that such a message can be resubmitted to the transport
> infrastructure, at that point its a new message, with all that implies.
> 
> An MTA performing such a downgrade in the context of handling EAI mail is
> engaging in an egregious standards violation. Talking about such standards
> violations is an interoperability document is fine, but (1) The standards
> violation aspect needs to be made clear and (2) There needs to at least some
> evidence that such things are happening on a wide enough scale to care about.
> 
> As such, I agree with John: This section needs to be deleted.

I may not have read everything EAI, but I think the above is not necessarily spelled out in the EAI protocol, and someone not knowing the history of EAI may interpret the spec quite differently. This is why I guess you have operational testing before an RFC get the standard status...

Removed, because the EAI paragraphs is about malformed emails and security workaround to defeat DMARC and not the impact DMARC has on email flows. This language could go in a BCP on how to deploy an MTA with DMARC.

> 
> > Section 4.1.2.3 is equally wrong for the same reasons and also needs to go.
> 
> Agreed.
> 
> > Section 4.1.3.1 doesn't mention rewriting the From: address to a valid
> > forwarding address in a domain for which the list can sign.  It's not
> > just me doing it, LISTSERV can do that, it's widely implemented.
> 
> Our list server supports it as well, and it is being used this way. So:
> Agreed.

Added

> 
> > Take
> > out .invalid, nobody does that because (as I discovered and you
> > mention) many spam filters dislike From: addresses with domains that
> > don't resolve.
> 
> I don't mind mentioning .invalid as long as the problematic nature of
> using this mechanism is made clear.
> 
>
I think it is, and I too, prefer to document it, rather than omit it

---

From: Franck Martin <[email-masked]>
Date: Tue, 9 Jun 2015 05:20:05 -0500 (CDT)

----- Original Message -----
> From: "Hector Santos" <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, May 26, 2015 8:06:32 AM
> On 5/23/2015 10:59 AM, [email-masked] wrote:
> > (chair hat off)
> >
> 
> For DMARC, I don't support any form of rewriting the header from. I
> don't think the interop report should encourage rewriting or
> downgrading.   But I am not sure if removal/deleting the section does
> that.   I think it should say that downgrading or rewriting can cause
> more unrelated to DMARC conflicts.

The EAI section is removed, because it is about rejecting message that may trivially bypass DMARC, rather than the scope of the document which is what to do to remediate DMARC policy.

> 
> The reports should outline all the related issues that a current and
> future MARC implementation may run into.
> 
Future is hard to predict

---

From: [email-masked]
Date: Tue, 09 Jun 2015 09:40:08 -0700 (PDT)

> I may not have read everything EAI, but I think the above is not necessarily
> spelled out in the EAI protocol,

In regards to addresses, it's spelled out very explicitly. RFC 6530, section 9:

9.  Downgrading in Transit

   The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321])
   states that "due to a long history of problems when intermediate
   hosts have attempted to optimize transport by modifying them, the
   local-part MUST be interpreted and assigned semantics only by the
   host specified in the domain part of the address".  This is not a new
   requirement; equivalent statements appeared in specifications in 2001
   [RFC2821] and even in 1989 [RFC1123].

   Adherence to this rule means that a downgrade mechanism that
   transforms the local part of an email address cannot be utilized in
   transit.  It can only be applied at the endpoints, specifically by
   the MUA or submission server or by the final delivery MTA.

There's probably text elsewhere that further emphasizes the point, but I didn't
bother to look.

> and someone not knowing the history of EAI may interpret the spec quite
> differently. This is why I guess you have operational testing before an RFC get
> the standard status...

I don't think "cannot be transformed" is in any way ambiguous.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Wed, 10 Jun 2015 08:06:32 -0400

> Future is hard to predict

Serious?

Frank,

This is an INTEROP report.   It includes the future in the sense of an 
existing or perhaps NEW system that MAY want to IMPLEMENT this junk, 
in the future, and they need/wish/desire to find out the kind of 
implementation issues that currently exist and will mostly run into 
it.  If EAI (or anything else) is one of those possible messy issues, 
then you need to talk about it.  Don't be intimidated by Levine and 
Ned. If there is a ESMTP vs SMTP conflict that shows up with DMARC, 
then describe it.

-- 
HLS