[Clo-devel] Modern internet mail rules and mailing list Subject rewriting

Mark Evenson evenson at panix.com
Wed Feb 4 13:40:40 UTC 2015

> On 04 Feb 2015, at 13:46, Erik Huelsmann <ehuels at gmail.com> wrote:
> Hi,
> Monitoring the mail system, I've found that Google still has us rate limited. Trying to understand why, I've come up with the following reason:
> Google verifies DKIM as part of their criteria for identifying SPAM. We sign our outgoing mail, so, there shouldn't be a problem. However, some mail *already* has a DKIM signature. Still no problem, but most mailing lists change the Subject: line by prepending the mailing list name.
> Now *that*'s a problem: it invalidates the pre-existing signature! So, simply strip the old DKIM headers, you might say. That will make the problem go away. Well, in fact it probably doesn't: domains which use DKIM can also state a policy that all mail from the domain should be signed. Stripping the DKIM signature makes the mail invalid with respect to that policy, again triggering the SPAM rules.
> My conclusion: we have to stop munging the Subject: line in the mailman mailing lists.
> Any comments?

mailman also adds a “footer”, like 

> Clo-devel mailing list
> Clo-devel at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/clo-devel

so we need to do more than just stop re-writing the subject line.  

From [wikipedia] [1]:

These problems are exacerbated when filtering or relaying software adds actual
changes to a message. Although legitimate, the footer addition operated by most
mailing lists and many central antivirus solutions, formally, are exactly the
kind of message tampering that DKIM has been designed to guard against. The
solution is to whitelist known forwarders, e.g. by SPF. Alternatively, a
forwarder can verify the signature, modify the e-mail, and re-sign the message
with a Sender: header. However, it should be noted that this solution has its
risk with forwarded 3rd party signed messages received at SMTP receivers
supporting the RFC 5617 ADSP protocol. Thus, in practice, the receiving server
still has to whitelist known message streams, i.e. by DKIM.

[1]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."

More information about the clo-devel mailing list