dmarc_protection whitelist

[dpc22]

Expected Behavior

dmarc_protection From: header munging should only be used for external email addresses (for my definition of "external").

(We also use arc_feature to implement ARC signing: more about that later).

Current Behavior

We currently have the following in /etc/sympa/sympa.conf

dmarc_protection.phrase name_via_list
dmarc_protection.mode dmarc_quarantine,dmarc_reject

and advertise the following data collection only DMARC policy.

$ dig +short _dmarc.cam.ac.uk txt
"v=DMARC1; p=none; rua=mailto:[email protected]

If I was to replace "p=none" with "p=quarantine" or "p=reject" then Sympa would start to apply dmarc_protection to all of our internal email.

lists.cam.ac.uk and cam.ac.uk have the same SPF records and the same DMARC policy, so dmarc_protection From munging doesn't actually gain us very much for local cam.ac.uk email addresses. It will just confuse people.

I think that it makes sense to use dmarc_protection From: header munging for email coming into our list server which uses external domains, but leave the From: header well alone when the sender is using a cam.ac.uk domain.

I have also implemented ARC for our Sympa lists using "arc_feature". However it looks like it is down the the recipient to decide whether they want to trust our ARC signing. I would prefer a belt and braces approach, rather than switching off dmarc_protection entirely and hoping that arc_feature works in its place.

Possible Solution

I can implement this as a one line hack to .../lib/Sympa/Message.pm: sub dmarc_protect()

return if ($from_address =~ /[@.]cam\.ac\.uk$/);

dmarc.patch.txt

However getting something merged upstream would be more sensible in the long term. Thanks!