DMARC: End of Spam and Phishing for Good? Maybe, But Proof-of-Concept Still Needed
It was recently announced back in March of 2011 that the DMARC (Domain-based Message Authentication, Reporting & Conformance) organization, consisting of AOL, Facebook, Cloudmark, Linkedin, Band of America, PayPal and other leading organizations, proposed a new operational specification for the current email authentication infrastructure. In short, the proposal would ensure that email senders can prove they are indeed the true originator and receivers can take appropriate actions if the email is spam, junk or should just reject the email all together. The grand scheme of this new specification is to simply reduce or even eliminate spam emails, permanently.
So will this new email authentication protocol actually work? Interestingly, the new proposed changes are borrowing two fairly old email authentication technologies that have not been widely adopted by many companies and organizations, specifically the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) frameworks. Taking a deep dive approach, I will give you an overview of what they are about, their weaknesses and their flaws as a stand-alone solution:
SPF allows owners to specify IP addresses tied to a list of computers that are mapped to a domain name (for example, host computers I designated as authorized email senders on the Domain Name System (DNS) for ben.com, will only been seen by the receivers). However, it has a problem with handling forwarded email messages. This occurs when the sender changes to another ISP and simply begins forwarding emails from their original email address to other non-specified server. With the lack of end-to-end authentication, there is no true way to determine the authenticity of incoming emails as to their origin. Also, spammers can take advantage of SPF’s weakness by forging email addresses and registering those records into DNS servers in order to pass SPF checks. The other issue here is the belief that SPF acts as a spam filter, when it does not. SPF only detects forged emails and so there is still the need to have endpoint security solution on receiving hosts. More importantly, SPF is still considered experimental and is still in its development phase, according to the Request for Comments 4408 (RFC).
DKIM relies on public key cryptography based on a sender email authentication framework. This includes the digital signature, a domain name, and email contents (header and body). DKIM (usually installed in the email server) signs or encrypts the message using a private key. The public key is stored in the DNS servers where the receiver can retrieve and validate the signature by using the public key for genuineness of the sender. The whole point is to ensure that the email has not been modified in any manner and trust is attained between sender and receiver.
Problem: Forwarding once again poses a problem for DKIM. If an email using DKIM is signed, but then forwarded to another mail server (such as a Blackberry server), the message will become modified with added tags (i.e., “Sent from my Blackberry device.”). The end result will be a false positive flag given to the receiver in that the email was compromised and will most likely result in a rejection of the message. Also, in terms of availability and performance, CPU and RAM resources need to be considered when cryptographic functions are being processed on very large volumes of email. DNS servers themselves are prone to DDoS attacks, causing delays and even worse, data loss.
DMARC will attempt to close these two gaps. It will improve the assurance and guidance between the sender and receiver in order to manage failed email messages and reduce or even possibly eliminate spam and phishing attacks compared to today’s current standards. What I see as a problem in the future is lack of adoption and the persistence of spammers circumventing this new proposal. Although many leading companies have joined in, it will take a long time until all mail and DNS servers become standardized with this new protocol, mostly due to smaller organizations with lower capital adopting at a much slower rate. Email attackers could also still create a genuine DMARC complaint email for phishing attacks if crafted carefully. How DMARC will actually address this is yet to come. Nevertheless, this is one positive step in addressing an old problem that has been a thorn for almost everyone in the world.