[Mimedefang] Blocking spam senders using IPTables?

[James Ebright]

Paul,

No, I understand your point, it is just that by using IP tables to drop the 
connection _very_ few packets before sendmail (postfix, etc) would (if using 
your own DNSRBL, i.e. install the software and lock it down for your own use 
yourself...) you do not gain alot and loose RFC compliancy.

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.

Dropping a connection at the firewall level (IP tables) would indeed save you 
a few bytes of connection data per request... but at the cost of true 
scalability across clusters and RFC compliancy.

If you are looking for a simpler approach than DNSRBL then perhaps you can 
use sendmails (postfix, etc) access list. If you are not delaying checks it 
would have the exact same benefit, and not involve one extra DNS lookup, just 
a hash table lookup, and still be fairly easy to maintain across multiple 
nodes.

Ultimately.. I think the reason you are seeing the data come in before your 
server finaly sends a 5xx reject is the way your filters/milter are setup, if 
you used an access list or DNSRBL to send the reject earlier you would not 
incur the data phase hit at all. A simple test of this would be to hardcode a 
pattern match for one of them in filter_sender and enable that filter in 
mimedefang and see if  your mail server now drops the connection earlier, 
before the data phase... but.. I still think dropping before you even get to 
a costly milter would be best (access list, DNSRBL, etc).

James Ebright
ESISNET, LLC
www.esisnet.com 


On Wed, 3 Nov 2004 10:51:51 -0000, Paul Murphy wrote
> James,
> 
> > Seems to me this would be much better served implemented as a DNSRBL than 
a 
> > iptables solution. By using your own DNSRBL, you would have a scalable, 
RFC 
> > compliant solution that still drops the connection well before the "data" 
> > phase and before any mimedefang/SA processing, if you implement the 
DNSRBL 
> > inside your mail server software itself.
> 
> You've missed my point - RBL lists have their place, but when the 
> sender is badly behaved, they add nothing to the solution.
> 
> My scenario is a sender who keeps trying no matter how many times we 
> send a 5xx response code, and who in some cases uses a mailer which 
> stuffs the whole message down the connection before you even get a 
> chance to say hello.    Even using a RBL, the bandwidth has been 
> used, and the system has incurred the load of handling the packets 
> and doing lookups.  The greeting delay feature introduced in the 
> latest Sendmail incarnation also doesn't help, as the greeting is 
> ignored and the Sendmail daemon still has to process the queued packets.
> 
> At the IPTables level, Sendmail never sees the packets, and the very 
> limited processing is done by the kernel using optimised packet 
> matching and filtering routines.
> 
> 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
> _______________________________________________________________________


--
EsisNet.com Webmail Client