Spam, delivery, email and more
In this week’s Magilla newsletter, Ken provides a number of ways to identify a bad email list vendor. His suggestions are not only appropriate for list vendors, but are also a good way to screen mail partners, customers or even vendors.
RoadRunner has decided to delay the launch of their new FBL until after the holidays. Sounds like a good idea to me, the launch is never quite as smooth as the ISP wants it to be. People are checking out and trying to troubleshoot the problems while also dealing with all the extra stress and demands of the holiday season is asking for trouble. The good news is that they are now planning on running the two FBLs in parallel for a few weeks, instead of ending one then starting the other.
Well over half of the clients who come to me with delivery problems admit at some point that one of the ways they collect subscribers is through co-registration. They typically have widespread delivery problems at the major ISPs as well as SBL listings.
John Levine posted over the weekend about his thoughts on co-reg.
So a friend asked, is it possible to do coreg that doesn’t stink?
After a variety of more complex suggestions, I offered a simple criterion: if it’s one opt-in, it’s one opt-out. That is, if I signed up in one place, and I later decide that I don’t like all the mail from Our [Trusted Marketing Partners], I want to unsub once and have it all stop.
Therein lies the rub. Most companies selling addresses through co-reg will tell you that they can’t take any responsibility for what happens to the address after the sell it. They will point out it is not financially viable for them to track what happens to their subscribers. The question I have never received a satisfactory answer to is: If you don’t know what your trusted marketing partners are doing with the addresses you are selling to them, how is a subscriber expected to give informed permission
On the flip side, companies who buy co-reg usually have a rash of excuses for why they will not take responsibility for gathering permission from the recipients. They don’t want to send welcome messages. They won’t tell the recipient who sold them the address. They won’t ask sellers how many other senders this address was sold to. They will not confirm the recipient wants mail from them. In my, admittedly biased, experience the entire co-reg industry is about obfuscation and hiding from recipients. This goes equally for the sellers and the buyers.
Over at the Exacttarget blog, Al talks about a successful way to do co-reg.
Direct co-registration is far less problematic. That’s a scenario wherein a site explicitly asks a registrant if they want mail from company X, Y or Z, and then, if the registrant only agrees to mail from company X, only company X is given the registrant’s email address. Sounds like opt-in to me.
His experience matches with mine. If there is transparency in the transaction, that is both the seller and they buyer inform the recipient what is going to happen to an email address then the recipient can make an informed decision. However, when the recipient is just told that their address will be shared, there is no informed opt-in and the recipient treats the mail as spam.
Josh reports mail from MobileMe to spamcop.net addresses is being filtered somewhere and isn’t being delivered or actively bounced. He asserts that Apple is blocking all mail to Spamcop addresses
because they were having problems getting blacklisted on SpamCop and implemented this as a way of reducing their number of SpamCop spamtrap hits.
That makes no sense. Spamcop spamtraps are rarely hosted on spamcop.net. I won’t say never because there may be some, but I know that some spamtraps are on different domains and different SMTP servers. Senders who try to avoid Spamcop problems by filtering all mail to Spamcop are doomed to failure.
The problem is being discussed both on the Apple forums and the Spamcop forums. There is some confusion about what is going on. Some posters seem to be having problems mailing addresses at spamcop.net addresses, other posters seem to be having problems forwarding spam to the spamcop reporting address.
One poster reported that Apple support is claiming that Spamcop is blocking mail from MobileMe. In response ae Spamcop admins posted:
SpamCop does not block ANY email at all that is sent to spam.spamcop.net addresses. We do not use our own blocking list. We might bounce emails to certain addresses, but we do not block anything that comes our way.
The same applies for the SpamCop Email Service. However, they do use greylisting, which delays acceptance from some servers until the server tries again. Continuing to try to deliver email is standard behavior for legitimate mail servers, but not for spammer servers, which only try once and give up.
I suppose it is possible that Apple is seeing the greylisting delay when they try to send mail to spamcop.net, cqmail.net, or cesmail.net addresses and thinks it is a rejection.
If the problem really is forwarding spam to the Spamcop reporting address, it could be Apple filtering outgoing mail to prevent spam from leaking out their servers. If the problem really is sending mail to Spamcop.net addresses it could be a bad interaction between MobileMe and Spamcop’s greylisting scheme. Without seeing the actual transactions between the two servers it is difficult to determine what is happening.
In any case, this demonstrates some of the challenges involved in troubleshooting mail problems. People are poking the system from the outside, but there seems to be some one along the line silently discarding email, leaving senders (and receivers!) in the dark about where the email went.
The great folks over at Mailchimp publish aggregate stats from their customers. This is a useful set of data for senders who want to see how other mailers or ESPs are doing.
One set of stats is the data from
234 million emails delivered by our system (where campaign tracking was activated, and where users actually reported their company size) and calculated average open rates, average click rates, average soft bounces, average hard bounces, and average abuse complaint rate by company size.
Good stuff, Mailchimp.
Stephanie Miller at ReturnPath offers suggestions on how marketers can break the rules, mail old lists and reap the rewards.
People are reporting delivery delays into Yahoo over the last day or so. Yahoo is having some general connectivity problems and are working to correct the issue.
Changes to the AOL report card were announced today on the AOL Postmaster blog.
The new Report Cards will be sent to domains generating in excess of 0.3% inbox complaints. While 0.1% is still the target for a bulk mailer, we do not feel it is necessary to alert mailers of a potential problem until they have reached 0.3%. In addition to this change, we will no longer be providing the specific inbox complaint percentage for each domain. The report card will simply be an indication that you have exceeded 0.3% and that you should check your processes to ensure you are managing your spam complaints.
On another note: Happy Thanksgiving! I am out of the office the rest of the week and am not intending to do any serious blogging until I get back next week.
ReturnPath announced today that the BlueTie FBL is live. You can signup for the new FBL at http://feedback.bluetie.com/.
