[Mailed and mailed. Alan Stebbens trimmed from Cc: list, will surely
receive this via Procmail list anyway :-]
On Fri, 23 Aug 1996 16:52:56 -0500 (CDT),
athar shiraz siddiqui <assiddiq(_at_)students(_dot_)uiuc(_dot_)edu> wrote:
(A) Log the senders and ban the account that sends more than say 10
messgs. in one hour or one day .Or better begin counter measures ....like
bouncing back mail and sending all man pages.
For the record, "counter measures" like sending man pages -- or
uuencoded core dumps / vmunix images / what have you -- doesn't help
solve the problem in any way. Just refuse the guy; if he continues to
send, and hasn't already protected himself against anything you might
send his way, he'll drown in his own bounces.
For one thing, any net.terrorist worth his salt will have the
mailbombs sent from, or forged to appear to be sent from, some
innocent third party.
As was remarked on this list some time ago, it's probably better to
bounce messages than to just redirect to /dev/null. This depends a bit
on the nature of the incoming material; if you know it's forged,
there's no point in bouncing it to someone who didn't send it in the
first place. Other than that, the bounces will tell the sender that
you are refusing his mail, and maybe inspire somebody to do something
about the situation (like a postmaster somewhere).
(B) Also we could check the size of the Inbox and remove excess mail, as
it comes in, because if the bomber is a fellow procmail usr he can easily
fake the FROM: field.
I think B is more feasible and less taxing.
is there a way of doing this ?
If you just start trimming your Inbox when it grows big enough, you
will probably lose legitimate mail. As a simple threshold, you could
trash all mail exceeding some particular size.
As for the "no more than n messages from one particular sender"
mechanics, I'm sure somebody will already have implemented that ...
Love this list :-)
Here's what I'd code if I had the time -- pseudo code, then:
Parameters:
Header -- match on envelope From_ line, or what?
Time-Window -- how long time a cache entry should survive
Low-Threshold -- no. of messages allowed in Time-Window
High-Threshold -- no. of messages allowed in Time-Window before
really freaking out :-)
0. Flush entries older than Time-Window from the Header cache
1. Write message's Header field to cache
2. If it appears more than High-Threshold times in the cache, just
send to /dev/null
3. Else, if it appears exactly High-Threshold times, notify
postmasters etc etc.
4. Else, if it appears more than Low-Threshold times in the cache,
bounce it
5. Else proceed normally to deliver message
Is the first field of the From_ line a good thing to match on, and how
would one implement the cache thing?
/* era */
--
See <http://www.ling.helsinki.fi/~reriksso/> for mantra, disclaimer, etc.
* If you enjoy getting spam, I'd appreciate it if you'd register yourself
at the following URL: <http://www.ling.helsinki.fi/~reriksso/spam.html>