Subject: [dmarc-ietf] Last Call: <draft-ietf-dmarc-interoperability-15.txt> (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 20 May 2016 06:42:05 -0700

The IESG has received a request from the Domain-based Message
Authentication, Reporting & Conformance WG (dmarc) to consider the
following document:
- 'Interoperability Issues Between DMARC and Indirect Email Flows'
  <draft-ietf-dmarc-interoperability-15.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-06-03. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 May 2016 11:08:47 +1200

This is useful.

> 4.1.3.3.  Mailing Lists
> 
>    [RFC6377] provides some guidance on using DKIM with Mailing lists.
>    The following mitigation techniques can be used to ease
>    interoperability issues with DMARC and Mailing lists:

It should probably be indicated whether these techniques would be applied
to all messages, or only to messages sent from domains with a DMARC
policy other than "p=none". (I prefer the latter.)
...
>    o  Configuring the MLM to "wrap" the message in a MIME message/rfc822
>       part and to send as the Mailing List email address.  Many email
>       clients (as of the publication of this document), especially
>       mobile clients, have difficulty reading such messages and this is
>       not expected to change soon.

This seems like a quite elegant solution. I'm very surprised by the second
sentence - are these clients that have difficulty with many Content-Types
or is it a specific issue for message/rfc822?

Thanks
   Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 May 2016 12:00:19 +0100

> or is it a specific issue for message/rfc822?

Only message/rfc822. E.g. it took iOS a couple of years to start supporting it properly. And it is one of the better mobile email clients.

---

From: Franck Martin <[email-masked]>
Date: Mon, 23 May 2016 12:07:36 -0500 (CDT)

----- Original Message -----
> From: "Alexey Melnikov" <[email-masked]>
> To: "Brian E Carpenter" <[email-masked]>
> Cc: [email-masked], "Ned Freed" <[email-masked]>, [email-masked], [email-masked],
> "alexey melnikov" <[email-masked]>, [email-masked]
> Sent: Sunday, May 22, 2016 4:00:19 AM
> Subject: Re: [dmarc-ietf] Last Call: <draft-ietf-dmarc-interoperability-15.txt> (Interoperability Issues Between
> DMARC and Indirect Email Flows) to Informational RFC
> 
> Only message/rfc822. E.g. it took iOS a couple of years to start supporting
> it properly. And it is one of the better mobile email clients.

And "forward as attachment" that creates this message/rfc822 has disappeared from many clients...