Someone I know got hit with a flood of messages from a misbehaving
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
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.
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