On Wed, 25 Feb 2004, Professional Software Engineering wrote:
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).
If the limit is fairly small, you could do something like this:
:0
* ? formail -rD 10000 sent0.cache
* ? formail -rD 9000 sent1.cache
* ? formail -rD 8000 sent2.cache
* ? formail -rD 7000 sent3.cache
* ? formail -rD 6000 sent4.cache
* ? formail -rD 5000 sent5.cache
* ? formail -rD 4000 sent6.cache
* ? formail -rD 3000 sent7.cache
* ? formail -rD 2000 sent8.cache
* ? formail -rD 1000 sent9.cache
{ LOG="Ten times is too many$NL" }
Not spectacularly efficient, but obvious and uses only "standard" tools.
There's the little matter of resetting the counter in a sensible fashion
Ah, now the tricky bit: Periodically rotate the cache files down one
number (sent9 -> sent8, ... sent1 -> sent0). That lets in one more
message per sender per rotate period. Perhaps it would even be sufficient
to periodically discard the send9.cache, but then you might need to have
the sizes form a bell curve or something. (I'm just throwing out thoughts
as they pop into my head, I have no non-intuitive basis for that remark.)
Of course you might need to make the cache sizes larger if there are a lot
of possible senders, but IIRC formail -D prunes the cache in MRU fashion,
so only someone who's flooding will make it into all ten caches -- if it's
email traffic in general that's heavy, non-flooders will be pushed out of
the lower caches (between rotates) by the volume of more recent senders.
Or at least that's the theory.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail