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.
Today a California judge ruled against plaintiffs suing reunion.com. Venkat has blogged about the case previously, and has an analysis of the ruling. The crux of the case is reunion.com requesting users provide passwords to email accounts and then sending mail claiming to be from the user to all the addresses in the users address book.
According to Mediapost:
the plaintiffs alleged that these types of messages are deceptive because they appear to come from people’s friends rather than the site itself. The consumers sued the site for violating California’s anti-spam law, which prohibits e-mails with false or misleading headers and subject lines and provides for up to $1,000 per violation. The federal CAN-SPAM law preempts most state spam laws, but there’s an exception for state laws dealing with fraudulent e-mails.
The judge ruled that since the plaintiffs could not demonstrate actual damage from the email, that there was no case. Venkat says:
…to me the court’s preemption reading is way too broad here. [...] State law doesn’t necessarily impose this requirement. State law (such as California law) allows pretty much everyone who receives an email to sue, and provides for statutory damages regardless of whether actual damages are suffered. To focus on whether the plaintiff suffered actual damage would pretty much raise the bar for spam lawsuits far beyond what is contained in state law.
I can’t disagree with Venkat’s analysis. I’m not really not sure that California lawmakers intended the plaintiff to have to prove actual monetary damages when suing for spam.
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.
A few weeks ago I was asked my opinion about a delivery situation. It seems that a sender wanted to mail to a purchased email list. They asked what I thought about getting fresh IP addresses and domains to use to send mail to the purchased list. “We know we’re going to get complaints, probably hit spamtraps and generally have problems with the first few sends of the list. We want to do this without harming our reputation. We figure if we move over to different domains and different IP addresses than we can send this mail and not suffer a reputation hit.”
Uh. Yeah. That’s what spammers do. They split off their mail into discrete sets so that they can spam with impunity and still have one or two ranges that have a good reputation and decent delivery. Some spammers have taken the discrete companies to extremes, and have a series of companies. They purchase a new list and send it through their companies one by one. At each step, they aggressively purge off bounces and complainers. Gradually, they move the list through their steps, resulting in a list that generates few complaints that they can send through their high reputation companies with few delivery problems.
Sure, legitimate mailers can do the same type of thing. But how legitimate can a sender be if they are using spammer tactics? And these are not mailers unwittingly doing something that spammers also do, these are mailers who are using spammer tactics for exactly the same reason spammers do it. They are trying to send mail people do not want, but send it in a way that does not negatively affect their bottom line.
Spammers hide and try to avoid their bad reputation. Legitimate mailers do not.
Stephanie Miller at ReturnPath offers suggestions on how marketers can break the rules, mail old lists and reap the rewards.
