Comments in the body...
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 21 August 2002 16:48
> To: James Developers List
> Subject: RE: Anti-SPAMMER measures
>
>
> 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.
>
I always think that it's your (local) choice. We used the defaults, but
with another script killing socket connections older than 10 minutes, so
they may have fought with each other! In my experience mail servers &
clients don't normally do one delivery per mail, but more on the lines
of one delivery per recipient. So anybody sending more than 2 (or up to
5) should be tarpitted. Any more than 10 and you're a spammer. In the
event you actually kill the connection for this reason, I think this
event should be logged with the suspects IP address at least.
> 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.
>
Agreed. Qmail does a lot of the spam filtering up front in the SMTPD
(port 25 listener). The object of the exercise is always to the spammers
off your server as quickly as possible.
> 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.
>
Agreed. The blocking should be done by mailets in the case of mail
address. A wildcard address blocker (*@themail.com) is much better
implemented as a mailet.
I would suggest that a pipeline model is followed. For example:
(In the SMTP handler)
Block bad IPs (simple, low overhead)
RCPT TO counter (fast)
Bad MAIL FROM: (Not sure)
Tar pitting
(In mailets)
Bad domains (reverse lookup?)
Subject checker ("mail dollars fast" etc)
The other thing you don't want to do is implement VRFY via. the
backdoor, by sending reject messages back to the spammer for bad
addresses. Then they will know if they've got a good address. Junk the
mail or send it to another account for analysis.
> 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.
I would make it persist for forever.
>
> Thoughts on the concept of adding support for a real-time
> filter into the SMTP handler?
I like it! However, I would suggest caching as much as possible when the
server starts, with a write-to-disk in the background. Also good logging
is essential if there is a hiccup in the rules.
>
> --- Noel
<snip'd by JW>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
