What constitutes a spam, anyhow?

Today, myself and my co-worker got into a pretty big discussion about what constitutes spam and what doesn’t.

At issue was a message that was flagged as spam when sent to an internal Microsoft alias.  What happened is a researcher sent around a message that contains  some data about spam and malware, contains some URLs along with some summaries of important trends and sends to a distribution group.  The From address is an internal Microsoft user alias but the name that appears is “Daily Trends” (not that exactly, but you get my point).  The MUA is not Outlook, but instead is a mailer script that is written in Perl.  I’m not familiar with the interface but the mailer is in the message headers and runs on a box that is internal to Microsoft.  Thus, the script, I assume, connects to port 25 (from within the Microsoft environment) and sends a mail with contents based upon what the user has written.  This mail was rejected in SMTP based upon characteristics within the mail.  I classified this as a false positive.  It’s a legitimate mail, people want it, and is neither unsolicited nor bulk.

Now, my colleague, by contrast, insists that this message is 100% spam.  It is not legitimate by any stretch of the imagination and the content filter rejected it and that this was the correct behavior.  To my (crazy) colleague, the reason that this message is spam has nothing to do with whether or not the recipients wanted to receive the message, nor whether or not the message contents are spam.  Instead, he insists that it is spam because there was no SMTP AUTH for the message.

In other words, the message was sent “anonymously.”  The script connected to the network, sent a mail, and then disconnected.  By contrast, if you are in a corporate environment, you might have to login and send mail via Exchange and all mail is sent as you; that is, mail has SMTP AUTH because you are logged in and mail is coming “from” you (never mind the fact that anyone can walk by your terminal if you haven’t locked it and send mail as you).  His argument is that a rogue employee could log in and send volumes of mail to internal distribution lists without actually doing SMTP AUTH.  And if you aren’t AUTH’ed, then the message is spam.  It doesn’t matter what the contents of the message are, no AUTH = not legitimate.  Furthermore, most (?) companies’ policies (?) are that you cannot send mail anonymously like this, you must do it logged in.  If you’re not, then it doesn’t matter what type of mail you send, it should be rejected 100% of the time.

From my perspective, this is wrong.  SMTP AUTH is a way to backtrack back to the user who sent the mail and makes it easier to find out who is sending the mail.  But if it isn’t used, it doesn’t mean that it is spam.  These are the exact types of scenarios that are part of the “long tail” of email usages.  I would guess that there exists hundreds of thousands of mail and IT admins who have automated scripts set up somewhere to collect information and send out reports.  Or that send out email and don’t do SMTP AUTH.  It’s just a script, and it’s internal.  It’s a quick, easy way to find out information and send it to a narrow audience.  My point is that it is not spam.  If a spam filter detects it as spam then that would be an example of a false positive.  It may be a false positive that the filter should not take action to correct (it falls into the TS category), but it’s a legitimate mail that was incorrectly flagged as spam.  Mail that one user sends to another for a specific purpose – namely, that contains valuable information – is not spam.  Maybe best email practices aren’t being followed, but a filter should be intelligent enough to figure that out.  And not so aggressive that it cannot allow some leeway to handle cases like these.

Comments (4)

  1. SPAM is UCE (Unsolicited Commercial Email).

    Other email may be unwanted for other reasons and there certainly are good arguments for putting security measures in place to disallow anonymous email internally, but they do not qualify as SPAM.  Neither do annoying marketing email that a user has signed up for and not even tried to opt out.  If a marketing list does not honor an unsubscribe request, then it officially qualifies as SPAM.

    There may be other email that can be classified as annoying or undesirable (often for security reasons), but SPAM is already well defined and should not be confused with the poor judgment (or thoughtlessness) or the message you described above.

  2. Pete says:

    Why not just get the script to AUTH with the script author's details…? Or is the script so badly written it can't AUTH?

  3. Good post. There can be a really thin line between spam and not-spam-but-not-unreasonable-to-block-for-other-reasons and that's one of the things that makes working with (i.e. against) spam interesting, both from a sender's and a receiver's point of view.

    It made me wonder: is there some kind of spam-filtering BCP? Something that tells you, as a spam filter, that if a message has property a or b and c, then it's reasonable to block it?

  4. CS says:

    Why choose SMTP AUTH as some holy discriminant that is the standard for deciphering spam from ham. Why not SPF, why not strict protocol adherence. That's just an odd stance. Not that any of those are actually infallible discriminants themselves. If I only had a dime for every spam I've seen sent from an AUTHed account!

    I agree with you, this is a false positive. I a work in the anti-spam business and encounter situations where communications about some particular spam gets quarantined by our system. I consider this a fp too, although I accept it because 1) it's a corner case, and 2) writing a spam filter that can judge intent of the sender merely from the content and metadata of the message is a valiant but impractical ideal.

Skip to main content