Jason,
Thanks. I think I see a way to patch James to be less SPAMMer friendly. To
implement a delay, I can put a delay in handleConnection in the loop that
calls parseCommand. I'd need to be able to configure it, of course, and
keep within reasonable parameters.
Sounds like the qmail patch just uses a constant 5 seconds after 50
recipients. I might not want to wait that long on my own server. I am
seeing multiple blasts of no more than 20 recipients at a time, but 100s of
them.
My current thought is to create an real-time filtering object in the
MailetContext that I can share between the SMTP handler and the
matcher/mailet infrastructure. This would allow them to communicate without
changing the way that James' spool processing works. The only internal
filtering that the SMTP handler might do would be based upon RCPT TO count
(the result of which would be cached for later reference in the shared
content). Otherwise, the handler would be educated by the configured
matchers and mailets.
The shared content would provide real-time filtering information for the
SMTP handler. For example, it could contain a whitelist, it could contain
code that checks an RBL, it could contain a list of currently identified
abusive IP addresses, etc.; whatever was desired in terms of real-time
filtering. But we wouldn't have to do constant real-time verification of
recipient addresses, for example, which might be rather a chore given
mailing lists, etc., which aren't even included in the current user
repository model.
And it would be persistent, at least for the session. So, for example, once
an IP address gets flagged, when they come back the handler could
immediately tarpit (or reject) them. Until the server is restarted, at
which point it would start over. I suppose that at some point if they reach
a defined threshold, instead of continuing to delay them, we reject them
with an error status.
Thoughts on the concept of adding support for a real-time filter into the
SMTP handler?
--- Noel
-----Original Message-----
From: Jason Webb [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 21, 2002 4:34
To: 'James Developers List'
Subject: RE: Anti-SPAMMER measures
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
