Wandering Thoughts archives

A confession: I find rejecting spam at SMTP time to be more satisfying

In a modern mail environment, there are a number of places where you can block or drop spam. Of these places, in some ways the hardest place to support is rejecting things during the SMTP conversation. It may take gory hacks to get your inbound mailer to do spam checks during the conversation, there's the SMTP DATA rejection problem, and various other problems.

In the past I've written on various good technical reasons to reject at SMTP time, and I certainly (still) believe all of them. Rejecting spam at SMTP time reduces the risk of false positives and will often (although not always) reduce the load on your mail system, perhaps substantially, and so on. But I have to confess that there is an additional reason that I really like SMTP time rejection of spam: I simply find it a lot more satisfying.

However irrational it is, it simply feels better to reject a spam message at SMTP time than to let it on to my systems. Rejecting at SMTP time feels like I am in some tiny little way giving the spammer the middle finger and throwing their own spam back at them. And on the other side, accepting their spam and then throwing it away later makes me feel just a little bit slimed by that spam, even if all steps are automated and the end result is exactly the same. It even makes me feel a bit irritated to accept and then dump spam.

(Part of it is that with SMTP rejections we are visibly registering some sort of objection to the mail, but that's not all of it by any means.)

I'm aware that this is an irrational thing, but rejection at SMTP time just makes me happier. As a result, I'm willing to go out of my way to create mailer configurations and so on that enable us to do this (and enable us to offer this to users as something they can enable).

(I suspect that part of why I find SMTP time rejection to be more satisfying is that it is the right place to do it at a technical level. Accept then drop is clearly technically inferior to rejecting during the SMTP conversation.)

There are three places spam filtering can happen these days

These days, there are three different places where (anti-)spam filtering can happen in an email system:

1. In the user's mail client, assuming that you let them run one that has filtering rules (and most of them do). It's worth noting that there is effectively no client side filtering in webmail systems.

2. On the server once the email has been accepted at the SMTP level. This is the domain of people running procmail from their .forwards, as well as various sorts of system-wide filtering.

3. At SMTP time, so that undesired messages get SMTP level rejections. This is easily done for things like DNS blocklist checks, but can often be done with content filters as well.

Client side filtering is essentially entirely in the hands of users to both set up and maintain. You can try to distribute some standard filtering rules if you happen to have standard clients that you support, but I'm not sure how much support there is for updating them later except through manual user action (which we all know is very unlikely to happen). On the other hand, client side filtering fully empowers users to do whatever filtering they want with whatever tools they can put together. It also requires the least effort on your part, since you basically don't have to do anything; MUA authors maintain the filtering system and users maintain whatever filtering rules they want.

As someone who doesn't like to quietly drop email, it's my personal view that SMTP time rejection is the best option if you can manage it. Early SMTP rejection before DATA can significantly reduce the load on your mail system, but rejection after DATA may help less (since you have to receive the message and then run it through potentially expensive checking). Unfortunately the limitations of SMTP may make DATA-time rejection potentially chancy, since they apply to all recipients.

On the server after the mail has been accepted from the sender has been the traditional place to do filtering, at least on Unix machines. It's generally been much easier to run email through additional steps here rather than at SMTP time and there have long been robust tools for filtering, both at the individual user level and at the overall MTA level. Procmail is a classic even if it's not all that user friendly.

(As mentioned, people using webmail generally don't have a client side, so for them it is some form of server-side filtering or nothing. This filtering may run when messages are received or just when people log in to their webmail and start doing things.)

Only at SMTP time can you genuinely reject the email (although the sender may or may not pay any attention to your rejection; spammers probably won't). After that, about all you can really do is throw the message away (see this for details on why). On the other hand, if you want to let users go through their filtered out email you basically have to accept it first.

Red Hat has really doubled down on being email spammers

Back in June, I wrote about how we'd gotten marketing email from Red Hat to a RHN contact address. At the time I wrote an angry complaint email to Red Hat about it, from my core email address. This is the only time I have given Red Hat my core email address; it is not, for example, the address I use on their Bugzilla.

On November 10th, I got the following email message from Red Hat, once again from their very own SMTP server:

From noreply@engage.redhat.com Tue Nov 10 [...]
Received: from mail01.engage.redhat.com ([204.92.22.83]) [...]
[...]
From: "Red Hat" <email@engage.redhat.com>
Subject: Win a complimentary pass to RSA Conference in Nov. 18 virtual event

If you're looking for a reason to register for Secure Foundations for Today and Tomorrow | A Red Hat virtual event, look no further. In the virtual event on November 18, you'll hear from Red Hat executives, technical experts, and IKEA, and learn more about: [...]

There are no polite words for a company that takes email addresses that have sent abuse complaints to them and recycles those email addresses into their mailing lists as fresh addresses. Such a company is a spammer, period, full stop.

So: Red Hat are email spammers.

Sic transit gloria mundi, and all that. There was a time when I would have believed that Red Hat would never do this, that it had far too many principles to even get close to this. Clearly I was wrong, and I guess I found out how far Red Hat was willing to go (as I wondered in my initial entry).

I sent another email complaint, because somehow I am still an optimist. It has been almost a month and just as the first time, I have had exactly no response from Red Hat. Dead silence to abuse complaints is of course another sign of a spammer, so I shouldn't be surprised.

(Sending out your email with a 'noreply' address is of another one of those signs. Real mailing list software uses envelope senders to track bounces and handle them; software that is never going to remove email addresses when they bounce obviously has no need for such niceties.)

I haven't gotten any further marketing spam messages from Red Hat, but I expect it's only a matter of time (and thus I expect to someday write a third entry to confirm that it's happened). If they continue it long enough, 2017 will be an interesting year.

Sidebar: Who engage.redhat.com appears to be

While various pieces of information (such as good reverse DNS) ties this to Red Hat with Red Hat's active cooperation, Red Hat appears to have outsourced part of their spamming to something called eloqua.net, aka en25.com, aka eloqua.com. To quote the latter's website, this is 'Oracle's B2B Cross-Channel Marketing solution'. There is some moderate irony in that, but I suppose that for both Oracle and Red Hat, money is money.