Re: PSA: Messages sent through LA mailing lists being classified as SPAM

"Joel W. Shea" <[email protected]> Thu, 14 Jan 2016 23:05:27 +1100
Newsgroups	gmane.linux.australia
Message-ID	<[email protected]>
On Thu, Jan 14, 2016 at 10:25:46PM +1100, Russell Coker wrote:
> 
> If the appended signature was the only problem then it could be fixed by using 
> the l= flag when generating the DKIM signature.

In this instance, it was the only problem, but also fixed by disabling
msg_footer (as you note below)

> There's also the modification of the Subject: header, but that's something that 
> can be fixed too.

Agreed since that field is typically signed, although in this case the
subject header wasn't signed, although that could also be fixed by
disabling subject_prefix (as you also note below)

> The biggest problem at the moment is that Mailman rewrote the DKIM signature 
> header to use spaces instead of tabs.  While it seems to be standards 
> compliant to rewrite headers like that both OpenDKIM and libmail-dkim-perl 
> will report such messages as invalid.

Except that this particular message was signed with "c=relaxed/relaxed",
so should still validate with spaces, otherwise you're right, since many
leave the default "c=simple/simple"

> If we wanted the list to pass messages with valid DKIM signatures then here is 
> what needs to be done:
> 
> 1)  Turn off Subject munging.
> 2)  Turn off the list footer.

Agreed.

> 3)  Make Mailman not munge the DKIM header - or install a milter that reverses 
> such munging (which is quite trivial in terms of message editing).

Alternatively, make Mailman reject the message with a DMARC failure
report, and hope that the sender signs with "c=relaxed/simple" to allow
whitespace variation in the header in future.

> But it's much easier to just change the From: header to the list address.

Perhaps, since even if DKIM signature verifies, DMARC will still fail
domain alignment on SPF?

Which is why there was an IETF draft for an "Original Authentication
Results" header, although that could easily be forged and signed, at
least it'd allow the concept of a "trusted forwarder", unfortunately
this didn't seem to go anywhere (AFAICT)

> It's expected that when you add new anti-spam features that there will be some 
> false positives.  But everyone else will just deal with it eventually, and 
> that includes list servers configuration being changed to work with it.

Hence the recommendation to set DMARC to p=none at first, then
q=quarantine; pct=1; then gradually increase pct, this gives the sender
an opportunity to adjust their policy to accommodate for the most common
false positive failures.

_______________________________________________
linux-aus mailing list
[email protected]
http://lists.linux.org.au/mailman/listinfo/linux-aus
signature.asc (application/pgp-signature, 473 B)