[Mimedefang] Blocking spam senders using IPTables?

[Paul Murphy]

James,

> I am not sure you understand how an SMTP conversaation takes 
> place... it is my understanding that the client cannot 
> "ignore" a 5xx response and continue blasting data... since 
> the server will not talk to a client after sending a 5xx 
> response and closes the connection. Thus after recieving 
> a 5xx return code a client would have to start over, 
> generating another 5xx... etc.

I understand it very well, thanks.  It appears however that you don't.

You are incorrect in saying that a client cannot ignore a 5xx response.  Try it
via Telnet and see what happens:

gate:~# telnet mail.example.com 25
Trying AAA.BBB.CCC.DDD...
Connected to mail.example.com.
Escape character is '^]'.
HELO mail.example2.org
220 Ready ESMTP
250 mail.example.com Hello mail.example2.org [FFF.GGG.HHH.III], pleased to meet
you
MAIL FROM: test at spammer.org
250 2.1.0 test at spammer.org... Sender ok
RCPT TO: pmurphy at ionixpharma.com
550 5.0.0 pmurphy at ionixpharma.com... We don't accept mail from spammers
DATA
503 5.0.0 Need RCPT (recipient)
Example data portion
500 5.5.1 Command unrecognized: "Example data portion"
.
500 5.5.1 Command unrecognized: "."
quit
221 2.0.0 mail.example.com closing connection
Connection closed by foreign host.

If you code the filter to issue a 5xx error at the MAIL FROM: stage, the effect
is very similar.  Spammers who stuff data down the pipe don't check the response
codes, so you have to accept each line of the message, parse it to see whether
it has a valid command, and then issue the 500/551 error.  Their aim is to
process several million messages quickly, and bandwidth is not generally a
concern (otherwise they'd take more care to clean up their lists to remove
addresses which are known to generate errors), so they don't implement much in
the way of error checking and recovery.  Yes, some will take the hint and go
away, but some don't, and some do but come back later.

To do what you suggest, the mail daemon would have to send the 5xx error, and
then send a TCP RST packet to the sender's port to effectively drop the
connection, but the RFC requires that it is possible to recover from a 5xx error
and to continue, since the server may have one address fail out of a batch of
20, or have 10 messages to deliver in one connection.  In any case, section 3.9
of RFC 2821 states:

"  SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly."

Therefore, compliant systems will keep trying, and will keep being dropped, and
will keep using up your resources.  Refusing the connection before the SMTP
server sees the packet is the only way to resolve this issue.

Basically, in a world where some people refuse to play nicely, it is naïve to
run your systems as though everyone does - you already filter for viruses and
spam, so this is just a refinement.

Best Wishes,

Paul.
__________________________________________________
Paul Murphy
Head of Informatics
Ionix Pharmaceuticals Ltd
418 Science Park, Cambridge, CB4 0PA

Tel. 01223 433741
Fax. 01223 433788


_______________________________________________________________________
DISCLAIMER:
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to which they
are addressed.  If you have received this email in error please contact
the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741
_______________________________________________________________________