Comment 5 for bug 1589693

Revision history for this message
Thomas Ward (teward) wrote : Re: Make Launchpad DMARC Compliant to avoid Launchpad mail considered spam

Forgive me for a very blunt statement, but in reply to wgrant's statement about LP being compliant, it actually *isn't* being compliant. Simply altering "Sender" field and then implementing no changes to the "From" field is going to trigger any and all DMARC rules that have either a QUARANTINE or REJECT policy in place.

In having to handle DMARC compliance on a listserv implementation, and doing some heavier-duty testing with my DMARC compliant mail server(s), I discovered that not only does the Sender address and the outer Envelope have to not be from the DMARC-compliant addresses, the From field in headers is *also* verified, and can (and usually will) result in a failure case for all DMARC policies which restrict mail.

A large number of companies and groups implement strict DMARC handling, of which Launchpad will be noncompliant for in the future.

A prime example of this is a message sent by Launchpad today to the user 'nacc' which addressed the email as from me, because of my reply to a merge proposal made by them on something, and my critique on how they could fix an issue in that proposal. The relevant header bits are here:

Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of bouncesATcanonical.com designates 91.189.90.7 as permitted sender) smtp.mailfrom=bouncesATcanonical.com;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=trekweb.org
...
From: Thomas Ward <email address hidden>
Sender: bouncesATcanonical.com

DMARC only cares about SPF and DKIM; it does not specifically care about whether messages were handled with TLS or not. Specifically, it wants the SPF of the sender and the DKIM of the "From" address to both validate properly. SPF passes because the Sender SPF records match properly with Canonical's SPF records. DMARC however fails because the domain trekweb.org publishes a DKIM record, and the DKIM signature does not match.

In *most* ListServ implementations that are DMARC compliant, there sits a mechanism to replace the "From" address with the address of the ListServ itself (sometimes with the raw mail header of "From: John Smith <listserv_AT_domain.com>", and sometimes a Reply-To of either the actual originator. The "From" field, therefore, validates against the domain of the listserv / system itself and *not* the actual originator. This solves the DMARC Compliance issue, as DMARC then checks the domain of the system itself (in this case, it would be canonical.com) and that will not fail.

Perhaps a setting could be added to user settings that would be "mask email address in notifications", which would then under the hood set the From header to be something like "User Name <bouncesATcanonical.com>" instead of the original from address?