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

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: "John Levine" <[email-masked]>
Date: 22 May 2016 03:05:34 -0000

>policy other than "p=none". (I prefer the latter.)

It's an implementation issue, depending on whether the list software
can get the DMARC policy from a DNS query or from an
Authorization-Results header.  My MTA puts an A-R header on incoming
mail so I have a shim after the list manager that looks at the A-R
header and rewrites the From: address (into dmarc.fail addresses,
which some people imagine are not deliverable) if it sees a DMARC
policy.

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

It's a one-entry MIME digest, so it looks like a digest, not an
individual message.

R's,
John

---

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: "John Levine" <[email-masked]>
Date: 22 May 2016 14:20:13 -0000

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

Brian sent me a message/rfc822 wrapped version of his message, so I
stuffed it into my Gmail, Yahoo, and Hotmail mailboxs after looking at
it in Apple mail and Thuderbird and of course Alpine.  Gmail flattens
it to look like a text forward, Yahoo loses the headers on the
wrappped message, Hotmail and Apple mail show it as an attachment you
can download, Thunderbird and Alpine show all the relevant bits, but
not in a particularly attractive way.

In practice it's worse than rewriting the From: line to the mailing
list's address, which is already far from good.

R's,
John

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 22 May 2016 08:56:24 -1000

> not in a particularly attractive way.

Let me give a "half full" view of this "half empty" glass. This experiment shows that not all UA to the right thing, but some actually do. If the "forwarded" scenario becomes important, user pressure and competition will drive more UA to improve their handling -- or more customers to switch to systems that handle such messages correctly. So there is some hope.

-- Christian Huitema

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2016 15:20:43 -0400

> Let me give a "half full" view of this "half empty" glass. This experiment shows that not all UA to the right thing, but some actually do. If the "forwarded" scenario becomes important, user pressu…

Since we already have ARC in the works to let lists keep working the way 
they always have, changes to MUAs purely to work around DMARC problems 
seem unlikely to me.

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

---

From: [email-masked]
Date: Sun, 22 May 2016 18:47:00 -0700 (PDT)

> Let me give a "half full" view of this "half empty" glass. This experiment
> shows that not all UA to the right thing, but some actually do.

Take a closer look at the list. The two UAs that John said "do the right
thing" (and I would dispute that claim in the case of Thunderbird) are
both open source. The three that don't are the three of the larget, if not
the largest, service providers. 

This also ignores the entirely one-sided history in this area. Message formats
that provide the ability to represent a forwarded message in its entirty go
back to at least ~1980 (NBS format followed by X.400), long before MIME.
And in the past 35 years there have been many attempts to use 
message encapsulation for various purposes - the obvious ones is delivery
status notifications and message disposition notifications, which are
in fact currently used at scale.

And yet client ability to display such things in any sort of sensible way
just hasn't happened.

Given the importance of knowing why a message didn't get delivered
you'd think clients would support this better. But they don't.

So you'll have to forgive me for thinking your "half full" view here
is hopelessly optimistic.

				Ned

---

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