Can mails that fail DMARC be handled some other way than a central quarantine

[DavidWestlund01884]

Right now, there are only three possible alternatives to handle mails that fail DMARC verification:

* Let through.

* Put in central quarantine.

* Reject.

These options are too limited. For example, many email lists still break DMARC verification, requiring whitelisting for specific hosts and/or envelope senders. There are companies that (just like with SPF) have incorrect settings that they do not fix.

The following are some example that would make DMARC easier to handle for administrators:

* Make it possible to put mails that fail DMARC into the users quarantine instead of a central quarantine.

* Allow adding a warning to mails that break DMARC but let them through to the users.

* Make it possible to handle DMARC as a content filter. Today it is possible to manage SPF and DKIM in content filters, but not DMARC.

Is there some way to have less strict rules than rejection or a central quarantine for mails that fail DMARC, that I have not found?

BR,

David Westlund

[marc.luescherFRE]

Hi David,

I agree with you that it would be nice to have more control over DMARC and even ARC messages in the ESA. While I am aware that ARC support is on the roadmap I do not expect much for now on the DMARC side.

DMARC is a beast and it took us some month to feel confident with our results but there is no single day where we don't get any unplanned exceptions like changed DKIM keys, different IP addresses then what we have in our SPF and many more.

What we mainly have done is to create a mail policy to allow bypass of broken ARC/DMARC validation for identified hosts.

The built in DMARC whitelist is pretty much useless in this case.

We then built a set of content filters examining the SMTP authentication headers for ARC pass or fail., as it also includes the DMARC verdicts. We opted against notifying our users as most of them would be worried about more specific messages about SPF,DKIM.DMARC and ARC failing but we had some success with copying such messages into a specific quarantine for analysis and/or adding a footer with details at the end of messages for end users to see. The same information would also be in our mail_logs.

I did not have the time yet to document it all but hopefully can do that on my blog soon. This is very powerful approach to overcome some limitations the ESA has today.

-Marc

[DavidWestlund01884]

Thank you! I am looking forward for your blog post, if you get the time to write it.

What we have done so far is to create a content filter that checks the "Authentication-Results" header after dmarc=fail. Right now we have activated it for some specific domains, as a test. Before we start using it for all domains, we will have to create different filters based on the policy (p=quarantine, p=reject or p=none). We will probably also move dmarc whitelisting to its own content filter, have it set a header, and then skip dmarc checks if the header is set.

Using content filters give us the possibility to white list based on sending server, envelope address or basically anything else you can match with a content filter. So far, we have had to white list some mailing lists.

The setup seem to work. The setup will however be complicated, with many different content filters.

BR,

David Westlund

[marc.luescherFRE]

Hi David,

I think you got the twist on how to do it. This complexity is one of the reasons why we are currently testing the ARC headers for messages which have that header to make our life in DMARC verdicts easier.

Indeed you will need many message filters to deal with all possible scenarios. But this method gives you also an entry way to be able to decrypt all TLS traffic on the firewalls and use secondary headers to let ESA's do its job afterwards.

Our "innovative" ideas are one of the reasons TAC is always worried dealing with our tickets as they fear breaking things.

Will keep you posted

Marc