Chris's Wiki :: blog/spam/RatelimitsWithDelays

SMTP submission ratelimits should have delays too

February 15, 2016

We've recently enabled ratelimits on our mail submission servers. By this I mean that when you hit the ratelimits (which are applied to recipients, ie RCPT TO commands), the mailer gives you 4xx replies and your client will probably error out. But when I set up the ratelimits, I didn't just do that; I also made the mailer delay for 10 seconds before responding to every ratelimited RCPT TO. It's my view that this is a useful and in fact important thing to do.

You should normally only have ratelimits on submission in order to deal with spammers, which means that when the ratelimits trigger you hopefully have a spammer. One of the things you want to do with spammers is slow them down; the slower the spammer is going, the less messages they're submitting and the less damage they're doing. If you immediately reject RCPT TOs, you're slowing down the spammer in one sense (their message isn't getting through to very much), but not in another sense; their submission client will get 4xxs at a rate of many a second and finish message submission almost immediately. They can try again immediately or switch over to another compromised account they have or whatever. Delaying before each reply slows the spammer's submission client down, possibly significantly. If you delay for 10 seconds (as we do), now the spammer can only test 6 RCPT TOs a minute. Unless their code abandons message submission when it goes too slowly, you're tying up their submission code for tens of minutes for a typical spam message with a mass of recipients, instead of letting them dump the message on you and be rejected in a second or so.

(The other benefit of slowing the spammer down is that it gives your alerting mechanisms more time to light up with alarms and get your attention.)

Now, it's certainly possible that this frustrates spammers less than I think. Perhaps their software abandons message submission on the first 4xx reply and immediately moves on (including abandoning the current account). But on the other hand it's a cheap precaution and I think it's worth a shot.

(A spammer that does many message submissions in parallel can speed things up here, but then they open themselves up to other limiters. It's almost certainly rather unusual to have multiple mail submission sessions running at the same time, especially once ratelimiting has kicked in.)

Comments on this page:

By Sotiris Tsimbonis at 2016-02-15 02:01:08:

Unfortunately, I think that spammers these days think differently than us (postmasters).

Whereas in the past I used to see zombie clients sending hundreds of messages per minute/hour from a handful of IP addresses, my observations in the past few months indicate that they now send only 2 or 3 messages from the same IP during a 24h period, but their clients are now very distributed, to hundreds of IP addresses.

So even though delaying them is a nice touch, I don't think they care now. They should not even care enough to change their code around it.

By cks at 2016-02-15 02:16:00:

I wasn't clear in the context of this entry; this is for internal mail submission servers, ones used only by our users for outgoing email (and with some form of authentication or privileged network position). Spammers exploit these by compromising user accounts and then using them to send out spam, either via webmail systems or by authenticated SMTP. In the few cases we've had, all of this spam injection activity was from only a handful of IP addresses (and involved quite large numbers of recipients for each outgoing email).

By Grant at 2016-02-15 14:32:28:

Hi Chris,

I tip my hat to you sir for your attempt at tarpitting spammers, even if it may be a futile gesture.

Years ago I ended up hacking (in the original sense of the word) Sendmail's Bad Recipient Throttle to provide linear delays for each additional bad recipient. I think I allowed 2 or 3 bad recipients before kicking in Bad Recipient Throttle.

I got the code to work such that the first bad recipient after the trigger delayed the SMTP response for 1 second. The second bad recipient delayed for 2 seconds. So on and so forth.

The thing that I did that I thought was neat was that I used SMTP multi-line replies to respond once per second indicating that throttling was in effect.
RCPT TO:...
4xx bad recipient
RCPT TO:...
4xx bad recipient
RCPT TO:...
4xx bad recipient
RCPT TO:...
4xx-bad recipient throttling in effect. (1 second delay)
4xx bad recipient
RCPT TO:...
4xx-bad recipient throttling in effect. (1 second delay)
4xx-bad recipient throttling in effect. (1 second delay)
4xx bad recipient
RCPT TO:...
4xx-bad recipient throttling in effect. (1 second delay)
4xx-bad recipient throttling in effect. (1 second delay)
4xx-bad recipient throttling in effect. (1 second delay)
4xx bad recipient
I never did hear any complaints from my users that they noticed a problem. I did see in my logs where I would tie up a spammer trying to send to bad recipients for 5 ~ 25 minutes at a time. (The mail server was bored and I was never worried about consuming my resources. I don't know how well this would scale today.)

I did also shoot myself in the foot with a poorly coded ad-hock SMTP engine that I was using for something. Oops!

Any way, I thought this was a neat story of mine that went along with your article.

Written on 15 February 2016.

«	Your outgoing mail system should have a per-sender stop switch

Whether or not to use cgo for Go packages, illustrated in a dilemma