BLOG
Domain Assurance by Return Path
As often happens during MAAWG, email companies are announcing new products. One of the interesting ones is the new Domain Assurance product from Return Path.
Domain Assurance […] first audit a company’s email streams to be sure authentication has been properly implemented. Then, the company’s domains are added to a registry. Participating ISPs can check the registry and block any unauthenticated emails coming from the domains found there. Return Path provides on-going checks for authentication accuracy and alerts participating companies any time their brand is phished or spoofed.
While this type of authentication won’t solve phishing, it is a tool to help protect end users from malicious mail.
They claim that it will solve the phishing problem. However, I’m not sure if I fully understand the concept. Participating ISPs can check the registry to make sure that a company in the registry is sending authenticated emails? And then block the unauthenticated emails?
Why wouldn’t they simply block the unauthenticated emails without checking the registry?
I would think they would just block the unauthenticated ones, at least from domains that normally sign. Doesn’t ADSP already provide a mechanism for doing just that?
They also point to inconsistent adoption of authentication, but wouldn’t such a registry just add one more step to the process?
Al, how does an ISP know whether a domain is authenticating ALL of their mail, or just part of it? If only part is authenticated, they’ll end up blocking legitimate messages.
Joe has it right with ADSP, which provides a way for the domain owner to say (in effect) “yes, I sign all my mail, and you can discard anything that’s not authenticated.” But in order for the domain owner to feel comfortable making that decision, they’ll want to run an audit to make absolutely sure that they’re signing everything they care about — and be alerted if it looks like one of their servers is misconfigured. The same process can also identify spoofing & phishing attacks against the domain.
I wrote about ADSP in a bit more detail last year:
http://www.returnpath.net/blog/2009/03/searching-for-truth-in-dkim-pa-1.php
I think audits like that could prove to be extremely valuable, as a resource for corporate mailers to make sure it is done right, and done right the first time.
The idea of creating a registry to store information the DNS already stores is what I’m not quite understanding. Wouldn’t that add one more variable and therefore one more opportunity for ambiguity re signing practices?
If ADSP indicates to discard the mail, but the domain is not in this proposed registry, then what? If ADSP is followed regardless, what does the registry add? If not, doesn’t that in effect create one more step in a process many already find so daunting?
By the way, ADSP is also not an all or nothing value. It can be set to none, which is pretty much default. There is also a middle-of-the-road type of ADSP setting that can be used to allow third party signatures. And ADSP is how you know if a domain is authenticating all of its mail, or only some.
As one of the people involved in developing ADSP, I’d certainly like to see it succeed.
Thing is, ADSP doesn’t have a flag for “yes, I know what I’m doing” — and the ISPs we’ve spoken with are generally wary of discarding mail unless they can be certain that the person who set the ADSP discardable assertion knew what they were doing, and knows what the results of an incorrect assertion will be. With Return Path’s product, the domain owner can also get alerts when it looks like one of their servers is no longer signing correctly, or other events where they might want to take their domain off the list for a while.
And once more verifiers are checking ADSP & respecting the discardable assertion, we’ll help our clients create appropriate ADSP records to publish in their DNS.
Yeah, unfortunately ADSP doesn’t have an I know what I’m doing flag. To be frank, mainly for that very reason that you mention, I won’t discard an email based *solely* on ADSP and failed DKIM either. (But add failed SPF and it will end up in the dreaded folder :). And yes I do run the MX’s that host my personal inbox. So there definitely would be a huge value in a checkable I know what I’m doing flag.
As someone who is not a commercial sender, my fear is that authentication, and I mean authentication that ISPs will honor, could become something only bulk senders can reasonably afford. The thought of bulk taking priority over real human to human messaging, when it comes to things like inbox placement, is something rather unnerving.
On the other hand, yeah there does need to be a way to discard forgeries, and not discard the non-forged notification from one’s bank even if the latter makes a configuration oops.
Helping clients make sure their authentication is 100% is a very awesome thing, don’t get me wrong, but requiring joining a registry to have forgeries of ones domain rejected is unnerving.
If authentication has been properly implemented, Why can’t return path themselves stay from being automatically marked as spam from hotmail ?
As far as i am concerned the prices do not relate to the quality of the service.