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: [EMAIL PROTECTED] 250 2.1.0 [EMAIL PROTECTED] Sender ok RCPT TO: [EMAIL PROTECTED] 550 5.0.0 [EMAIL PROTECTED] 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 _______________________________________________________________________
_______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
