At 22:13 2004-02-26 +0000, Alan Clifford wrote:
One defense in my autoresponder is to put the reply into sendmail's queue.
If a mailloop occured, there would be a 30 minute delay between the
responses.
That's good, though it's rather dependant upon how often the mail queue is
processed.
After a response, I put the address into a list and don't respond to
addresses already in the list.
I only wish the toad at the far end had taken _any_ steps to avoid problems
with autoreplies, but seeing as my end is a list processor, ignoring
further requests from the same sender is inappropriate - they could be
s*bscribing to multiple lists, etc. Similar for delaying replies (where
after 10 or 15 minutes, the user might actually believe the command wasn't
accepted and send it again - it's amazing how many turkeys repost on
discussion lists because they don't see their post in their own inbox
instantaniously).
I dump my list every morning with cron. For a subscription address, isn't
your problem the same in that you just have to break the mail loop so a
persistent list is not required?
One needs first to determine that it in fact is a loop. THAT would be the
purpose of a flood control function - determining how many messages some
specific sender has sent in the past 'x' hours, say with a 20/hr threshold,
and then they get disabled, requiring admin intervention.
I implemented a simple database as a text file for my long line detector.
I don't know how well such a thing would scale, but if it is limited to
mail coming to a subscription address, does it need to? My database
format is
20040226 0032 AAABVAIPrj...
where the 'C' helper program updates the counter and emits it on stdout
for scoring in procmail and a gawk program does the ageing cleanup as a
cron job.
A one-line record would be insufficient, I'm afraid, since there's no
record of how old any number of the entries were, and if you purge the file
on the hour, then, as I previously stated, a problem that was running, but
not past the threshold before the hour, will continue that much longer
before being flagged. I'm thinking more of a sliding window for the time
period, rather than bracketed times:
20 messages in the hour before this very instant
vs.
20 messages since 1pm, even if it's 1:01, or 1:59, and if we had 19,
and then it's 2pm, and we now have 0 and we're looking for 20
messages since 2pm...
While I can appreciate the understated elegance of the tiered formail cache
implementation suggested by Bart, invoking from 1 to 10 formail processes
each time a message floats through seems, well, rather inefficient. I'd
prefer to write my own helper program before taking that approach.
---
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