[Mimedefang] Blocking spam senders using IPTables?
jebright at esisnet.com
Wed Nov 3 08:56:14 EST 2004
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
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).
On Wed, 3 Nov 2004 10:51:51 -0000, Paul Murphy wrote
> > Seems to me this would be much better served implemented as a DNSRBL than
> > iptables solution. By using your own DNSRBL, you would have a scalable,
> > compliant solution that still drops the connection well before the "data"
> > phase and before any mimedefang/SA processing, if you implement the
> > 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 Murphy
> Head of Informatics
> Ionix Pharmaceuticals Ltd
> 418 Science Park, Cambridge, CB4 0PA
> Tel. 01223 433741
> Fax. 01223 433788
> 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
More information about the MIMEDefang