Related Posts

Greylisting: that which Yahoo does not do

Over the last couple days multiple people have asserted to me that Yahoo is greylisting mail. The fact that Yahoo itself asserts it is not using greylisting as a technique to control mail seems to have no effect on the number of people who believe that Yahoo is greylisting.
Deeply held beliefs by many senders aside, Yahoo is not greylisting. Yahoo is using temporary failures (4xx) as a way to defer and control mail coming into their servers and their users.
I think much of the problem is that the definition of greylisting is not well understood by the people using the term. Greylisting generally refers to a process of refusing email with a 4xx response the first time delivery is attempted and accepting the email at the second delivery attempt. There are a number of ways to greylist, per message, per IP or per from address. The defining feature of greylisting is that the receiving MTA keeps track of the messages (IP or addresss) that it has rejected and allows the mail through the second time the mail is sent.
This technique for handling email is a direct response to some spamming software, particularly software that uses infected Windows machines to send email. The spam software will drop any email in response to a 4xx or 5xx response. Well designed software will retry any email receiving a 4xx response. By rejecting anything on the first attempt with a 4xx, the receiving ISPs can trivially block mail from spambots.
Where does this fit in with what Yahoo is doing? Yahoo is not keeping track of the mail it rejects and is not reliably allowing email through on the second attempt. There are a couple reasons why Yahoo is deferring mail.

Read More

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.

Read More

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.

Read More