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.)

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 »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Feb 15 00:43:03 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.