Final post on interview with the spam chief

Following on from my previous post on my comments on Mark Risher of Yahoo, with whom there was a user interview, I'd like to respond to a couple more of his responses to users.

Mindy: What are you recommendations for handling blocks due to complaint volume, since FBL requests are not accepted at the moment?

Mark: The FBL, or feedback loop is a way that Yahoo! communicates back with commercial e-mail senders to let them know their messages are being marked as spam by Yahoo! Mail users. One of the most important ways that Yahoo! Mail is able to block spam is by listening to its users.

Yahoo! is the largest webmail system on the planet, and if someone is sending mail our users don’t want to receive, those users let us know.  We recommend commercial e-mail senders ensure they’re sending mail that Yahoo! Mail users want to receive. This means following recommended practices like confirming — and even periodically re-confirming — that users want to be on their mailing lists and proactively removing anyone who doesn’t read their mail.

A feedback loop (FBL) is something that many vendors have set up.  Basically, you tell an email provider what IPs you send email from.  When a user receives a message from one of your outbound IPs and clicks "Report Spam" when it lands in their inbox, the email provider (in this case, Yahoo) takes that spam message and emails it back to you (say, abuse@example.org) as if to say "Your users are sending my users spam."  This way, you can take steps to cut down on your own outbound spam.

The problem with Yahoo is that you can't sign up for their feedback loop unless you sign your outbound mail with DomainKeys.  Personally, I think that is totally unnecessary.  If you know what IPs your outbound mail goes through, that ought to be enough.  There's no reason to also have to sign with DK/DKIM.

Finally, I thought that Yahoo was the largest webmail system on the planet.

Mel: Not really a question but a comment with the hope that Yahoo! will figure out why a lot of postdated spam shows up. For instance, on the 28th I got several spam emails that were dated August 1. Shouldn't these be easy to stop since they obviously aren't legitimate emails? I used to get pre-dated emails, i.e. emails that were dated from the '70's, before the internet came to be. Yahoo! ultimately learned to stop them in their tracks because it's been about a year since I've seen one. Maybe the same can be done for postdated emails. Thanks!

Mark: Hi Mel, W’m glad you asked. With hundreds of different spam attempts every day, we have to prioritize the feature areas we work on.

For this particular spammer, we’ve been throwing 100% of his messages into the spam folder for a long time. Talk about an unabashed spammer; instead of cleaning up his act or giving up the fight, he decided he just wanted to be at the top of the list — the spammiest of the spammers. So he started setting the date way into the future so that people who sort their messages by date would see his garbage first.

While this one is really irritating — and I completely share your frustration — because the messages are in the spam folder, we’ve been focusing our efforts lately on other areas.

I can share Mark's pain here.  Over here in Exchange Hosted Services, we have a backlog of about a dozen features that we want to get to!  Prioritizing them is one of the things that I have to do and I order them by how many times a complaint is escalated to me and I second sort on how much additional anti-spam effectiveness said feature will add to our product.

To answer Mel's question, if you get an email from some time in the future (say, August 30th and today is August 15th) or some time late in the past, it is often indicative of spam.  But, not always.  One thing I have long since learned is that even though lots of spammers do things that most legitimate emailers don't do, the key word is most.  There are a lot of mail servers that are misconfigured and have date/time stamps that are not consistent with today's date.  So, blocking outright on this is likely to produce a pile of false positives because you can't count on everyone to do things properly.