Agari has been working diligently to stop the abuse of email since its founding in 2009. By driving increased adoption of DMARC email authentication, Agari (and the industry as a whole) has made it much harder for criminals and other bad actors to forge email identity. DMARC has been a key part of this success and its importance continues to grow — for validation of this refer to the recent Binding Operational Directive 18-01, which calls for mandatory DMARC adoption within the US Federal government.
Trade-offs with DMARC Email Authentication
For an organization that has a strong brand presence with the general public, or an important email program, the benefits of DMARC are clear. It stops the fraudulent use of their domains. Yet while this is very effective, there remain cases where this doesn’t work very well and ISPs and SEGs override DMARC to ensure legitimate mail is delivered. These most often involve intermediaries (such as forwarders or mailing lists). Organizations facing the oppressive threat and impact of fraud are willing to live with the collateral fallout of blocking mail where authentication has been broken by an intermediary, but many smaller groups are not.
We’ll take the opportunity in this blog series, to outline some enhancements to the protocols surrounding DMARC email authentication that address this problem which should help increase the use of authentication and secure email communications.
“You Broke my Mailing List!”
One refrain widely heard, especially among long-time operators of email, is their mailing-list (perhaps one that has been in operation for multiple decades without issue) is now struggling to deal with DMARC-enabled domains. The problem is that in certain cases, mailing lists will break authentication. DMARC relies on SPF and DKIM, both of which will fail when a message is sent by an “unauthorized server” and has its content modified. Of course, lists can be configured to use a generic From: address which keeps authentication from breaking—at least this is possible even though many senders don’t do this. This is something an emerging protocol, ARC, will help address. This will be discussed in an upcoming entry in this blog series.
Weak Cryptography
DKIM relies on several cryptographic primitives for its protocol definition. One example in particular is the use of the SHA1 hash algorithm. Web Browser vendors have already started considering SSL certificates invalid that are still using SHA1. DKIM has had support for SHA-256 (a stronger hashing algorithm) for some time now and it is time for DKIM verifiers to stop supporting SHA1 before weaknesses are actively exploited. We’ll talk about this change and several others proposed when discussing DCRUP.
