[Gllug] SPAM - trying to block at SMTP level

t.clarke tim at seacon.co.uk
Wed Feb 16 12:57:31 UTC 2005


Hi all


I have been pondering upon the problem of spam and thought it worthwhile to
run a few ideas past you all, as I am sure that spam filtration is an area
for which many of you must qualify for the 'been there, done that and got the
T-shirt' award!

Firstly, we have not opted for using any of the 'normal' spam-filtering
techniques whereby potential junk emails are identified and placed in a
separate 'holding' area or somesuch.   At present, in order to preserve
our limited bandwidth via our kilostream circuit (regrettably too far from the
exchange to use DSL), we are keeping track of originating email domains and
rejecting mail from domains that:
a) we dont recognise and b) have exceeded a couple of emails without being
'registered' as known to us/
This strategy allows occasional originators to reach us without rejection on
the first couple of occasions, but blocks persistent senders who send us
unwanted emails (spam or otherwise). For example, I note that last night about
900 incoming emails were rejected from 'doteasy.com' addresses.
The rejection is done at the SMTP 'mail from:' level, so very little bandwidth
is wasted.

The strategy catches a reasonable percentage of spam, but still a fair amount
gets through (unfortunately, particularly to me) from originating addresses
that appear to be used only once (and are subsequently found to be bogus)
and thus are allowed for that first time.  This does not cause any particular
problems in dealing with the mornings incoming email pile, since these emails
are 'flagged' as 'unkown sender' and be skipped very simply.  However, the
problem of bandwidth consumption remains.

A number of thoughts have occurred to me as to methods to deal with these
'one off' spam emails, but I am not sure as to whether they would be practical.

Firstly, one could possibly 'chop off' unknown senders emails after the first
N characters (say 3000) with a 'receivers mailbox full' type of message.
This would limit bandwidth usage but at the same time forward enough of the
email to the recipient to identify the sender and his/her intentions and
request retransmission of the email if required.   I believe there are also
patches around to our (qmail) smtp server to reject base64 attachments, where
required, at the smtp level.

Another possibility might be, where a sender is 'unknown', to either
reject, with a permanent or temporary error-code, emails where the originating
machine is not running an smtp server on port 25.  This might result in some
erroneous rejections, but I am guessing that a lot of the spam originates from
robots that are doing outgoing smtp only.  It certainly appears that all the
genuine email we get originates from machines that both sned and receive email
via SMTP.   I accept that probably hotmail/yahoo are exceptions and do not send
and receive on the same IP addresses!

Anyway, I thought before doing any actual experimenting, it would bne a good
idea to get your various thoughts.

Sorry if this post is a rather long-winded!

Tim


--------------------------------------------------------------------------------
This E-Mail (and any files transmitted with it) is intended solely for the use
of the individual or entity to whom it is addressed. If you have received it in
error please notify the sender and delete the message.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list