mouss wrote:
Kouhei Sutou a écrit :
Hi,
I want smtpd to abort a connection for a SMTP client as soon
as possible when the client disconnects the connection
before smtpd returns a response.
If you mean the ability to reject a connection before RCPT TO, then you
can change smtpd_delay_reject. but if you do so, MTAs that don't
"understand" this will retry.
if you mean the ability to disconnect instead of sending a response,
then the only compliant way is to return 421. so "real" MTAs will retry.
Note that postfix 2.6 also accepts 521 as a "reject and
disconnect" code. I've been using this on selected clients
for a while with no apparent ill effects. Most MTAs seem to
interpret this as intended. I suppose the worst that could
happen is a client would treat it as a temporary error and
retry later, so no worse than a 421.
as a result, the costs may increase!
finally, some ratware will retry whatever you return.
Indeed...
[snip]
Tarpitting is an effective anti-spam technique for some
spammers. The following figure shows about 20% spammers can
be protected by 65s tarpitting:
http://f.hatena.ne.jp/images/fotolife/s/stealthinu/20070705/20070705142716.png
I want to use tarpitting ONLY IF connected SMTP client is
very spammy because tarpitting may cause DoS. And I want to
reduce system resource usage caused by tarpitting.
Tarpitting can be done with SLEEP action in access(5),
policy server or sleep(3) in milter. All of them sleep
specified seconds even if connected SMTP client disconnects
a connection.
It's not very friendly to sleep 65s on every connection.
Hopefully you would whitelist clients known to pass.
The sleep action built into smtpd is not a very good solution
for tarpitting, it hurts you more than the spammer.
Future versions of postfix will likely support some sort of
low-resource front end for prescreening of clients.
... stay tuned.
-- Noel Jones
