If the news wires are to be believed, the death of spam is imminent. Again! (In 2004, Bill Gates famously remarked that spam would be a thing of the past by 2006.) Now, the Big internet providers are joining forces to kill it DEAD!! The following article is from Sophos and does the best at explaining the plan so I’m providing the entire article.
The prospective savior this time round is a recently-proposed internet standard called DMARC, or Domain-based Message Authentication, Reporting & Conformance.
With Microsoft, Google, Facebook, PayPal, LinkedIn, Bank Of America and others behind it, this new kid on the anti-spam block has been reeling in coverage, with breathless headlines like this:
* Google, Microsoft Say DMARC Spec Stops Phishing
* Google, Facebook, Microsoft in PHISH-FIGHTING smackdown
* [DMARC] could dramatically slash the amount of spam received by hundreds of millions of people
If you’re responsible for the mail infrastructure in your organisation, you might be a little sceptical at this point. You’re probably asking yourself, “What happened to SPF and DKIM, which themselves were going to be the scourge of spammers?”
SPF stands for Sender Policy Framework. It allows an organisation to make a public declaration about which servers are authorised to send email on its behalf, thus – in theory – making phishing emails from imposters trivial to spot.
DKIM stands for DomainKeys Identified Mail. It allows an organization to add a cryptographic signature to outbound email, thus – in theory – allowing an email to be validated against its sending domain.
The answer to your skeptical question about DMARC is that it doesn’t replace SPF or DKIM, and it doesn’t replace your current email security and control solution. In fact, it is predicated upon them, to the point that DMARC’s official first step in its implementation guidelines is:
* Deploy DKIM & SPF. You have to cover the basics first.
And this begs the question, “How well are we doing with SPF so far?”
Let’s take a look. I’ll simplify greatly, but not, I hope, excessively.
SPF records are published using the Domain Name System (DNS). They declare which servers can, and which cannot, be considered official senders for a domain’s email. Like this, for example.org:
v=spf1 +a:mx1.example.org +a:mx2.example.org -all
Interpreting this is easy. It means, “Email from the named servers mx1 and mx2 is genuinely ours. All other email claiming to be from us is bogus. Thanks for listening.”
If I receive email purporting to come from example.org, I can unashamedly discard it unless it originates from one of the two named mail servers. In theory, it really is as easy as that.
The problem, in practice, is not that SPF has so far lacked a protocol layer on top of it to help you manage and tweak it usefully, which is most of what DMARC is about.
The problem is that few organizations have actually had the guts to use SPF to make a definitive statement about their email practices. They have paid SPF little more than lip-service.
To be of any real use, an SPF record must end with the word “all”. This tells people what to do with email which doesn’t come from one of your official servers. There are exactly four possibilities. With their official SPF name-codes, they are: +all (PASS), ?all (NEUTRAL), ~all (SOFTFAIL, somewhere between NEUTRAL and FAIL), and -all (FAIL, so block all offending emails).
Let me translate these SPF affirmations into my own name-codes, and into straightforward English:
| +all | DOH_EXCLAMATION | Go on, spoof my domain! I don’t really get this internet thing. |
| ?all | DONT_CARE | I’m ambivalent about other people spoofing my domain, but I’ve read enough to know that +all looks silly. |
| ~all | PRETEND_TO_CARE | Although I’m against phishing, I don’t have the guts to be definitive. But I want to look better than the sort of person who would write ?all. |
| -all | LISTEN_UP | You have my official list of email servers. All other email is bogus. Thanks for listening. |
Now let’s take the fifteen DMARC contributors whose logos feature on the DMARC promotional page, and see where they stand on SPF. Remember, as DMARC says, you have to cover the basics first:
* agari.com: -all
* americangreetings.com: -all
* aol.com: ?all
* bankofamerica.com: ~all
* cloudmark.com: ~all
* comcast.com: no SPF record
* facebook.com: -all
* fidelity.com: -all
* google.com: ~all
* linkedin.com: ~all
* microsoft.com: ~all
* paypal.com: ~all
* returnpath.net: ~all
* trusteddomain.org: no SPF record
* yahoo.com: no SPF record
Doesn’t bode too well, does it? Three no-shows, one DONT_CARE and seven PRETEND_TO_CAREs out of fifteen.
Does this mean DMARC is useless?
No. There are some good things in there.
Firstly, DMARC provides a means for recipients to report potentially out-of-policy emails to senders (whether they’re blocked or not), thus helping senders gain confidence to move from PRETEND_TO_CARE to LISTEN_UP.
Secondly, DMARC provides a way to apply policy rules only in a random subset of cases, thus helping senders test the effectiveness of policy changes before making them live to the whole Internet. (Your change control committee will love this.)
But will DMARC be the end of phishing and fraud in email?
Source: Sophos (Naked Security)