[Mimedefang] Blocking spam senders using IPTables?

[James Ebright]

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