Flood protection patch

[fanf]

I've posted my rate limiting patch to the exim-users mailing list. You can see it at:

http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/exim-ratelimit.patch

Comments

[lusercop.livejournal.com]

Cute. One thing I'm not quite sure I understand is how anything gets written back to your state database if you're not in leaky mode, though. (I probably need to read the patch in context, but it's 8 in the morning, and I'm about to go to work, so I'm probably missing something obvious). Does it all magically get updated from the tree when the connection gets closed or some such?

[fanf]

The relevant code is:

if (rc == FAIL || !leaky)
dbfn_write(dbm, key, dbd, sizeof(dbdata_ratelimit));

i.e. if the rate is low, or if we are strict, update the persistent state.

[korenwolf.livejournal.com]

I'm going to be rolling this into the local test release shortly to see if it can help control the speed at which some of the larger companies dump mail onto my outbounds. I'll let you know how it performs.

[fanf]

Marvellous! You'll want to know that I've just updated the patch on the web server to correspond exactly to what was committed (see also http://www.exim.org/mail-archives/exim-cvs/). There were two commits because Philip suggested a change to improve the handling of certain edge cases, though this won't affect most normal use.

[korenwolf.livejournal.com]

I'm using the patch I grabbed from the url on this LJ entry around 30 minutes ago or so, that the latest?

[fanf]

Possibly not - I literally updated it just before replying to your comment. The latest patch has the following near the start

-$Cambridge: exim/exim-doc/doc-txt/ChangeLog,v 1.140 2005/05/23 15:28:37 fanf2 Exp $
+$Cambridge: exim/exim-doc/doc-txt/ChangeLog,v 1.141 2005/05/23 16:58:55 fanf2 Exp $

[korenwolf.livejournal.com]

Grabbed, thanks.. Now to make sure that rpm has built the way I want it and then to test on the cold spare :)

[korenwolf.livejournal.com]

Looking very good, I'm running it on one of the core servers in testing mode at the moment, assuming no problems I'll be looking to using it in production as it solves a large number of problems with (a) stupid legit bulk sending customers and (b) stupid customers who can't maintain windows boxes.

Any known gotchas? :)

[fanf]

gotchas

So long as you understand the options (especially the difference between strict and leaky) it should be straight-forward. One thing that's slightly poorly documented is exactly how the key is treated: it actually includes the all of the ratelimit options (m/p/opt/key), so if you tweak the configuration it effectively forgets the client's saved rate. Perhaps it shouldn't include m in the database key...

[fanf]

I've fixed the latter so that the limit is omitted from the lookup key; the period and options are still included because they change the meaning of the recorded state. This fix only matters if/when you change the limit, so you probably shouldn't change your plans.