The key word in that statement from RFC 2821 is SHOULD which has a very specific meaning in an RFC as defined in RFC 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I certainly believe this situation qualifies and dropping a connection due to a "blast" would still keep you compliant. Looking at my log files I do NOT see the issue which you describe where a client continues to send data regardless of the commands returned. Of course I am not sure how much, if any, of that would be logged. I suspect only the initial connect and the quit would generate a log antry (along with any user unknowns generating entries as well) during the course of normal logging. Besides, what would it accomplish if the spammer ignored all return codes... they would NEVER be able to reliably send any mail. No, I am not claiming they (spammers) are "playing nice" but it to believe they are not capable programmers is to underestimate them. We examine between 160-180k messages daily and run a small delay without seeing numerous children hanging around either, so I believe I can logically conclude either it is not happening often here or sendmail is actually closing the connection after a DNSRBL or Access list violation (I would have to look at sendmails source to be sure though), or the client is actually issuing a quit and trying again. This all happens well before milter/Mimedefang/SA are involved. Also, it looks like I might try sending a 421 back from violations within my milters now instead of the 5xx as I see zero reason to allow client recovery based on a rule violation within my milter (depending on the particular rule). Jim On Wed, 3 Nov 2004 14:40:49 -0000, Paul Murphy wrote > 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: > > ..... -- EsisNet.com Webmail Client _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang