Mailing List Message #106248
From: Bill Cole <>
Subject: DMARC (WAS: Re: Temporarily blocked...not)
Date: Sat, 29 Oct 2016 20:50:31 -0400
To: CommuniGate Pro Discussions <>
X-Mailer: MailMate (2.0BETAr6058)
On 27 Oct 2016, at 12:27, Palvelin Postmaster wrote:

My question was more rhetorical than anything. I don’t see it as a viable practice to include various mailing list servers (beyond my control) as my trusted senders.

Absolutely. For anything larger than a personal vanity domain, this would be unworkable. Fortunately, it also would be worthless since SPF isn't relevant in this case and messages on this list already pass SPF checking. SPF checks the envelope sender address, which is There is no DMARC record which "aligns" to that address.

The rejection is because the DMARC record for includes the tag "p=reject" which means a message with a From header with a address MUST have a valid DKIM signature with an "aligned" DKIM selector. There is no DKIM signature on your messages as they come out of the list. Either you are not signing messages or the list server is stripping out the signatures. Also, CGP assigns its own Message-Ids to list messages and for this list adds a Reply-To, which would break most DKIM signatures.

Couldn’t one instead argue that mailing lists are ”broken” in this regard? :)

Mailing lists were here first. :P

Beyond that, section 10.5 of RFC7489 (which defines DMARC) makes it clear that DMARC is known to be incompatible by design with standards-compliant behaviors and references RFC6377, which discusses the many ways common useful mailing list behaviors may break DKIM signatures. RFC6377 excuses this by pointing out that a bad DKIM signature is supposed to be equivalent to no DKIM signature at all and recommends that personal mail that might go to a mailing list not be subjected to a ADSP policy (the failed predecessor to DMARC) that would cause rejection of unsigned messages because of the diverse breakage modes.

I don’t think DMARC and SPF are going anywhere but instead becoming more popular.

Well, SPF (even with "-all") doesn't break robust mailing lists, it just breaks the traditional local ~/.forward files and alias forwarding mechanisms, which have a bunch of other intrinsic problems when done across administrative boundaries and have been dying out as a result anyway. SRS can be used to prevent those SPF failures, but it can't save sites from the consequences of forwarding uncaught spam to GMail, Office365, or other mail systems where spam sources get blocked robotically. Because SPF is essentially workable with ~all or even ?all, it's very useful for envelope sender whitelisting, and is essentially required for reliable deliverability into some large systems, it is here to stay.

DKIM has an even better foothold because it authenticates the visible From header, isn't broken by forwarding, can survive some mailing lists, and on its own is never derogatory. Like SPF, it is a useful whitelisting adjunct. In the context of DMARC with p=none, it is indispensable for phishing feedback loops.

In contrast DMARC with p=reject is particularly pernicious in that it conflicts with behaviors that are entirely within the formal standards for mail handling and which are widespread because they are useful. It should never be used for mail generated by humans unless the intent is to prevent them from participating in discussion mailing lists  based outside of their own domain and from using a wide range of other facilities that send mail "From" a user as a trick to avoid blowback. It is worth noting that the primary adopters of p=reject for email domains handling personal mail are huge freemail providers who have a complex of business interests in keeping their users within their own online ecosystems. It is notable that those proprietary ecosystems include alternatives to traditional Internet many-to-many mailing lists. For example, Yahoo has Yahoo Groups, which (if they had competent management) could generate substantial ad revenue. It is not surprising that they were the trailblazer among consumer mail providers in publishing a DMARC record with p=reject which they honor themselves.

That fact also points out a telling hypocrisy among DMARC users. Many domains which are publishing p=reject DKIM records do not actually implement the requested policy of mail rejection, even for their own domains. There's a pragmatic understanding expressed by that behavior: that DMARC is untrustworthy by design. Yahoo at least is consistent, albeit in a user-hostile and world-hostile way.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster