DMARC Support

[norwayfinland]

Organizations who send messages to ops-trust with a published DMARC policy may experience delivery issues to list recipients due depending on the recipients local policy or the DMARC policy of reject and/or quarantine.

Mailman has addressed this issue by "munging" messages for senders who have a DMARC policy of reject and/or quarantine. This is described at http://wiki.list.org/DEV/DMARC

It is my recommendation that senders who have a DMARC policy published have their messages munged by rewriting the originator From: header with the posters name 'via the list' and the list's address and merge the original originator from poster's address into Reply-To:

[massar]

We'll go for the first option: 8<-------------- Munge the From: header - The obvious way to avoid a DMARC rejection is to munge the From: header so it doesn't contain the domain that triggers the DMARC rejection. Essentially, the Mailman server would take ownership of the message and would inject its own address into the From: header. This breaks reply-to-sender, although we might be able to add the original sender address in another header, or in the Reply-To header to reduce the impact of this. ------>8

Note that we currently do not (auto-) detect that a From address is DKIM/DMARC/SPF protected. But one can set the "Email hiding" option in the Edit Contact page (hide_email column which is per user) to enable the "hiding" of the email address.

As such, the primary thing that might be useful to do is for the software to check + cache if DKIM/SPF is enabled for a From: header and if that is the case automatically rewrite the header.

[morrowc]

On 03/17/2015 10:33 AM, Jeroen Massar wrote:

We'll go for the first option: 8<-------------- Munge the From: header - The obvious way to avoid a DMARC rejection is to munge the From: header so it doesn't contain the domain that triggers the DMARC rejection. Essentially, the Mailman server would take ownership of the message and would inject its own address into the From: header. This breaks reply-to-sender, although we might be able to add the original sender address in another header, or in the Reply-To header to reduce the impact of this. ------>8

Note that we currently do not (auto-) detect that a From address is DKIM/DMARC/SPF protected. But one can set the "Email hiding" option in the Edit Contact page (hide_email column which is per user) to enable the "hiding" of the email address.

As such, the primary thing that might be useful to do is for the software to check + cache if DKIM/SPF is enabled for a From: header and if that is the case automatically rewrite the header.

Don't we have to potentially re-write all messages though? dmarc will still barf (depending on none/reject/quarantine/etc) if the message comes from 'unfix.org' email address, but not a valid unfix.org mailserver... right?

[massar]

Don't we have to potentially re-write all messages though?

Only ones sourced from From's that have either SPF or DKIM enabled.

Toggling hide_email does that today.

dmarc will still barf (depending on none/reject/quarantine/etc) if the message comes from 'unfix.org' email address, but not a valid unfix.org mailserver... right?

DMARC will only barf if either DKIM or SPF fails and the policy is set to reject. Few hosts have that.

Note that (very minimal): SPF = Source-IP check, always fails unless they add ops-t SPF records DKIM = Signature => fails because of footer addon / subject modification DMARC = policy enforcement of DKIM +/ SPF + reporting (the reporting is the funny bit, one can see

And now you say it, I should probably enable hide_email for my domain; though it is not enforcing SPF/DKIM yet though and I have not seen any bounces. Likely as most folks use SPF/DKIM for scoring, not ultimate rejects.

[morrowc]

On 03/17/2015 11:15 AM, Jeroen Massar wrote:

Don't we have to potentially re-write all messages though?

Only ones sourced from From's that have either SPF or DKIM enabled.

Toggling hide_email does that today.

dmarc will still barf (depending on none/reject/quarantine/etc) if the message comes from 'unfix.org' email address, but not a valid unfix.org mailserver... right?

DMARC will only barf if either DKIM or SPF fails and the policy is set to reject. Few hosts have that.

'have that, today'... I was arguing that shortly (2 yrs?) we'll see more and more p=reject, I bet.

Note that (very minimal): SPF = Source-IP check, always fails unless they add ops-t SPF records DKIM = Signature => fails because of footer addon / subject modification DMARC = policy enforcement of

I don't think the footer does us in, it's mostly the subject change... I don't think anyone's signing over the body for DKIM, are they? oh... bh= body hash, wow. that sounds like crazysauce.

DKIM +/ SPF + reporting (the reporting is the funny bit, one can see

And now you say it, I should probably enable hide_email for my domain; though it is not enforcing SPF/DKIM yet though and I have not seen any bounces. Likely as most folks use SPF/DKIM for scoring, not ultimate rejects.

--- Reply to this email directly or view it on GitHub: https://github.com/ops-trust/portal/issues/50#issuecomment-82403201

[massar]

For DKIM, we just check if there is a "Dkim-Signature" header in the mail. If that is there, we can enable the hide_email from automatically.

For SPF we'll have to do DNS queries for (and if there is a single TXT record with SPF, then we can assume that SPF does not include our records), and then enable hide_email.

We won't check for DMARC though as either of the above already signals if hide_email is needed.

[vixie]

let's have a call on this, please. if dmarc can't work with ops-t, then we need a more complete re-think, not a patch or an option.

[norwayfinland]

Ops-T doesn't break SPF since SPF is defined in RFC 7208 as checking the envelope from, not originator from, so this is never an issue with respect to message composer to the list since envelope from is the Ops-T MTA and the recipient MTA will process SPF for the envelope from (return-path) for the SPF record defined by Ops-T. It does however break DKIM and DMARC; DKIM because of folks doing DKIM strict and the message modifications don't match the signature and DMARC due to the coupling and required matching of the envelope from and originator from domains.

Anyone sending to Ops-T with a DMARC policy will get reports. Those sending to Ops-T with a p=reject or p=quarantine will potentially end up with rejected or quarantined messages by list recipients who honor and enforce DMARC.

Finally, I am more than happy to help test the configuration changes in any way I can to help this effort inclusive of changing "production" DNS records.

In summary:

SPF = Ok (Envelope From = Ops-T, Originator From = Composer) DKIM = Breaks due to message signing not matching since DKIM header is still present but message has been "tampered with" DMARC = Breaks, for the reason DKIM breaks plus the broken association of Originator From domain matching Envelope From domain.

Hope this helps explain better my friends.

• Edit; fixed typos and transpositions.

Cheers, NF

[vixie]

by that description, we need to change the header From: to be the mailing list, elide the header To:, and set the Sender: to be the originator of the message? ok, in that case, we should change the "hide_email" behaviour to mean this rather than what it means now, since that would also fix the problem hide_email was created for.

[norwayfinland]

Paul, having not yet tried hide_email, if this feature conceals the identity of the sending person this might could cause unintended issues not of a privacy-centric nature. The unique challenge is the sole creation of the composer's email address in the Reply-To creates a "Reply-All" situation in that the list recipient's client MUA reply must be "Reply All" so that it is directed at both the list and the composer, the addition of both the list and composer in Reply-To creates a default recipient client MUA "Reply All" effect, and the lack of inclusion of composer in any of the originator fields creates no way to directly address the composer by the client MUA unless the composer self-identifies in the body of the message and the client MUA or client MUA reader "manually" processes it.

The very unique challenges of DMARC that align envelope headers with originator headers...

[norwayfinland]

Perhaps the solution is allowing the Ops-T composer to select their preference since some composers may not mind client MUA received response duplicates, others would dislike client MUA received response duplicates, and others would be fine with list-only traffic and no potential for composer reply received duplication. This creates a solution that would be amiciable to all current ways to address DMARC with respect to mailing lists that are known at this time with respect to handling client MUA reply traffic.

Hope this makes sense, hard to speak intelligibly about directivity.