Subject: [dmarc-ietf] A l'abordage!

From: Franck Martin <[email-masked]>
Date: Mon, 15 Apr 2013 22:20:54 +0000

Arrrr! 

Let me state a few things. You may not agree with them all but this is where my thinking is at the moment.

There is no problem between DMARC and mailing lists.
People want emails coming from the mailing lists they subscribed to
There is little spam/phishing on mailing lists as if there is, either the list admin resolve the spam source, or the members fork another mailing list

We should also document that MS-Exchange by design cannot preserve DKIM when forwarding (this statement may not be completely true, but so far it seems, please provide a counter example, I'm looking for one). Applying past logic here, then DMARC is not for transaction emails too.

Several hosting providers that break DKIM forwarding, are whitelisted as Know Forwarder, again if your users want these emails, you do what you need to do...

Now, list admins cannot remove subscribers from domain with p=reject manually. I cannot stop people from subscribing to mailing lists despite the fact I told them it would create problems. So manually does not scale. It may work now, because DMARC is still new, but don't expect everyone to get all the nuances the first time...

List software must become DMARC aware like they became ADSP aware (not!) to refuse subscription from domain with p=reject, or not treat these bounce towards the unsubscription count or send email aligned with DMARC. Is there any list software that was modified to handle ADSP, I'm curious to know? So far I feel, it is done manually because ADSP was not widely adopted (like SPF -all).

What would help list software is to recognize DMARC bounces, I think we have not standardized in our implementations the bounce message so it can be recognized by list software and ignored, so at least it does not unsubscribe people that do DMARC or ADSP rejects.

Lists have seldom DKIM signed their emails like any other domain. DMARC, as well a few others technology, are encouraging all domains to implement DKIM. Getting OAR in lists is also possible. 

List-Post or List-Id are some good candidate to be identifiers of mailing lists (not sole identifiers), but I have noticed some ESPs use List-ID, ezm does not use list-id. This is why, at the moment I don't know which one to use. I need to know more what is in the wild out there. As Tim pointed it would be nice to describe what is a mailing list and how to authenticate one....

Anyway you toss it, list software needs some new code/process.

So we are not discovering the pain with authentication and list software and some MTA implementations, it has been well documented. We are just now experiencing it to an acute level. What the pain will change, this is anyone's guess, but I don't think DMARC needs to be made more aware of mailing lists than it is today. What people needs to understand, there are mailing lists, people want the email, what best strategies to recognize safely enough mailing lists.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 03:14:38 +0200

On Tuesday, April 16, 2013 12:20 AM [GMT+1=CET], Franck Martin wrote:

> (...)
> List software must become DMARC aware like they became ADSP aware
> (not!) to refuse subscription from domain with p=reject, or not treat
> these bounce towards the unsubscription count or send email aligned
> with DMARC.

Too many things "must become" for not being a problem to begin with, don't you think?

> What would help list software is to recognize DMARC bounces, I think
> we have not standardized in our implementations the bounce message so
> it can be recognized by list software and ignored, so at least it
> does not unsubscribe people that do DMARC or ADSP rejects.

This is a nice suggestion. A special reject message could be useful (to minimize collateral damage) while "something" happens that settles "the problem" (be it the death of mailing lists, the death of DMARC, or some synthesis of them in --hopefully not-- zombified form).

> Anyway you toss it, list software needs some new code/process.

Yes, assuming DMARC newness gets the upper hand over mailing lists' incumbency.

> So we are not discovering the pain with authentication and list
> software and some MTA implementations, it has been well documented.
> We are just now experiencing it to an acute level. What the pain will
> change, this is anyone's guess, but I don't think DMARC needs to be
> made more aware of mailing lists than it is today. What people needs
> to understand, there are mailing lists, people want the email, what
> best strategies to recognize safely enough mailing lists.      

Given that you take part in this mailing list subscribing from a domain sporting a DMARC record of "p=reject", I think that you are saying it's OK for senders publishing such a policy to outsource to receivers the responsability of handling the occurrence of exceptions to said sender's policy; and you are also saying that the previous assertion is "as things ought to be" because DMARC "does not need to be made more aware of mailing lists".

Sorry, but that is such a bold abordage, to be frank.

Regards, 

J. Gomez