Hi all, So I've been happily running qpsmtp for a few weeks, and I'm tempted to do some hacking, (er ... suggest some changes) but thought I'd ask for comments before starting.
I started off thinking that I'd suggest adding basic tar-pitting (http://www.gordano.com/kb.htm?q=1112) to selected plugins (such as SPF) that are detecting blatant abuse - the idea being that if a spammer has recruited 5,000 trojan home-cable machines worldwide to send out his spam, us just rejecting his connection at the start of a conversation might reduce our personal spam, but it doesn't hurt the spammer - in fact it saves him time (and therefore money) in that we've rejected him early and he's now free to get on to the next person (the equivalent of slamming the phone down on a tele-marketer, when what really costs them money is when they waste 10 minutes on the phone and then you slam the phone down). So, I was going to modify selected plugins to not just return DENY, but to waste a bit of his time too my ($result, $smtp_comment, $comment) = $query->result2($rcpt->address); if ($result eq "fail" and $self->{_args}{spf_deny}) { # added a delay (default 30 seconds) to tar-pit nasty joe-jobbers sleep( $self->qp->config("tarpittime") ); return (DENY, "SPF forgery: $smtp_comment"); } And then I figured that this holds up his SMTP conversation with me, but probably doesn't do much more if he's using multiple threads (well, it does, but not an awful lot) so then I thought why not exploit the fact that if he's recruited a lot of home machines on cable/DSL connections, they have asymmetric connections and so very limited upload speeds, so we want to waste his time/bandwidth transmitting the stuff, and thereby reduce the effectiveness of his 5,000 machines to some fraction of that number... So perhaps I could add a new plugin return code of "DENYEVENTUALLY", which remembers that we're going to reject his message, but lets him transmit the whole thing, DATA and all (discarding it all as I go, of course), before rejecting it, but slows down reading the socket so that he still has to send all the data, but it takes a long time - maybe long enough for someone to notice. I'd want to make sure that I don't end up doing a DoS on myself, so I'd probably put a cap on how many of these I'm running simultaneously and how much bandwidth they're using, but then I started getting all sorts of nasty thoughts about closing my end of the socket but sending back raw packets to leave his socket in the infamous FIN_WAIT2 state (where it chews up resources but can't be cleaned up)... and that's when I thought I'd check what the interested parties think of the idea - has it been tried, does it sound fun, does it already exist, do you already do this using one of these tcpwrapper / smtproute whatever mechanisms ?? I look forward to any comments ... Cheers -- Tim
