procmail
[Top] [All Lists]

Flood control?

2004-02-25 22:17:03
Someone I know got hit with a flood of messages from a misbehaving autoreply bot.

A list s*bscription processor (majordomo) received a s*bscription confirmatin from a user (ironically, sent from the problem account to confirm s*bscription for a different address). The list processor sends out a message confirming the results of the action - to the address which submitted the command.

Which promptly was replied with a _fresh_ message stating how the user reads all their email, etc, but is having troubles with their account, so if they don't reply in 24 hours, send the message again. Yea, thanks champ.

Of course, since the LIST processor address is intended to only be used for list processing (and in fact, the SENT messages have an envelope sender of the listadmin, not the list processor - so DSNs are not sent to the processor), it isn't equipped to deal with autoreplies.

Nothing about the autoreply met any of the standard characteristics for vacation messages either, so that filter wasn't tripped.

Now, I've got other things to deal with right now, and I'm going to sleep on this anyway, but I was wondering if anyone here might have any insights on how to implement a dynamic "flood control" mechanism.

I'm thinking something along the lines of taking the sender's address and incrementing a counter associated with that address -- if the counter exceeds some limit, that sender's messages get redirected elsewhere (and as a result, don't get processed through the list processor, so they don't get further messages).

There's the little matter of resetting the counter in a sensible fashion (if you merely purged the counter file on a weekly basis, then if there was a problem right around the purge time, it count go for nearly twice the threshold before being detected). While the legitimate message traffic to the list processor account isn't tremendously high, I think it'd be good to have a system which doesn't have a high processing overhead -- I had thought that tossing one liners with a datecode and address would be one way, then grepping the list. A cron-invoked cleanup script could trim and rewrite the log file based on a cutoff date.

dates could be emitted to individual data files named based on the sender's email. I'm not particularly keen on this implementation, though the cleanup script could easily eliminate files which were more than some number of days old, then individually truncate those which remained (based on the same datecode lines). Checking for a flood would be as simple as taking the sender address and doing a wc on the datafile of that name - you're not running through a bunch of lines which don't have anything to do with the sender.

There's also the possibility of a simple database, which I could implement, but if this is to be a fairly portable solution, I think that should be avoided -- having a dependancy upon a helper app and a specific db implementation gets messy when you go to share code.

Ideas?
---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>