Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 18:49:43 -0500 (CDT)

FYI

Please post more reviews... 

-----------------

A new version of I-D, draft-ietf-dmarc-interoperability-02.txt 
has been successfully submitted by Franck Martin and posted to the 
IETF repository. 

Name: draft-ietf-dmarc-interoperability 
Revision: 02 
Title: Interoperability Issues Between DMARC and Indirect Email Flows 
Document date: 2015-04-28 
Group: dmarc 
Pages: 20 
URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-02.txt 
Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ 
Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-02 
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-02 

Abstract: 
DMARC introduces a mechanism for expressing domain-level policies and 
preferences for email message validation, disposition, and reporting. 
The DMARC mechanism can encounter interoperability issues when 
messages do not flow directly from the author's administrative domain 
to the final recipients. Collectively these email flows are referred 
to as indirect email flows. This document describes interoperability 
issues between DMARC and indirect email flows. Possible methods for 
addressing interoperability issues are presented. 

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org. 

The IETF Secretariat

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Apr 2015 14:26:06 -0400

I think overall, there are two concerns I have:

1) The over estimated use of the idea for "rewriting" and
2) the word or term "common" is used for mitigation methods.

Common means most and its not the case. Rewriting is a major industry 
taboo, in all mail or communications concept. Just because one or two 
renegade MLM wrote a kludge for their site,  puts it on a wiki, does 
not make it legit at all, not one iota.

The doc infers that RFC6377 provides guidance, and it immediate jumps 
to a Rewriting "common mitigation policy."  Thats not right.  In fact, 
RFC6377 preaches ADSP or in general the DKIM Policy framework.   I 
don't support Rewriting, its not common, its not a BCP.  It reeks with 
IETF appeal problems.   I don't think the doc should legitimize any 
idea of rewriting.

Other comments...

The doc should make a note that DMARC is an informational status 
domain. It is not a proposed standard nor a BCP.  It is very 
incomplete and it is missing lots of considerations.  The 3rd party 
issues was intentionally in an attempt to avoid a complex design 
issue, but that it could not avoid.

The doc fails to mention technical history with SSP ADSP, ATPS, or any 
of the RFC documents products such as:

   rfc4686  Analysis of Threats Motivating DKIM
   rfc5016  Requirements for a DKIM Signing Practices Protocol
   rfc5518  Vouch By Reference
   rfc5863  DKIM Development, Deployment, and Operations

and possibly others.

The docs should explain why ADSP was abandoned and why its "Super 
ADSP" [sic] version called DMARC replaced it.

-- 
HLS

On 4/28/2015 7:49 PM, Franck Martin wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 29 Apr 2015 19:47:20 +0000

2.  Causes of Interoperability Issues

This section focuses on intended recipient perspective but fails to mention/discuss the originator perspective where some subset of originators, particularly for high value transactional messages, want the message discarded if it passes through an intermediary and is modified in any way resulting in a failure to validate. Examples of such messages include those related to financial organizations and medical establishments.

2.1 (This is just a nit) Last paragraph

SPF can provides two Authenticated Identifiers...

This should be "SPF can provide two Authenticated Identifiers..."

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Franck Martin
> Sent: Tuesday, April 28, 2015 7:50 PM
> To: [email-masked]
> Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-
> interoperability-02.txt
> 
> FYI
> 
> has been successfully submitted by Franck Martin and posted to the IETF
> repository.
> 
> messages do not flow directly from the author's administrative domain to the
> final recipients. Collectively these email flows are referred to as indirect email
> flows. This document describes interoperability issues between DMARC and
> indirect email flows. Possible methods for addressing interoperability issues
> are presented.
> 
> 
> 
>

---

From: Franck Martin <[email-masked]>
Date: Wed, 29 Apr 2015 15:40:40 -0500 (CDT)

----- Original Message -----
> From: "Hector Santos" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, [email-masked]
> Sent: Wednesday, April 29, 2015 11:26:06 AM
> Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt
> 

I would avoid the words "renegade" and "kludge". I think you could better phrase the above paragraph.

I'll tone down the use of common, however I'd like to point:
1)Google Groups and Yahoo Groups are doing rewriting, if not mistaken, to cite only one data point, these are large deployments.
2)Common, as in the sense, many MLM software have the option today. Will make it more clear in the doc

> IETF appeal problems.   I don't think the doc should legitimize any

In the realm of things to do to fix the issue, I think rewriting is an operationally used technique on several lists, but I have no data how popular it is compared to other methods. However, and I think this is your point, many more did not change anything and have to manually deal with the issues.

I know a few ticketing systems that have done rewriting before DMARC existed.

Anyone wants to comment or has data on what people did? I think this may be helpful.

Looking for more guidance.

> issue, but that it could not avoid.

yes it should be noted that [DMARC] is informational

> ADSP" [sic] version called DMARC replaced it.

I don't think the purpose of this doc is to describe history, but to explain what may break, how to avoid it, and what are the drawbacks of each solution, if any.

https://datatracker.ietf.org/wg/dmarc/charter/

"Draft description of interoperability issues for indirect mail
flows and plausible methods for reducing them."

"The working group will specify mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows, including deployed
behaviors of many different intermediaries, such as mailing list
managers, automated mailbox forwarding services, and MTAs that
perform enhanced message handling that results in message
modification. "

I think an history of email authentication would be interesting and could be an awesome informational RFC. Are you volunteering?

---

From: Franck Martin <[email-masked]>
Date: Wed, 29 Apr 2015 15:50:40 -0500 (CDT)

----- Original Message -----
> From: "MH Michael Hammer (5304)" <[email-masked]>
> Sent: Wednesday, April 29, 2015 12:47:20 PM
> This section focuses on intended recipient perspective but fails to
> mention/discuss the originator perspective where some subset of originators,
> particularly for high value transactional messages, want the message
> discarded if it passes through an intermediary and is modified in any way
> resulting in a failure to validate. Examples of such messages include those
> related to financial organizations and medical establishments.

Good point. 

added this section, may be you have better language:

2.1.  Originator vs Receiver Perspective

   Some Receivers are concerned that wanted email messages are received,
   regardless if such email messages are not strictly in conformance to
   any standard or protocol.

   Some Originators, particularly for high value transactional messages,
   want the message discarded if it passes through an intermediary and
   is modified in any way resulting in a failure to validate.  Examples
   of such messages include those related to financial organizations and
   medical establishments.

> This should be "SPF can provide two Authenticated Identifiers..."

fixed

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2015 21:36:46 -0000

>Please post more reviews... 

Hmmn.  Section 3.1.2.3 on EAI is, to a first approximation, completely
wrong.  Please delete it, since the problems it describes do not
actually exist.

EAI does not, repeat NOT, downgrade messages in transit.  If I send
you an EAI message, either it'll be delivered as that EAI message, or
it'll be bounced back.  There's no reason that DMARC wouldn't work
just the same as it does on normal mail, give or take some minor and
easily resolved ambiguities about whether the domains in DKIM
signatures are U-labels or A-labels.

All of the downgrade stuff to which this section refers only happens
in one rather arcane situation -- the MTA that received the mail does
EAI but the user's MUA doesn't, and the user is trying to pick up the
mail with POP or IMAP.  Our choices boiled down to invent a new error
code that says "you have new mail but you can't see it neener neener"
or downgrade messages during POP or IMAP retrieval.  Since the normal
place to check DMARC is at delivery time, DMARC will have done its
thing long before any possible downgrade, so the downgrade doesn't
matter.

People might try to forward downgraded messsages, but the issues there
are the same as for any message that's smashed when it's forwarded,
as described in 3.2.2.

We invented the RFC6854 empty From: group syntax hack to enable simple
EAI downgrades, but it applies to any mail, normal or EAI.  My strong
suggestion would be that if there's no address on the From: line,
there is nothing for DMARC to do and no problem to solve.  It's just
like any other message with a return address for which the MTA has no
reputation info.

In 3.2.3, I've never seen list software do PGP encryption, but I have
seen it do S/MIME decryption and re-encryption.  You might want to
change the example.

In section 4.1.1.1, add:

* Senders can use different domains for mail sent directly and mail
  sent in ways likely to have DMARC problems, the former with a DMARC policy
  and the latter without.

Please also delete Section 4.1.2.3, since again the EAI problem it
describes does not exist.

In the first long paragraph in 4.1.3.3, at this point I don't know
anyone adding .INVALID, but I know people rewriting the From: address
to a different valid address that forwards to the real author. Some
people do it the way I do, e.g. [email-masked], or
LISTSERV invents a pseudo-random address in the list's domain.

Section 4.2.1 is hard to follow. Is it describing Doug's thing?

In Sec 7, it's often considered tacky to acknowledge people listed
as document authors.

R's,
John

PS: I could swear we went around the EAI stuff in the last version of this draft.

---

From: Franck Martin <[email-masked]>
Date: Wed, 29 Apr 2015 18:11:59 -0500 (CDT)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, April 29, 2015 2:36:46 PM

Yes, they are not downgraded in transit. I improved the solution section in "receivers", but I realize the description of the problem is not accurate. Fixing (and see below).

> thing long before any possible downgrade, so the downgrade doesn't

I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole use as you describe it above. I wish it would say so. An MTA that has an EAI message that tries to pass it to an MTA that do not support SMTPUTF8 will bounce the message. The MUA or MSA or user may then decide to change the message and use the group syntax to transmit it to an non-EAI environment if it has a normal email address to send to. One can envision such process to be automatic without the user input, especially when the MUA/MSA/MTA is on the same server. See how Coremail handles it transparently (tho they don't use group-syntax).

RFC6854 lacks a lot of guidance.

Even in your case when the MDA/MS gets such message with group-syntax and forwards it, then an MTA will have to deal with it.

> like any other message with a return address for which the MTA has no

Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not like to have a message with an RFC5322.From header field with no valid domain in it. Also moving to email over IPv6 requires you to move to domain blocking. So the point here, there is little incentive to do DMARC if you are not stricter in what you tolerate in the RFC5322.From. Therefore, if you don't want to reject emails from EAI based mail system, your system must support EAI.

> seen it do S/MIME decryption and re-encryption.  You might want to

I have seen lists do PGP encryption. Adding S/MIME nevertheless

>   sent in ways likely to have DMARC problems, the former with a DMARC policy

Added and rephrased

> describes does not exist.

See above

> LISTSERV invents a pseudo-random address in the list's domain.

You used to do it no? Anyhow this is just an example of suffix to use.

The LISTSERV solution is a derivative of rewriting the RFC5322.From header field to use your own domain. Not sure if we should describe it too?

> Section 4.2.1 is hard to follow. Is it describing Doug's thing?

not specifically, people have searched to do some form of transitive trust.

> In Sec 7, it's often considered tacky to acknowledge people listed

roger. will confer with other authors. It was to acknowledge my lack of contribution to the core of the document :P

> PS: I could swear we went around the EAI stuff in the last version of this
Yes but both of our reality fields need to be adjusted... :P

The solution part has been fixed but not the problem part correctly, I overlooked that part.

While I'm doing some EAI+DMARC and have some practical operational experience, the large implementation that I know of is Google. It would be nice to have some guidance from them here.

We may need a few iterations here.

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2015 20:00:12 -0400

> Yes, they are not downgraded in transit. I improved the solution section 
> in "receivers", but I realize the description of the problem is not 
> accurate. Fixing (and see below).

Really, there is no problem.  DMARC works fine on EAI mail.  Just delete 
the section.

> I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole 
> use as you describe it above. I wish it would say so. An MTA that has an 
> EAI message that tries to pass it to an MTA that do not support SMTPUTF8 
> will bounce the message.

Correct.

> The MUA or MSA or user may then decide to change the message and use the 
> group syntax to transmit it to an non-EAI environment if it has a normal 
> email address to send to.

No.  That is completely wrong.  Nowhere in the EAI documents does it 
contemplate that, and no mail system I know does that.  If someone is 
going to send ASCII mail, the only sane way to do so is to use an ASCII 
From: address to which the recipient can reply.  We do expect MUAs to be 
configured with an EAI address for recipients that can handle it and an 
ASCII address for recipients that can't.

There may be Chinese systems that try different addresses, but since it's 
at the sending end, it's up to them to know what addresses they can use 
and to send valid mail.

> Even in your case when the MDA/MS gets such message with group-syntax 
> and forwards it, then an MTA will have to deal with it.

No.  No, no no.  The dowmgrade is only for POP/IMAP retrieval to non-EAI 
clients, not anything else.  If it's forwarded by sieve or the like, it'll 
forward the original EAI message.

> Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not 
> like to have a message with an RFC5322.From header field with no valid 
> domain in it.

Please don't invent stuff.  In any event, the unlikely possibility that 
someone might send mail with an empty From: group has nothing to do with 
EAI or forwarding or anything else.

> You used to do it no? Anyhow this is just an example of suffix to use.

I think there is an important difference between invalid addresses and 
valid ones.

> The LISTSERV solution is a derivative of rewriting the RFC5322.From 
> header field to use your own domain. Not sure if we should describe it 
> too?

It's different because the address in the From: line is (indirectly) still 
the real author, not the list.

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

---

From: Franck Martin <[email-masked]>
Date: Wed, 29 Apr 2015 19:09:27 -0500 (CDT)

----- Original Message -----
> From: "John R Levine" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, April 29, 2015 5:00:12 PM
 
> forward the original EAI message.

When I click the "forward" button there is no MTA involved... It will not forward the original EAI message.

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2015 20:12:21 -0400

> When I click the "forward" button there is no MTA involved... It will not forward the original EAI message.

Right, this is the MUA smashed forward problem, which is nothing new. 
Outlook is famous for being unable to forward anything without smashing 
it.

Regards,

---

From: Franck Martin <[email-masked]>
Date: Wed, 29 Apr 2015 19:47:14 -0500 (CDT)

----- Original Message -----
> Sent: Wednesday, April 29, 2015 5:12:21 PM

No. No, no, no. No, no, it is not. No, no, it is not, any email client can forward the message they downloaded via POP/IMAP. They have no idea about the "original EAI message"

"smashing" the message, because MS-Exchange/MS-Outlook prefers MS-TNEF to MIME, is a different problem.

Please, don't mix problems.

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2015 21:01:26 -0400

> Please, don't mix problems.

It's exactly the same problem -- the MUA changes the message so the 
DMARC info is invalid.

In any event, I would be surprised if 0.001% of EAI mail gets downgraded 
after delivery.  The people who use EAI are largely in China, and the 
whole point is so they can type Chinese into their MUAs.

The whole null From: thing is a distraction.  Please just delete it.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 30 Apr 2015 10:17:47 +0900

Hector Santos writes:

 > Common means most and its not the case.

You're wrong.  "Common" in this context means "frequently observed".
"Most common" means "most frequently observed."

That said, with no statistics about actual usage, I would omit this
word.
 
 > Rewriting is a major industry taboo, in all mail or communications
 > concept. Just because one or two renegade MLM wrote a kludge

It is indeed a kludge, and IMO it is not legitimate.  Nevertheless,
rewriting From is now common in my experience, and even my own product
was forced to implement it "by popular demand" (and by precedence,
since Franck's patch that does rewriting was the first offered).

 > I don't think the doc should legitimize any idea of rewriting.

It doesn't.  It mentions them because they exist, and they are
unpatentable because any practioner skilled in the art of email would
immediately think of them and know how to implement.