|
||
|
||
DMARC is extremely useful, yet I’ve heard some vendors are putting their implementations on hold because of the IETF DMARC working group. You really shouldn’t wait though—it’s been in wide use for nearly three years, enterprises are looking at DMARC for B2B traffic, and the working group charter is limited in it’s scope for changes.
Let’s compare this to a similar situation in the past. When I was on a panel at the INBOX Conference in 2006, I told the audience—which included email appliance makers, software vendors, and email service providers (ESPs)—that they should already be offering SPF and be preparing to support DKIM, which would be finalized Real Soon Now (in fact it took another year). But I did not tell them they should be implementing DomainKeys...
DomainKeys had been announced two years earlier and was an effective technology, but it was not widely deployed—a number of senders were using it, but few mailbox providers or companies were using it to filter inbound messages. Meanwhile the IETF DKIM working group was creating something different from and incompatible with DomainKeys. So the decision to wait for the DKIM working group to finish was reasonable.
Today, the circumstances around DMARC are very different. DMARC has been filtering the email sent to over 80% of consumer mailboxes in the US alone for almost three years now, and over 80,000 active domains have published DMARC records. It’s already popular with saavy email senders and domain owners for the light it sheds on where email using their domains is coming from. And just as enterprises became enthiastic users of TLS for B2B email, DMARC is being evaluated as an additional protection for sensitive B2B email channels.
The IETF DMARC working group is chartered to fix some important interoperability issues with forwarded email, mailing lists, and other “indirect” mailflows. However the working group is not chartered to make major changes to the protocol, the way the DKIM working group was—maintaining interoperability with existing implementations is a key objective.
Several vendors and services have already integrated DMARC filtering into their products (list at dmarc.org), and you can bet more have it in the pipeline. So if you’re planning the next release of your email appliance, MTA, or related software, you should make sure you’ve got DMARC support in the works too.
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byVerisign
A World-Renowned Source for Internet Developments. Serving Since 2002.
Implementing and deploying certainly differ. It takes something of an effort to implement DKIM, given the intricacies of crypto-software. Deploying it is quite a breeze, since it suffices to just exercise signers and verifiers. Almost a no-op.
ADSP was standardized as a policy built on top of DKIM. It was demoted to historic after recognizing that several domains publish policies that are inadequate for the intended use of rejecting or silently discarding mail which fails DKIM verification. The lookout for DMARC might have had some influence in the decision to demote, but the objective reasons were rather about malfunctions in the face of inappropriate configurations.
Those same reasons, namely the adoption of inappropriate DMARC policies by some of the major mailbox providers, started the discussion that led to a IETF working group. The charter recognizes that “DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox”.
That state of affairs is troublesome for a mail-software supplier. Technically, it is not difficult for a package which already uses DKIM and SPF to also implement DMARC. However, I don’t have the guts to release a feature while heartedly recommending to not enable it. I already did so with ADSP, and wouldn’t do the same mistake twice. I didn’t build-in DMARC when I released my filter a few days ago. I want to get indirect mail whitelisting straight before enabling DMARC.
Any author or vendor has to make the decision about implementing DMARC filtering in their product based on their circumstances, and their understanding of their users’ needs. Clearly as the author of the ZDKIMFILTER package you should, and did, exercise that discretion.
As you briefly touched on though, there’s a difference between shipping a feature enabled by default versus having it available for those who understand the trade-offs. You made a decision based on your understanding of your users, the support burden it might generate for you and/or them, etc - just as you should. However others may draw different conclusions based on their circumstances and customers.
My advice to those vendors selling gateway software and appliances is still to start building in DMARC support now, if they haven’t already - and at least seven commercial products have shipped with DMARC filtering support, one of them over 14 months ago (see Message Gateways, Filters, &c;). While some customers may be receiving too many indirect mailflows to consider enabling inbound DMARC filtering, there are plenty of others - notably enterprise and other business customers - who are interested in doing so.