Recent Posts

Yahoo Statement on DMARC policy

Yesterday Yahoo posted a statement about their new p=reject policy. Based on this statement I don’t expect Yahoo to be rolling back the policy any time soon. It seems it was incredibly effective at stopping spoofed Yahoo mail.

Dealing with DMARC for Mail intermediaries

I’ve been getting some mail and calls from folks looking for help on resolving the issue of DMARC bouncing. Some of these calls are from ESPs, but others are from SAAS providers who have users that have signed up with yahoo.com addresses and are now dealing with mail from those users bouncing, even when mail is going back too those users.
None of the solutions are really great, but here are a couple options.
1) Prohibit users users from sending with @yahoo.com header-from addresses. This will be challenging for some companies for all sorts of reasons. I have seen a number of people suggest switching to @hotmail.com or @gmail.com addresses. This only works as long as Gmail and Hotmail/Outlook don’t start publishing p=reject policies. It’s unclear if they’re even considering this at all, but it may happen.
2) Rewrite the header-from address from @yahoo.com to something you control. One thing I’ve been suggesting to customers is set up a specific domain for rewriting, like @yahoo.ESP.com. This domain would need to forward mail back to the @yahoo.com users, which does add another layer of complexity as these addresses will become spam magnets. Thus the forwarding IP should be on a distinct and separate IP, to prevent interference with other systems. Note, too, that any users sending to these reply addresses from a domain protected by DMARC p=reject will bounce.
If you have questions or want to ask specifically about what to do in your setup, I’ve blocked out some time in my schedule next week for companies. If you want more information about this please contact me to for available times, information requirements and pricing.

Yahoo DMARC articles worth reading

There are a bunch of them and they’re all worth reading.
I have more to say about DMARC, both in terms of advice for senders and list managers affected by this, and in terms of the broader implications of this policy decision. But those articles are going to take me a little longer to write.
How widespread is the problem? Andrew Barrett publishes numbers, pulled from his employer, related to the number of senders using @yahoo.com addresses in their commercial emails. Short version: a low percentage but a lot of users and emails in raw numbers.
What can mailing list managers do? Right now the two answers seem to be stop Yahoo.com addresses from posting or fix your mailing list software. Al has posted how he patched his software to cope, and linked to a post by OnlineGroups.net about how they patched their software.
A number of people are recommending adding an Original Authentication Results header as recommended in the DMARC.org FAQ. I’m looking for more information about how that would work.
For commercial mailers, there doesn’t seem to be that much to do except to not use @yahoo.com address as your header-From address. Yes, this may affect delivery while you’re switching to the new From address, but right now your mail isn’t going to any mailbox provider that implements DMARC checking.
One other thing that commercial mailers and ESPs should be aware of. Depending on your bounce handling processes, this may cause other addresses to bounce off the list. Once the issue of the header-From address is settled, you can reactivate addresses that bounced off the list due to authentication failures since April 4.

Fixing discussion lists to work with new Yahoo policy

Al has some really good advice on how to fix discussion lists to work with the new Yahoo policy.
One thing I would add is the suggestion to actually check dmarc records before assuming policy. This will not only mean you’re not having to rewrite things that don’t need to be rewritten, but it will also mean you won’t be caught flat footed if (when?) other free mail providers start publishing p=reject.

If you have servers using SSL, read this

I was going to post about SSL certification and setup today, but the security world got ahead of me.
Recent versions of openssl – the library used by most applications to implement SSL – released over the past couple of years have a critical bug in them. This bug lets any attacker read any information from the process that’s running SSL, reliably, silently and without leaving any trace on the compromised server that it’s happened.
What’s so dangerous about that? As well as things like usernames, passwords, private email and so on, this lets the attacker take the private key for your SSL certificate. Once they have that private key, they can run a server that pretends to be you, even over SSL, opening up all sorts of shenanigans.
There are more details at heartbleed.com – but the short form is that you should check the version of openssl on all your servers – if it’s running openssl version 1.0.1 through 1.0.1f, it’s vulnerable.
You should obviously upgrade to openssl 1.0.1g on vulnerable machines, but given the scope of the potential attack you might want to consider the information on them already compromised. If so, that’d mean replacing the SSL certificates and changing any passwords the affected services have access to (both user passwords and any service passwords, such as database credentials).

Example bounces due to Yahoo p=reject

There are a number of different bounces that people are reporting due to Yahoo publishing a DMARC record of p=reject. I decided to put some of those bounces here so confused users could find out what they needed to do.
Comcast

A brief DMARC primer

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. What DMARC does is allow domain owners to publish policy statements in DNS telling receiver domains what to do with messages that do not authenticate. In addition, DMARC introduces the concept of “domain alignment.” What this means is that the authentication has to be from the same domain (or a sub-domain) as the address in the header-from: line. The idea behind DMARC is that organizational owners can use SPF and DKIM authentication to authenticate their actual domain in the header-from line. This moves authentication from a important but behind the scenes technology out to an end user visible technology.

Welcome to our new site

We’re very excited and pleased to launch our redesigned website and blog.
As you can see, we have a new logo and an official color scheme. In addition to the cosmetic changes, we’ve improved the underlying structure. We have pages dedicted to our offerings, including Abacus and information about our consulting services.
We’ve also consolidated a lot of the information spread across different website. The ISP Information page is updated and current (finally! all the Goodmail references are gone). And the ISP specific pages are here instead of over on the wiki.
Two features we’re quite excited about are our wiseWords and wiseTools.
wiseWords is our place to publish more in depth articles about email, delivery and the Internet than the blog. Over time, I expect this to grow to encompas a full email knowledge base. We’ve also published some white papers for download.
wiseTools is the umbrella for our useful email tools, including the tools published at emailstuff.org. They’re still at emailstuff.org, but they’re also here at tools.wordtothewise.com.
We’ve done our best to make sure links transfer from the old site to the new one, but feel free to contact us if you find a broken link.
You may find your first comment on the new blog goes into moderation the first time you post. But once you’ve been approved, comments won’t go through moderation a second time.
Our new website is just the first of many new things we are hoping to roll out in the coming months.

Marketers, we have a problem

And that problem is security.
Much of what marketing does is build profiles of customers by collecting huge amounts of data on every customer. That data collection is facilitated by compliant customers that provide all sorts of personal data just because they’re politely asked by a retail clerk.
There will always be people who comply with data requests, but I expect more customers to be wary of sharing information at the register.
I’m not the only one, a recent NY Times blog post from one of their security researchers: Stop asking me for my email address. She discusses how much information companies ask for and how complacently consumers hand it over without asking about security.

Spamtraps, again.

The DMA and EEC hosted a webinar today discussing spam traps. Overall, I thought it was pretty good and the information given out was valuable for marketers.
My one big complaint is that they claimed there were only two kinds of spam traps, and then incorrectly defined one of those types. They split spam traps into “pristine” and “recycled.” Pristine traps were defined as addresses that never belonged to a user, but were seeded out on the internet to catch people harvesting addresses off websites.
While dropping addresses on websites is one way people create spam traps, there are uncounted numbers of traps that receive spam (even from some big name brands) that have never been published anywhere. One very common source of trap addresses is Usenet message IDs. I don’t think anyone can really say these were seeded in an effort to catch people harvesting, they were part of posting to Usenet. Another common source of trap addresses is spammers creating email addresses; they take the left hand side of every address on a list and pair that with all the unique right hand sides of the same list. Massive list growth with a chance that some of those addresses will be valid.
I’ve talked about different kinds of spamtraps in depth previously and how the different traps are used in different ways. I also talked about how those different types of traps tell the recipients different things.
Another critical thing to remember about traps is they are not the problem. Spamtrap hits are a symptom of a larger problem with your list acquisition process. Every spam trap on your list is a failure to actually connect with a recipient. If you’re using an opt-in method to collect addresses traps mean that either a user didn’t really want to opt in or you managed to not accurately collect their information.
One of the things I get frustrated with when dealing with potential customers is their laser like focus on “getting the traps off our list.” I really believe that is not the right approach. Just getting the traps off is not going to do anything to improve your delivery over the long term. Instead of focusing on the traps, focus on the reasons they’re there. Look at how you can improve your processes and address collection so that you actually get the correct addresses of the people who really do want that mail.
Other posts about spam traps