News from MAAWG

During MAAWG a number of companies in the email space announce new initiatives, mergers, products and the like. This MAAWG is no different.
Spammers adjust to security trends. This is not really news, spammers have been adjusting to new security measures since folks started blocking from: addresses back in ’95 and ’96. The tactics are different and developing, but for every security hole that is blocked, spammers will search for another hole to exploit. The unfortunate truth is that end user is the weak point, and spammers and scammers are very very good at social engineering.
Spam statistics stalemate. Spam is still accounting for approximately 90% of all email traffic.
Cloudmark acquires Bizanga. I talked to some of the Cloudmark folks and they seem very excited with their acquisition of the Bizanga MTA and email technology.
Bizanga Storage announced. Bizanga Store is a scalable storage system brought to you by some of the people who were instrumental in building the Bizanga MTA acquired by Cloudmark.
ReturnPath announced partnership with RPost. Yet more ongoing changes in the certification field.

Related Posts

Matt Blumberg joins the DMA Board

Matt Blumberg, CEO of ReturnPath, announced on his blog today that he has joined the board of the DMA. The blog post is both an explanation of why he did it and an agenda for what he wants to accomplish.

Read More

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.

Read More

Permission Based Emails? Are you sure?

Yesterday I wrote about the ReturnPath study showing 21% of permission based email does not make it to the inbox. There are a number of reasons I can think of for this result, but I think one of the major ones is that not all the mail they are monitoring is permission based. I have no doubt that all of the RP customers say that the mail they’re sending is permission based, I also have no doubt that not all of the mail is.
Everyone who sends mail sends permission based email. Really! Just ask them!
In 10 years of professionally working with senders I have yet to find a marketer that says anything other than all their email is permission based. Every email marketer, from those who buy email addresses to those who do fully confirmed verified opt-in with a cherry on top will claim all their email is permission based. And some of the mailers I’ve worked with in the past have been listed on ROKSO. None of these mailers will ever admit that they are not sending permission based email.
Going back to ReturnPath’s data we don’t really know what permission based email means in this context and so we don’t know if the mail is legitimately or illegitimately blocked. My guess is that some significant percentage of the 20% of email to the probe accounts that doesn’t make it to the inbox is missing because the sender does not have clear recipient permission.
When even spammers describe their email as permission based email marketing, what value does the term have?

Read More