Look to spamd* on OpenBSD/PF - a SMTP tar pit. also see
http://benzedrine.cx/relaydb.html for analysis and implementation. This ties
into your DNS rbl systems and advert diverting proxies. This feedback into
the DNS layer is getting complex enough for an API of it's own?
*not the same as SpamAssassin's daemon
-----Original Message-----
From: Tim Meadowcroft [mailto:tim(_at_)schmerg(_dot_)com]
Sent: Saturday, May 22, 2004 5:07 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Tarpitting and SpamCannibal (was Re:
Brainstorming RFROM variants)
On Saturday 22 May 2004 00:54, Seth Goodman wrote:
The qsmtpd list has had much discussion of the
"spamcannibal" approach
in which your MTA informs your firewall to drop a random
half of the
packets arriving on this eschewed connection.
Sounds interesting. What can you tell us about this?
I sort of started it off by suggesting a change to qpsmtpd to
add a "tarpit"
return code that would bog down the sender (originally the
idea was just to
sleep for a while between replies to slow down the sender).
Unfortunately the
way qpsmtpd is typically run with tcpserver or the like
(which puts a limit
on the number of concurrent connections), this isn't such a
great idea (you
end up DOS'ing yourself), so Matt Seargeant suggested instead
passing the
offending socket to a seperate daemon (quoting some Stevens
code to do this)
which would just tarpit all the sockets it received and throw
the data away.
Then someone suggested the more sophisticated SpamCannibal
(www.spamcannibal.org) which I looked at, and is nice but has
a very specific
setup, but basically it builds a database of offending source
IP numbers
(including reading black hole lists), and then uses iptables
to tarpit any
new connections from those IPs: it filters the initial TCP
connect and, in
completing the handshake, it sends back flow control flags
that set the
packet data and packet window to very small numbers, and then
it throws away
any packets received on that connection without ACKing them
(and they never
get to your SMTP server). In this way SpamCannibal itself is
stateless and
requires very few resources but the sender is bogged down
sending packets
that never get ACK'ed, the author claims to have tarpitted
certain single
connections for 3 months before the spamming software gave up.
The problem is that you can't do this part way thru a connection with
SpamCannibal, so I thought I'd adapt qpsmtp so that you can
soft-fail a
connection (replies with a "try again" error code and closes
the socket) when
you figure they're a spoofing spammer, but at the same time
you add the
offending IP to SpamCannibal (or a reduced copy of the key items of
SpamCannibal) for new connections in, say, the next 24 hours.
But my setup here is a bit screwed with respect to iptables
and a few other
things SpamCannibal needs, so this has moved down the queue
until I get a
weekend to get the prerequisites in and working.
To my mind this sits very well with SPF - I'm happy to
blindly tarpit any IP
that spoofs a sender name, whereas I wouldn't want to blindly
tarpit hosts
that send me spam or else I'd be forever blocking hotmail,
aol, yahoo etc.
etc.
Cheers
--
Tim
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-200405.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com