Postini bug
Ben over at MailChimp has an article talking about a recent experience with Postini and an actual bug that causes Postini to interact badly with another spamfilter and block non-spam.
Related Posts
Links
Venkat posts today about the ruling in the Asis v. Azoogle case. I have not yet had a chance to read the whole ruling, but in talking with Mickey over at SpamSuite it seems to expand the Gordon ruling a bit.
Mickey posts on Intellectual Intercourse about spam received from a recruiting agency trying to get him to hire one of their clients. This spam was amusing in that it contained reference to a bill that Mickey helped defeat years ago.
Box of Meat blog links to a CSO online article graphically demonstrating a botnet. The representation is really helps to understand the scope of the problem.
On Bronto Blog DJ posts about resurrecting old addresses. He has it right when he says: “If you continue to send email to customers that is random and unexpected, there will be consequences.”
Matt at ReturnPath has a couple posts about who should get delivery services and how ReturnPath chooses customers. This is something I end up dealing with occasionally. There are not specific types of companies I refuse to do consulting for. I will generally provide consulting on best practices to any business segment. My one restriction is that I will not provide ISP relations (ie, contacting the ISPs) for companies that do not send opt-in email. This has caused consternation with some potential customers.
Mark Brownlow at No Man is an iland suggests renaming “open rate” as “render rate” in an effort to make it much clearer what “open rates” really measure. Expect to see render rates referred to here on this blog in the future.
Josh talks about suppression list abuse on Deliverability.com. For those of us who use unique addresses for every signup, it quickly becomes clear that there are leaks in the suppression process. I have also seen problems with leaks from subscriptions, so do not think the problem is just in suppressions.
Affiliates: what is a company's responsibility
Many of my clients come to me when they end up with delivery problems due to the actions of affiliates. These can either be listings in some of the URL blocklists (either public or private) or escalations of IP based listings. In many of the cases I have dealt with affiliates, the affiliates have sloppy mailing practices or are out and out spammers.
Recently the FTC settled with Cyberheat over their liability for the behaviour of their affiliates. In this settlement Cyberheat is required to monitor their affiliates as follows:
Forgery and spamware
Recently there has been a massive uptick in forgeries. I have been seeing hundreds of bounce back messages, peaking at more than 1000 in an hour. I have been talking about this with people who monitor large spamtrap feeds, large MTAs and spamfilters and it seems this is not an isolated experience. The consensus seems to be that there is new spamware out there which is using email addresses on the spam list as a From: address
The volume itself is annoying. Thousands of messages a day from “mailer-daemon” telling me that the mail I sent with the subject line “Get a longer tool” cannot be delivered to some random address some where. These are coming to at least 3 separate email addresses. One of them was given to Intuit back in 2001/2002 when I registered a copy of Quicken, and ended up leaked to loan spammers and is all over spam lists. The other two are addresses scraped from websites. Same spammer has them, same spammer is using them as part of his spam run.
Even more annoying than the volume, though, is the challenge/response emails. “Your email to jobobjimbo@example.com cannot be delivered until you click this link.” I have been adding every domain I can find that is using c/r to my filters, and just discarding the c/r emails so I do not have to deal with them. That is not my ideal solution, it does mean that if someone using c/r ever tries to contact me I will not see the challenge and our communications cannot happen.
Some people have recommended that the right way to deal with challenges from forged spam are actually to answer the challenges. As the reasoning goes, if someone using c/r is going to outsource their spam filtering to a victim of spam forgery, then they should expect that the “spam filter” may have a different opinion than they do. While I always sympathized with this viewpoint, I was not sure I would ever confirm spam forgeries. The sheer volume of c/r stuff I have received in the last few weeks has almost convinced me that people who use c/r deserve every bit of spam they get. If a c/r filter lets in spam, then perhaps they will reconsider their choice to spew challenges out to forged email addresses.
The amount of c/r spam I am getting as part of the forgery runs is decreasing, I think I have finally managed to block the primary sources. It does mean I will not be able to communicate with people who use c/r in the future, but I find this a small price to pay for not having to be an outsourced spam filter. I get enough of my own spam, I really do not want to have to deal with yours.