On Thursday 03 February 2005 4:22 pm, Matt Kettler wrote: > At 06:13 PM 2/3/2005, Brian Godette wrote: > >Those sorts of mail servers end up in my firewall rules till some point in > >the > >future. > > I started off using a shun on them as a short-term fix, but then went to a > 500 error message for all mail from the server in /etc/mail/access. > > They seem to behave properly upon getting a 5xx and go away until a new > spam is queued, so it's less bandwidth for me if I do that then let them > continually try to reconnect and fail to get any answer. It also gives me > an opportunity to bounce back a message about why I'm blocking them.
My observations indicate the opposite, they just keep trying, often very rapidly. Plus a silent firewall drop of SYNs behaves as a mini-tarpit, the thread attempting to connect to you is blocked until connect() times out. > > In general doing a 5xx is better than a firewall block, unless the server > is so broken it doesn't respond to 5xx's and keeps retrying anyway. I should probably explain how IPs end up in my mail server firewall. I use a slightly modified version of watch-maillog (http://taz.net.au/postfix/scripts/watch-maillog.pl) to automatically add/remove IPs based on regexs on a tailed mail log. This stops dead any dictionary attack or any other 100% spam-source thing you can make your MTA log such as rejecting invalid HELOs using your MX's own IP or hostname(s). Yes it's kinda like grey-listing, but without the initial first time penalty, however care must be taken to have the expiry times reasonable or the iptables rule lists becomes much too large and eventually chews up all available CPU. The "too many" firewall rules case is one of the modifications I made, I limited the max rules, removing the next due before is was supposed to happen.
