Options for dealing with unwanted mail


Way back when I was dealing with spam, I used to through the abuse submission inbox and look for submissions that were good quality.  The best were the ones that contained full headers; generally speaking, messages with the spam attached were good to work with.  Later on, we wrote a plugin for Outlook that would forward us the message with the headers intact so users had a one-click solution for dealing with spam.

It's not at all uncommon for users to regularly submit non-spam messages as spam.  The most common of these are opt-in newsletters.  These fall into a couple of categories:

  1. Mail the user opted into at one point but no longer wants to receive.  The position that we take is that if you don't want to receive the mail anymore, then unsubscribe.

    One of the problems with that problems with that approach is that for years, the industry has told users not to reply to unwanted mail.  The assumption was that all unwanted mail was spam.  This is not the case, just because you didn't want the mail, it doesn't mean it's spam.  You just don't want the sender to send you anything else.  Still, users got used to requesting all mail that they don't want to be blocked as spam.

    Doing so, however, has the side effect of causing many, many false positives for other users.  Spam filters use a common rule base across users, so blocking something for one user necessarily blocks it all.

  2. Someone else provided the user's alias in an opt-in advertisement.  The advertiser then gets the person's email inadvertently added to their list.  They may or may not be legitimate (double opt-in would be nice) but the result is still the same - blocking the mail for one user causes many false positives for others.

This leads me to the Blocked Senders scenario.  I've never been a fan of this feature when it comes to blocking spam.  Spammers can spoof their sending domain incredibly easy, so allowing users to block on a sender is next to useless.  All that ends up occurring is the user builds an incredibly long list of blocked senders that sent to them once but don't do it anymore.  So, in terms of spam effectiveness, such a feature has next to no usefulness.

However, a Blocked Senders feature is more about specific policy enforcement.  A user may not want to click on an unsubscribe link because they think the sender is a spammer.  In this case, they should add the sender to a blocked sender list.  That way, they don't get the mail they don't want to receive and the rest of the general population can continue to receive it (on the assumption that they want it).  This feature is only useful when the sender is not a spammer and sends from the same return-path each time.

The one drawback of this feature is that the sender is blissfully unaware that their messages are not getting through to the end user.  However, that's a topic to be dealt with by the email-deliverability folks, I'm in the business of impeding mail flow!

Comments (2)

  1. Dave Crocker says:

    Terry,

    I just noticed that your "Sender Authentication" section, below Education and above Archives, list DomainKeys, SPF and Senderid, but not DKIM.  Since DKIM is the only one of the 3 that has formal standards status and since DomainKeys really is pretty much gone operationally, can you add a point to DKIm (top of the list would be fine…) to:  <http://dkim.org&gt;

    Thanks!

    /Dave

    dcrocker@bbiw.net

Skip to main content