Sebastion Ricco commented about DMARCbis and DKIM2 in a recent post, and I thought it warranted its own topic. (Along the way, I learned that "bis" is Latin for "next".)
The new DMARC specification has been published as three documents 9989 (main), 9990 (aggregate reporting) and 9991 (forensic reporting).
I followed the DMARCbis mailing list for years, but failed to have much impact. My one victory was getting them to deprecate the "PCT" token, because it asks receivers to lower their security while accomplishing nothing for accuracy.
The substantive difference is the Tree Walk algorithm, which walks up the DNS tree to look for a DMARC policy, instead of using the Public Suffix List (hereafter "PSL").
Lingo:
A "public suffix owner" is an entity chartered by IANA to manage a name space, such as ".com", ".net". and ".co.uk". A "private suffix owner" is an entity that offers subnets to clients. "OnMicrosoft.Com" is the most frequently encountered private suffix, but there are others The PSL attempts to include both, but it only accepts enrollment if the suffix owner requests to be listed. All of the IANA-sanctioned suffixes should be listed, but private suffixes may be missing. "OnMicrosoft.Com" was not in the list the last time that I checked. SmarterMail has added a few entries to their distribution, in response to my requests. "OnMicrosoft.com" is one of them.
DMARC assumes an organization is the name which appears one level below a listed suffix. (For example, "Example.Com" is an organizational domain because ".com" is in the PSL.)
If a private suffix is missing from the list when you use it to check alignment, you may get a false DAMRC Pass. For example "attacker.onmicrosoft.com" would appear to have relaxed alignment with "victim.onmicrosoft.com".
The Arguments for abandoning the PSL
- The PSL was created to help browsers defend against cross-site-scripting (XSS) attacks, and their concept of an organizational boundary is sometimes different from the boundaries needed for email usage. The maintainers of the list want DMARC usage to go away.
- There is not one version of the PSL. You download a copy and run your own local copy. This means that you do not need to worry about network connectivity or remote server load. But it also means that everybody has a different version of the list, based on when they last downloaded the file and what local edits they have performed. This is technically inelegant, because it means that senders cannot be certain of consistent results by all recipients.
- The new design allows huge organizations to define lower-level organization boundaries, to provide more granular control of relaxed alignment.
My objections to the new algorithm:
- Walking the DNS tree is more processing steps than doing a table lookup on a local copy of the PSL. Speed matters when processing email.
- There are still ways that the Tree Walk can produce false pass. Private suffix owners are expected to publish a flag field in their DMARC policy, so that the Tree Walk knows when to stop. If it is missing, the false sibling problem will still occur.
- A DNS timeout at any step in the Tree Walk will render the effort useless. This concern would be unimportant if DNS timeouts were rare, but I have data from multiple sources which indicate otherwise.
- Using the PSL. I can apply the DMARC test to any message, simply by applying a default alignment policy. Most messages will produce DMARC Pass, and the exceptions are worth investigating. The Tree Walk can only produce a result if a DMARC policy exists in the DNS tree, so it leaves us blind.
If impersonators would be nice enough to only attack domains with DMARC polices set to p=reject, we could block all impersonation. But since they are not nice, we need an authentication strategy which is not dependent on them being nice. This requires an authentication design which authenticates by algorithm when possible, or by local policy when that fails. When both fail, the message should be quarantined to resolve whether the message is a malicious impersonation, a benign impersonation, or a sender participation failure. DMARCbis does nothing to move us in that direction.
DMARCbis was chartered to fix the mailing list problems created by mindless application of DMARC failure disposition requests. The specification for ARC grew out of this goal, but it has been judged a failure, and an RFC to deprecate ARC is being written as we speak. The mailing list problem can only be solved with cooperation between list owners and recipient evaluators, and DMARC cannot make that happen on its own. So the mailing list problem remains.