OpenBSD's spamd.

[Christopher Hilton]

JoaoBR wrote:
> 
> why the spam daemon should introduce an artificial delay 
> (tarpit) if this can be done already before like Oliver 
> said, it would only eat up and slow down threads  between 
> both daemons (smtp + spamd) and overall spamd doesn't even 
> talk directly to the remote smtp
> 

Spamd does talk to the remote smtp. It does this until it determines 
that the remote smtp is RFC compliant in the area of retrying mail. On 
the first delivery attempt it sets up a time window for the delivery 
tuple: (server, sender, recipient). If it receives another delivery 
attempt within this time window it modifies a PF table which allows 
further delivery attempts to bypass spamd and talk directly to your 
actual smtp daemon. Without this entry remote smtp daemons talk to your 
spamd.

The tarpitting features of spamd are handy. Bob Beck, the author IIRC, 
watched connections to his spamd and noticed that the when tarpitted, 
the spammers and only the spammers were disconnecting from his machine 
and giving up on delivering the spam at all after ever shorter 
intervals. When the spammers got down to 3 seconds of tarpitting before 
they disconnected he added a feature to spamd that allows you to tarpit 
all inbound smtp connections for a configurable period of time (default: 
10 seconds).

So imagine being able to eliminate a portion of the spam that you get. 
This is spam that never gets to your MTA. It doesn't cost you CPU cycles 
in SpamAssassin and procmail or clamav. And all you pay is three seconds 
of the your firewall's time.


-- Chris