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

From: Franck Martin <[email-masked]>
Date: Fri, 8 May 2015 19:08:08 -0500 (CDT)

I went over the emails of this week, did not find any new comment/update for the above document.

---

From: "John Levine" <[email-masked]>
Date: 9 May 2015 02:33:55 -0000

>I went over the emails of this week, did not find any new comment/update for the above document. 

Do you know when you'll be posting a new draft?  There's a fair amount of stuff to fix.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 17:44:40 -0500 (CDT)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Friday, May 8, 2015 7:33:55 PM
> Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt
> 

Please submit "stuff" that needs to be fixed

---

From: "John Levine" <[email-masked]>
Date: 22 May 2015 23:16:26 -0000

>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.

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.

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.

Section 4.1.2.3 is equally wrong for the same reasons and also needs to go. 

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.  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.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 18:40:24 -0500 (CDT)

----- Original Message -----
> Sent: Friday, May 22, 2015 4:16:26 PM

I rewrote some of it, see next email...

I'm mulling indeed about deleting the whole EAI stuff, because it is about tangent policies around DMARC and not an interoperability issue per se.

But I'm stubborn, so I leave it for one last round, if only to get someone(you) to comment on the draft :P

Pass that, I don't see much more comments, so WG Chair should move the document close to last call?

I see the mailing list is focused on finding future solutions, not in explaining current operational solutions.

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2015 20:06:57 -0400

> I'm mulling indeed about deleting the whole EAI stuff, because it is about tangent policies around DMARC and not an interoperability issue per se.

Really, it's just wrong.  Delete it, please.

> I see the mailing list is focused on finding future solutions, not in 
> explaining current operational solutions.

OK, then how about taking out all of section 4?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 19:26:25 -0500 (CDT)

----- Original Message -----
> From: "John R Levine" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, May 22, 2015 5:06:57 PM
> > I'm mulling indeed about deleting the whole EAI stuff, because it is about
> > tangent policies around DMARC and not an interoperability issue per se.
> 

It is not wrong, I think you have no practical experience with EAI. The point is that it is just not relevant to the scope of the document.

> OK, then how about taking out all of section 4?

LOL! I'm more thinking about taking out entirely section 4.2 seeing the traffic on this list.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 23 May 2015 12:40:27 +0900

John Levine writes:

 > 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.

s/take out/deprecate/, please.  I know of at least one MLM with many
thousands of subscribers (python.org's locally modified version of
Mailman) that does use .invalid.  I know of exactly one recent poster
using a p=reject address, and nobody has complained about not seeing
his posts despite the practice.  (That's the dev lists, I'm not
subscribed to the user list which has a couple score thousand
subscribers I suppose, and probably a much higher proportion of users
posting from p=reject domains and receiving at "strict" treatment
domains.)

---

From: "John Levine" <[email-masked]>
Date: 23 May 2015 14:39:28 -0000

>It is not wrong, I think you have no practical experience with EAI.

You might want to review these, as well as RFC 6783.

http://www.circleid.com/posts/email_in_the_worlds_languages_part_i/
http://www.circleid.com/posts/email_in_the_worlds_languages_part_ii/
http://www.circleid.com/posts/email_in_the_worlds_languages_part_iii/

---

From: [email-masked]
Date: Sat, 23 May 2015 07:59:07 -0700 (PDT)

(chair hat off)

> 6854 allows empty groups "during the transition period to SMTPUTF8" is

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".

> address in a domain that publishes no DMARC record.

Agreed.

>    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.

> Section 4.1.2.3 is equally wrong for the same reasons and also needs to go.

Agreed.

> 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.

> Take

I don't mind mentioning .invalid as long as the problematic nature of 
using this mechanism is made clear.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 May 2015 11:06:32 -0400

On 5/23/2015 10:59 AM, [email-masked] wrote:
> violation aspect needs to be made clear and

+1

> (2) There needs to at least some

Side note, I think there is too much of this going on that it have 
been causing too many compatibility problems in the long run/term.

> As such, I agree with John: This section needs to be deleted.

If there is an DMARC interop issue related to SMTP vs ESMTP 
compatibility/support issues, then that should be pointed out.

But this section talks about a mitigating method, the new group syntax 
support that I never supported anyway.  As long as it was a 
transparent syntax, there was no need to get worry about it, that I 
could see.

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 reports should outline all the related issues that a current and 
future MARC implementation may run into.

-- 
HLS