I do (It's taken from the Qmail spam control patch)
(http://www.fehcom.de/qmail/qmail_en.html)
There's a lot of good stuff in there. We found in practice that
real-time blackhole list was a pain in the *** for high-volume systems
due to the lookup time, so we used the Spam control patch instead)
FYI: (I have just taken these from the Spam control readme file).
We used the patch as is, and it seemed fine. Most people doing multiple
RCPT TO:are spammers so we set TARPITCOUNT to 2, and left TARPITDELAY
set to 5.
MAXRECIPIENTS was set to 10 as a reasonable default. We then got the
server to return a 5xx error if the MAXRECIPIENTS threshold was
exceeded.
These settings worked fine for a MLM system. They may not be so
appropriate for a server only hosting user mailboxes. I reckon you would
probable double all the figures above - it this is just a guess.
=====================================================================
2.7 TARPITTING
--------------
I have included Chris Johnson's TARPITTING patch into SPAMCONTROL:
"What is tarpitting? It's the practice of inserting a small sleep in
a SMTP session for reach RCPT TO after some set number of RCPT TOs.
The idea is to that spammers who would hand your SMTP server a single
message with a long list of RCPT TOs. If a spammer were to attempt to
use your server to relay a message, say, 10,000 RECIPIENTS, and you
inserted a five-second delay for each RECIPIENT after the fiftieth,
the spammer would be 'tarpitted', and would most likely assume that
the connection had stalled and give up."
Two additional control files can be employed:
- tarpitcount
is the number of RCPT TOs to accept before starting
tarpitting and defaults 0 (no tarpitting).
- tarpitdelay
is the number of seconds of delay to introduce after
each subsequent RCPT TO. Default is 5 seconds.
Instead, the environment variable TARPITCOUNT and TARPITDELAY can
be used.
2.8 LIMITING NUMBER OF RCPT TO:'S
---------------------------------
Sometimes it might be useful, to limit the number of RCPT TO's
i.e. the number of RECIPIENTS for a SMTP session. Actually, this
violates (as many SPAMCONTROL features) the SMTP protocol.
Thanks to Bruno Cesar for this suggestion.
However, this can be accomplished using the addtional control file
- maxrecipients
which defines the upper limit of RCPT TO:'s acceptable
for a SMTP session.
Instead, the environment variable MAXRECIPIENTS can be employed.
===================================================================
-- Jason
-----Original Message-----
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
Sent: 21 August 2002 06:27
To: James Developers List
Subject: Anti-SPAMMER measures
Jason,
Thanks. :-)
Do you have a recommendation for the tarpit? Some of the others, e.g.,
filtering during the SMTP session, will have to be postoned for later,
but I can see how to do a tar pit fairly quickly, and I would like to
discourage people from spending my transfer. Can you suggest reasonble
parameters that have worked in the real-world?
Yes, Danny, the tarpit will be fully controllable via the config.xml
file, and will default to off.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 5:12
To: James Developers List
Subject: RE: Lots of twisty, er, servers all the same ...
Jason,
Thanks for that insight. James as you've rightly guessed isn't suited to
big volumes, its better suited to lower volume traffic which requires
complicated processing. That said increasing throughput is a goal and
your points will be helpful. d.
> -----Original Message-----
> From: Jason Webb [mailto:[EMAIL PROTECTED]]
> Sent: 20 August 2002 09:08
> To: 'James Developers List'
> Subject: RE: Lots of twisty, er, servers all the same ...
>
>
> On a related note...
> I used to run a mail system with 2 million+ deliveries per day. We
> came across some intresting issues during very high-volume email
> transmission (and no it wasn't spam). We used Qmail and EzMLM (with a
> DB backend)
>
> 1) Limit the number of delivery threads on a per-domain basis. This is
> very imporant if you have a lot of users with AOL accounts (or ATT for
> that matter :-)).
> 2) Agressively "cull" SMTP sessions that last longer than say 10
> minutes. This stops a trivial DOS attack clogging up the mail server
> 3) Timeout the delivery threads with an exponential back-off (Not sure
> if this is done already)
> 4) Up-front spam rejection. Tell blocked senders and spammers to ****
> off in the SMTP handler, not just within the mail processor itself.
> This will cut down on server load.
> 5) Tar-pitting - slowing down connections that do a lot of "RCPT TO:"
> - again using an exponential back-off
>
> These are a few things that James needs to do to make a real-world,
> volume solution. Qmail is not an elegant solution, but it is fast...
>
> -- Jason
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
