[Slightly OT] New Spam Fighting Technique

John Rudd jrudd at UCSC.EDU
Fri May 7 19:36:45 IST 2004


I have a friend who played around with delaying the initial 220
greeting that an SMTP server sends after connection.  The idea is that
the RFC says that the remote side should be willing to wait up to 5
minutes before receiving the initial 220 greeting, AND that it
shouldn't send any commands before it receives the 200 greeting.

He found 2 things:

1) remote MTAs for legit mail are patient and will wait, but on a
varying scale most spamware will not wait (remember, their margins
aren't as big as people think, and the biggest factor in their
profitability is "how many messages per second can I deliver", so
making them wait costs them money).  According to his statistics, he
catches 90% at 35 seconds and 100% at 85 seconds.

2) a significant number of them try to do blind SMTP sessions, meaning
that they connect and just start sending ALL of their commands without
waiting for any responses from the server.  So, no matter how short
your delay, if the remote side sends data before the delay is up, it's
probably a spammer trying to do a blind session.

His write-up of what he has been doing is here:

http://www.armory.com/~spcecdt/spamware/

One of his users has managed to get support for this idea into the
upcoming releases of Sendmail, and I managed to convince CommuniGate
Pro to get it into their current beta release (4.2b2).  But, if you
can't wait for that, and you run an MTA that can be managed from inetd,
you could also make this happen via a wrapper script.  (keep in mind
that sendmail recommends that heavy traffic sites not invoke sendmail
via inetd, but this might significantly reduce your traffic, as well,
so it's hard to say where the right balance point is)

For working with mailscanner, this basically means removing the version
of sendmail that you run with "-bd" from your start up scripts.
Instead, create an inetd.conf entry like this:

smtp  stream  tcp  nowait  root  /usr/local/etc/sendwrap  sendwrap

For the sendwrap ("sendmail wrapper") script I give, you just need to
modify the "@addrs" array to have regular expressions that match your
network(s).  If you only have one network segment, then you can
probably just replace my first entry (which is in the 10.0.1.0/24
network) with your own ... networks that match the ones in that array
do not receive the delay (so that your local users aren't getting a
long delay between hitting the "send" button and when the window
finally goes away).  You'll also need to pick your own delay_time (I
went with John Dubois' 90th percentile, so that legitimate remote
networks don't have to wait TOO long).  If you're using sendmail, then
you might need to adjust the path, but that should be it.

Let me know what you think, and how it affects your spam traffic.

Here's my sendwrap script:

#!/usr/bin/perl

use Socket;

my $rin, $rout, $nfound, $port, $paddr, $addr, $remote, $pattern,
$delay;
my $delay_time = 35;
my $sendmail = "/usr/sbin/sendmail";
my $sendmail_args = "-bs -OPrivacyOptions=noetrn
-ODeliveryMode=queueonly -OQueueDirectory=/var/spool/mqueue.in";
my $sendmail_command = $sendmail . " " . $sendmail_args;

my @addrs = (                                      # addrs we wont delay
           "^10\.0\.1",                             # as regular
expressions
           "^127\.");

vec ($rin, fileno(STDIN), 1) = 1;                  # set up for the
select()

($port, $paddr) = sockaddr_in(getpeername(STDIN)); # get the remote IP
addr
$addr = inet_ntoa($paddr);                         # convert it to a
string

$delay = 1;                                        # set the delay
foreach $pattern (@addrs) {                        # unset if in addrs
array
    if ($addr =~ "$pattern") {
       $delay = 0;
       break;
       }
    }

unless ($delay && ($nfound = select($rout = $rin, undef, undef,
$delay_time))) {
    # if they aren't delayed, or if they are delayed and didn't send
    # any data while being delayed
    exec $sendmail_command;
    }

-------------------------- MailScanner list ----------------------
To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
Before posting, please see the Most Asked Questions at
http://www.mailscanner.biz/maq/     and the archives at
http://www.jiscmail.ac.uk/lists/mailscanner.html



More information about the MailScanner mailing list