Recent Posts

Permission versus forgiveness

Stephanie at Return Path has a great blog post on permission and how permission is an ongoing process not a one time thing. There were a couple statements that really grabbed my attention.

I’ve been seeing more and more social network spam recently, mostly on twitter. In some ways it’s even more annoying than email spam. Here I am, happily having a conversation with a friend and then some spammer sticks their nose in and tweets “myproduct will solve your problem!”
It’s happened twice in the last week.
In most recent example, I was asking my twitter network for some advice on pasta making. I’ve made pasta a few times, but it’s never been exactly right. Not having an Italian grandmother to ask, I was looking for someone with experience in pasta making to answer a few questions. I was having an ongoing conversation with a friend who was helping me troubleshoot my problems. He gave me his recipe to try to see if that would work better. I thanked him profusely and replied that I would give it a try but probably not tomorrow because it was accounting day and those tend to run late. Someone replied to that tweet suggesting I try some random accounting software to make my accounting easier.
Just… No.
Interjecting product ads in a conversation may be the “acceptable” and “best practice” way to market through social networking. But, I can promise that you’re no better the guy who interrupts conversations at parties so he can hand out business cards for his affiliate program selling herbal male enhancement drugs.
Don’t be That Guy.
Update: Today’s twitter spam was from one of the email accreditation services attempting to sell me their email delivery services.

AOL transmitting 4xx error for user unknown

AOL is currently returning “451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure” in some cases when they really mean “550 user unknown.” This message from AOL should be treated as 5xx failure and the message should not be retried (if at all possible) and the failure should be counted as a hard bounce for list management purposes.
This is something broken at AOL’s end, and the guys with the magic fingers that keep the system running are working to fix it. Right now there doesn’t seem to be an ETA on a fix, though.
Even if you are a sender who is able to stop the retries, you may see some congestion and delays when sending to AOL for the time being. Senders who don’t get the message, or who are unable to stop their MTAs from retrying 4xx mail will continue to attempt delivery of these messages until their servers time out. This may cause congestion for everyone and a noticeable slowdown on the AOL MTAs.
AOL blog post on the issue
HT: Annalivia

Tagged.com and the courts

I’ve seen multiple reports of Tagged.com and their interactions on various sides of the courtroom aisle.
On the good side, Tagged.com won a judgment against a spammer sending spam to Tagged.com users. (Tagged has a post on their blog about the win, but the direct link to that article doesn’t work).
On the minus side, yet another ruling against tagged.com. They’ve been accused of sending spam, including some mail that looks like a phish. They recently settled in a CA court, agreeing to dispose of certain addresses collected during a 3 month period in 2009.

TWSD: Using FOIA requests for email addresses

Mickey has a good summary of what’s going on in Maine where the courts forced the Department of Inland Fisheries and Wildlife to sell the email addresses of license purchasers to a commercial company.
There isn’t permission associated with this and the commercial company has no pretense that the recipients want to receive mail from them. This is a bad idea and a bad way to get email addresses and is no better than spammers scraping addresses from every website mentioning “fishing” or “hunting.”

Yahoo stops offering preferred delivery to Goodmail certified email

A week ago, Goodmail notified customers about upcoming changes to the Goodmail Certification program. They wanted customers to be aware that Yahoo was going to stop offering Goodmail certified email priority delivery and guaranteed inbox placement as of February first. I’ve talked with a number of people in the industry, including representatives of Goodmail and Yahoo about this change.
Yahoo was the first to respond to my request for a comment, and offered the following statements. The decision was made at some of the higher levels of management and my contact did not participate. I was told that Yahoo was looking to have more control over their incoming mail stream. They did not want to be contractually obligated to deliver email. The Yahoo rep also told me that Goodmail was in no way responsible for the Yahoo connectivity problems over the last couple weeks.
I also spoke with Goodmail. They also stated that Goodmail was in no way responsible for the Yahoo MTA problems. They are continuing to negotiate with Yahoo and are hoping to have full functionality to Goodmail certified email at Yahoo in the future. Also, Goodmail certified email may continue to see good delivery at Yahoo, but the certification symbol will not be displayed to Yahoo users.
I do believe Goodmail is continuing to negotiate with Yahoo, but I don’t expect to see any reversal of the decision any time soon. There are a number of underlying problems here, but reading between the lines it seems that Goodmail is certifying companies that send mail Yahoo users don’t want.
Last summer a number of people in the industry told me that Yahoo had a meeting with Goodmail and told Goodmail that the quality of the mail that they certified was not up to Yahoo’s standards. At that point, Goodmail dropped a number of clients and stopped taking on new clients. One colleague believed he had a slam-dunk application that would take days to approve. Instead he chased Goodmail sales reps for weeks looking for confirmation that his employer would be accepted. Eventually, he did receive a response: his employer was not accepted and there would be a full revamping of the qualifications for the certification program.
It seems, though, that any changes implemented by Goodmail over the summer did not improve the mail stream enough for Yahoo to continue outsourcing delivery decisions to Goodmail.
Quite frankly, I am unsurprised by this. My impression of Goodmail has always been they never really understood the role of a certifying agency. For any certifying agency to be successful, they must continually monitor certified customers and enforce standards. Goodmail’s initial certification process was fine, but they never seemed to follow through on the monitoring and enforcement. I remember sitting at lunch with one of their founders a few years ago and repeatedly asking the same questions: How are you going to police your customers? What are you going to do when bad mailers come to you? How are you going to enforce your standards? The answers I received were vague and left me with the opinion that they didn’t really understand what spammers would do, or pay, to get guaranteed inbox placement. I never felt they recognized the work involved in enforcing the high standards needed to keep their ISP partners happy with their service.
What distinguishes Goodmail from other certification services is that Goodmail doesn’t make recommendations to recipient ISPs. Instead, Goodmail partner ISPs are contractually required to accept Goodmail certified email and deliver that to the ISP. In this case, it appears the certified mail did not meet Yahoo’s standards, and Yahoo ended the contract. I don’t expect Yahoo to change their stance until Goodmail can convince Yahoo that Goodmail will treat Yahoo users email stream exactly the same as Yahoo does.

Timeliness of email

There’s been an interesting discussion in the comments from yesterday’s post about temp failing. My position is that email is not a 100% reliable medium for transmitting time sensitive information.
Two things happened today to reinforce that.

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

iContact lists compromised

iContact has acknowledged that (some) of their customer lists were compromised and that they are investigating. As iContact has chosen not to allow comments on that post, feel free to share comments here.
HT: @aliverson

Delivery reference site

Over the years I’ve picked up a lot of useful and relevant information about email delivery. I’ve shared a lot of information here on the blog, and while that’s great, a blog is not a great format for a reference. The ISP information page was an initial pass at creating a reference. I realized that just linking to the ISP provided information didn’t communicate very much about how to deliver email even to those ISPs that were explicitly mentioned.
Enter the Word to the Wise Delivery Wiki to fill the need for a publicly accessible reference on email delivery. The cornerstone of the site is the ISP Information page. This page contains summary information about a number of ISPs, including known connection and sending limits. Each ISP mentioned on that page also has a individual page with more detailed information on delivering to that ISP. The information is as accurate as I could make it, and in many cases have been reviewed by representatives of the ISPs.
I welcome contributions from the general community. I will also be continuing to add content. My goal is to have a community resource for people handling email and delivery issues.