Return Path's Sam Masiello explains: "The genesis of DMARC was actually a private partnership between PayPal and Yahoo! and Google. They worked together in 20007 and 2008, respectively, to create a communication channel that would allow Google and Yahoo! to block all email purporting to be from a PayPal domain. It had a huge positive impact. At one point they were blocking, on average, 200,000 phishing messages a day."
DMARC takes these private agreements to the next level, creating a "scalable communication channel between every sender and every receiver and has the power to substantially reduce the damage of phishing."
DMARC appears easy to implement. It's not risk free, though. It can be used to instruct receivers to block or bulk email messages that fail or lack authentication, so a sender needs to be careful to ensure that all mail is properly authenticated. And be prepared for the oddball edge cases where authentication might fail unexpectedly.
The nerds in the crowd might recognize this as sort of a second try at ADSP, a DKIM authentication add on that was intended to accomplish something similar.
Update: Commenter Robert Mathews provided this link with an explanation of what makes DMARC different than ADSP. Thanks, Robert!
Address Validators: What are you Validating?
Laura Atkins wrote this really good post yesterday talking about email address validation, asking the question, "Can you verify email addresses in real time?" In it, she highlights her poking at a specific address verification service, immediately finding an example of how it identifies a specific handle of hers as a valid address when it isn't.
I've talked about email address validation for a long time now. Specifically, the pitfalls-- why it doesn't really do what you think it does; why it gets you blocked as a spammer by ISPs. Since 2007 (actually, longer), I've been warning people that the most common email validation methodology involves noisy SMTP transactions that land you on an ISP's "bad guy" radar. It started with SMTP VRFY, which just about every ISP now disables outright. To get around that, validation services (and spammers) moved to "faking it" via a series of SMTP commands. They walk through a sequence of MAIL FROM and RCPT TO commands (identifying who you might be trying to send a message to) without issuing a corresponding DATA command (meaning you never actually transmit a message to send). If the RCPT TO command fails, then it's a bad address. The recipient, the person you're trying to validate, never receives the message and never is the wiser. All good, right?
Wrong. When you do this, ISPs notice. You're a blazing red alarm that you might be a spammer, potentially up to no good. ISPs have long ago decided that this is spammer behavior, and they'll block you. I know from experience that Hotmail, in particular, considers this akin to a dictionary attack -- which may or may not be an accurate term for it, but that is what Hotmail has decided, so it's something you've got to deal with.
But let's set aside the technical and policy limitations that prevent this from being a success. Let's pretend everybody allowed this. When you perform this address validation, when it doesn't get blocked, what are you actually validating?
Where's the value here? I'm not seeing it.
I've talked about email address validation for a long time now. Specifically, the pitfalls-- why it doesn't really do what you think it does; why it gets you blocked as a spammer by ISPs. Since 2007 (actually, longer), I've been warning people that the most common email validation methodology involves noisy SMTP transactions that land you on an ISP's "bad guy" radar. It started with SMTP VRFY, which just about every ISP now disables outright. To get around that, validation services (and spammers) moved to "faking it" via a series of SMTP commands. They walk through a sequence of MAIL FROM and RCPT TO commands (identifying who you might be trying to send a message to) without issuing a corresponding DATA command (meaning you never actually transmit a message to send). If the RCPT TO command fails, then it's a bad address. The recipient, the person you're trying to validate, never receives the message and never is the wiser. All good, right?
Wrong. When you do this, ISPs notice. You're a blazing red alarm that you might be a spammer, potentially up to no good. ISPs have long ago decided that this is spammer behavior, and they'll block you. I know from experience that Hotmail, in particular, considers this akin to a dictionary attack -- which may or may not be an accurate term for it, but that is what Hotmail has decided, so it's something you've got to deal with.
But let's set aside the technical and policy limitations that prevent this from being a success. Let's pretend everybody allowed this. When you perform this address validation, when it doesn't get blocked, what are you actually validating?
- A verification service isn't going to know if an address is a spamtrap. It'll say that a spamtrap is a valid address, in that it accepts mail.
- A verification service isn't going to know if the recipient is the right recipient. It's not like a double opt-in (aka confirmed opt-in) process. It does no verification of consent.
- And some verification services provide false positive responses (as Laura Atkins was able to demonstrate)
Where's the value here? I'm not seeing it.
Topics:
address validation,
laura atkins,
smtp vrfy,
word to the wise
If the email’s legal, it can’t be spam. Can it?
Answering an important, and often-raised question by senders finding themselves blocked, Mark Brownlow explains that no ISP is going to let your mail through just because it is CAN-SPAM compliant. Read all about it here.
CheetahMail "Gives Up" Email Append
Over on the Email Responsibly blog, Experian CheetahMail's Ben Isaacson explains "that Experian CheetahMail believes that opt-out email appending is no longer an acceptable practice, and that marketers should no longer use this practice to acquire customer email addresses."
For those of us banging the best practices drum every day, this is fantastic news. For an email service provider like Cheetah, who has seemingly engaged and supported the practice for many years, to stand up and say yeah, it's played out, don't do it, this has to signal a major shift in the industry.
Some, but not all, email service providers have banned use of email append for some time now, and a rallying cry disaffected clients, when told not to utilize it, was often "but company X would let us do it!" The list of company Xs that would allow that sort of thing has just shrunk significantly today.
ETA 1/25/2012: Ken Magill covered this in the Magill Report this week.
For those of us banging the best practices drum every day, this is fantastic news. For an email service provider like Cheetah, who has seemingly engaged and supported the practice for many years, to stand up and say yeah, it's played out, don't do it, this has to signal a major shift in the industry.
Some, but not all, email service providers have banned use of email append for some time now, and a rallying cry disaffected clients, when told not to utilize it, was often "but company X would let us do it!" The list of company Xs that would allow that sort of thing has just shrunk significantly today.
ETA 1/25/2012: Ken Magill covered this in the Magill Report this week.
Still Delicious in 2012
Link-sharing site Delicious may have changed owners last year, but my account is still alive and chock full of deliverability-related links. Click here to check it out.
Append a keyword to a URL if you want to bookmark a certain section. For example, if you want to bookmark all of my links to Comcast or Gmail-related info, you would want to bookmark http://delicious.com/deliverability/comcast or http://delicious.com/deliverability/gmail.
Append a keyword to a URL if you want to bookmark a certain section. For example, if you want to bookmark all of my links to Comcast or Gmail-related info, you would want to bookmark http://delicious.com/deliverability/comcast or http://delicious.com/deliverability/gmail.
A Heck of an Oops
On December 28th, the NY Times sent an email, intended to go to about 300 people, out to over eight million email subscribers. At first, Times employees said it didn't come from them; it's forged, it's spam, ignore it. Many of us started to review the message source, noting proper email headers, proper links, email authentication, etc., noting that the email sure-as-heck looked to us like it was legitimately sent by the Times. Right about the same time I reviewed those headers, and came to the conclusion that it had to be legit, the Times clarified that it was an oops, and they did really send it.
That was one heck of an oops. Enough of one to actually make the mainstream media, where I'm sure you've all read about this already.
Jim Romensko gave me a good laugh today, which is why I'm posting this. Like him, I'm dying to know, what happened to the person who pulled the trigger on that email send? Is that person still employed? Sadly, the Times isn't telling.
Is this type of error career suicide? What do you think?
That was one heck of an oops. Enough of one to actually make the mainstream media, where I'm sure you've all read about this already.
Jim Romensko gave me a good laugh today, which is why I'm posting this. Like him, I'm dying to know, what happened to the person who pulled the trigger on that email send? Is that person still employed? Sadly, the Times isn't telling.
Is this type of error career suicide? What do you think?
Subscribe to:
Posts (Atom)