Tony Finch – blog

At the UKUUG winter spring conference I’m going to be presenting a paper on my email rate-limiting work. This gives me some incentive to work a bit more on its deployment :-)

I’ve been discovering that it’s very hard to set a limit which minimizes the inconvenicence (e.g. admin work maintaining the list of ratelimit exemptions; false positives because people don’t realize they need to warn us about bulk email beforehand) but at the same time provides decent protection against unwanted floods. The spam incident last term illustrated this well: I had (foolishly) assumed that spam would typically be one recipient per message, but the spammers managed to find a hole that allowed them many recipients per message, so my ratelimiting system didn’t spot the flood.

This problem is similar to the problem of setting an appropriate work factor for anti-spam proof-of-work systems: http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf

So I’m now experimenting with per-recipient limits in conjunction with per-message limits, to see how awkward it is to set the limits for that - probably just as bad, but per-recipient limits are closer to what we actually care about.

I’ve also had an idea about making the countermeasures less irritating for the user. Rejecting the message (even with a 450 try later code) is likely to cause problems for shitty mailmerge software that can’t retry. So what we can probably do instead is accept the message and freeze it on ppswitch’s queue, using the control = freeze ACL modifier, and after we have been alerted to the problem, we can check the messages and thaw them with exim -Mt. This is a fair amount of admin faff, so I’ll probably develop a web interface to move the work to the users.