[H-GEN] Email filtering

Greg Black gjb at gbch.net
Wed Sep 24 08:35:00 EDT 2003


[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On 2003-09-24, David Duffy wrote:
> Greg Black wrote:
> 
> >If you reject the connections based on their IP address, then
> >none of the mail gets through to you.  But, with these specific
> >messages, that is not generally possible or desirable.
> 
> So the access file acts on the email's IP/domain before even
> accepting the whole email? I currently use this to block the
> known repeat spammers.

The precise mechanism depends on the various software elements
involved.  On my systems, there are several programs that handle
each incoming SMTP connection before the actual SMTP server gets
to look at it.

In the first place, you have a connection from some IP address
on some port (in this case, port 25).  The first level of access
control looks at the IP address and, if that's a blocked IP, the
listening program just drops the connection without any other
processing (except, perhaps, a delay to waste a bit of the
offender's time).  In this case, usually used with external
blacklists, there is no data transaction at all.  However, as
already discussed, that's not a viable solution to the current
virus problem.

> OK, I see what you mean. To make an intelligent descision on whether
> or not you want the email, you really have to accept it, see if it is crap
> and then drop it into the bucket if it is. All in all, there's no real 
> way to
> refuse the mail unless you *know* the IP address is definately a dud.

Not quite, but I don't know if any of the mainstream MTA's have
such a capability.

An SMTP transaction consists of a series of messages in both
directions.  These identify the parties (not reliably when they
are bad guys), state the sender (again, not always reliably) and
recipient(s) of the email and then the receiving host tells the
sender to go ahead with the data (which is the message with all
its headers).  If the receiver chooses to parse the data, and
decides it doesn't like it, there's nothing to stop it from
closing the connection -- it would then need to refuse further
connections from the same IP for at least a while.

This wold be easy to program.  I don't know if anybody has done
it.  I could not be bothered, myself.

> >Whatever you do, don't bounce the messages -- that will only
> >make things worse and won't help anybody.  If you identify them,
> >just drop them on the floor.
> 
> Is dropping still better than rejecting even with known spammers?
> I mean, if the get a reject, do they remove your address?

Bear in mind that this stuff, although classified in our minds
as spam, is nothing of the sort -- it's a virus targeting
Microsoft systems, not advertising for some money-making
product.  With real spammers, they don't use the SMTP protocol
correctly at all.

For instance, here's a legitimate SMTP transaction, typed in by
hand:

	$ telnet bambi 25    
	Trying 172.16.1.2...
	Connected to bambi.gbch.net.
	Escape character is '^]'.
<--	220 gw.gbch.net: relaying and uce/ube/spam not tolerated ESMTP
-->	HELO felix.gbch.net
<--	250 gw.gbch.net: relaying and uce/ube/spam not tolerated
-->	MAIL FROM <gjb at gbch.net>
<--	250 ok
-->	RCPT TO <gjb at gbch.net>
<--	250 ok
-->	DATA
<--	354 go ahead
-->	From: gjb at gbch.net
-->	To: gjb at gbch.net
-->	Subject: testing
-->	Date: Wed, 24 Sep 2003 22:21:19 +1000
-->	Message-Id: <nospam-1064406108.79683 at bambi.gbch.net>
-->
-->	This is a test.
-->	.
<--	250 ok 1064406134 qp 79674
-->	QUIT
<--	221 gw.gbch.net: relaying and uce/ube/spam not tolerated
	Connection closed by foreign host.

The lines prefixed with --> are what I typed at the listening
SMTP server; the lines prefixed with <-- are the responses it
sent to me.

Spamware just blasts all its stuff out without taking any notice
of the responses or even waiting for them.  It certainly takes
no notice of specific error codes.  However, some spamware does
take note if a MX host drops the connection before it has sent
its message and then aggressively tries alternate MX hosts or
even repeatedly tries the same host.  In all such case, dropping
the connection is the only useful strategy[1].

Cheers, Greg

[1] By "only useful strategy", I mean it's the only strategy
    that I find useful; if I had the time and financial
    resources to go after spammers with a baseball bat, then
    there are other things I might do ...

-- 
Greg Black <gjb at gbch.net> <http://www.gbch.net/gjb.html>
GPG signed mail preferred; further information in headers.

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/



More information about the General mailing list