And again, my suggestion for this would be to use the DNS RBL from sendmail, which will be the lowest overhead, and if you have trouble with hosts that aren't listed, then have your daemon add those to sendmail's "access" file and remake the db. All of this data will then be processed by sendmail, at connection time only, and should have very low overhead.
I'm currently looking at several options to deal with our spam problem. We've tried RBL's via MailScanner (a Sendmail "frontend", if you will) but it simply gets too bogged down. Sendmail had similar issues, though not as bad.
You'll see consistant, short delays in sendmail, but nothing that should kill you. If you're only using RBL's anyway, your daemon doesn't get you much but a constantly growing list of spammers who've connected to you. If you have a local DNS cache, RBL lookups from sendmail will prevent the problems you're describing with your current setup.
To give you an idea of the problem, I started using SMTPBlock last Wed. It's already gathered over 10,000 IPs. The first few days were dreadful--watching the server 24x7--it would crash every so often due to the load it was trying to handle. Now, it's maintaining itself.
Not surprising. I don't think netfilter was meant to be used that way. The results you got are exactly what I'd expect:
Doctor, it hurts when I do this...
We were receiving several THOUSAND emails per hour. Now we're receiving less than 100.
The same reduction in volume would be acheived by the standard RBL setup, except that you wouldn't get that one successful connection that you do now.
Additionally, real persons who try to send you mail with your iptables setup will eventually (possibly after several days) get a notice that your mail server is unavailable: bad PR for you, it looks like your server is down. The RBL method allows you to inform other users that you're not accepting mail from them because their server is misconfigured, and how they can go about fixing the problem.
Either MailScanner (or Sendmail, for that matter) would have to query the RBLs EVERY time it receives an email.
Yes, but if you have a DNS box nearby, that's not a problem.
The idea behind using IPT for blocking is that it removes those entries from my logs, the packets are dropped as they come in (no other processing is done), and it provides a front line of defense--that is, IPT should handle this much better and (in theory, anyway :-) ) be much faster than "user space" programs like Sendmail because it's working at the Kernel level
Except that it's not because all of your TCP traffic ends up going through this history, rather than generating one DNS lookup per SYN packet. Seriously: the box was crashing. The system CPU utilization is very high. How can you conclude that this method is "faster"?
There's a reason that RBL's are done with DNS. It provides a fast lookup method for a database of bad hosts. If it were efficient to do this in firewalls, you'd find a lot more documentation on how it's done.
-- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
