[milters] Archive

Lists Index Date Thread Search

Article: 341
From: Georgy Salnikov
Date: 2005-02-17 07:44:28 -0500
Subject: Re: user account fishing

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

On Thu, 17 Feb 2005, Anthony Howe wrote:

> Aaron Berg wrote:
> > Does anyone know of an effective way to block ip addresses for some
> > period of time if they have requested to send to say 10 user unknowns in
> > some period of time?
> > Thanks for any input,
> > Aaron
> This was something I had considered for milter-limit (milter-miss was
> the project idea), but one of the difficult things with the milter API
> is finding out the reason a message is rejected or aborted by Sendmail
> or another milter, because the API has no logging, stats, or reporting
> features for milters to collect such information. Best you can do in a
> milter is say something like:
> 	N aborts per IP / domain / sender and you auto blacklist
> xxfi_abort is called for each milter when a message fail to be accepted,
> but doesn't say why.
> If people think this interesting, I can consider resuming the idea once
> again.

Blacklisting will not achieve the main goal in this case. The real problem
scenario is usually like this:

Spammers begin to attack with thousands of simultaneous mails varying the
recipient field (most of the recipients not existing).

The sendmail daemon on the recipient side will be flooded with the big
number of incoming mails. It will respond to some spammers with TEMPFAIL due
to graylisting, but to some of them it will start MX callback which may take
more time. Then more spam mails will be answered with some TEMPFAIL like 'I
am busy, please try again later' (because too many sendmail instances are
already doind SMTP dialog with the preceding spammers).

Negative is that good mails also get TEMPFAIL 'busy, try later' until this
spam attack finishes, it takes usually about one hour. The problem is not
that someone receives spam (spam is blocked anyway), the problem is that
sendmail daemon is too busy to be able to deal with good mails in the time
of a spam attack.

The only working solution might be in a short period of time to detect the
fact of such an attack (with some kind of spamshield script for example) and
automatically block the connection packets originating from the spammer
address via iptables on the firewall

iptables -A FORWARD -p tcp -s <spammer IP> -d <sendmail IP> --dport 25 -m
state --state NEW -j DROP

Then the spammers which have already opened their connections obtain quickly
their TEMPFAIL, and more spammers cannot setup new connections. In a few
minutes sendmail begins to deal with good mails again.

This iptables rule may be arranged to be removed by another robot in some
period of time if permanent blocking is not desirable.

Georgy Salnikov
NMR Group
Novosibirsk Institute of Organic Chemistry
Lavrentjeva, 9, 630090 Novosibirsk, Russia
Tel.   +7-3832-356416   +7-3832-331456
Fax                     +7-3832-331456
Email   sge@nmr.nioch.nsc.ru

Lists Index Date Thread Search