Hi Alice, On Sun, May 1, 2016, at 08:44 AM, Alice Wonder wrote: > If the IP is on a blacklist I use, I just let the blacklist deal with it via > reject.
Generally, I do too. TBH, it's those new-not-yet-on-a-list IPs that got my attention on this. > I'm somewhat conservative with the blacklists, many of them > are too aggressive with adding IP addresses that aren't actually > spammers, and that's bad in my opinion. I agree with the opinion. My experience has been few-to-zero FPs. I understand that's partly luck. > If the IP is not on a blacklist but I have received multiple spam from > it in short period, I just block the IP the firewall - but only for > three days. If it happens again then I firewall that IP for a week. I've put in place Fail2ban for just such instances. Tho, I'm mulling over the how-many-per-time policy that works best for me. > I prefer firewall because if an IP is acting badly, it may be hacked and > may try compromising other services I run. Fair point, tho the rest of my firewall is already pretty tight. > Everything else I just let SpamAssassin assign a score to and let the > user receiving it filter how they see fit. For the stuff that gets that far, agreed. > Interestingly, I have one server fairly recently set up that breaks the > rules by only allowing TLS connections. > > So far that has done an amazing job at preventing these mass mailers > from even connecting, with only a few legitimate connections rejected > (stuff like some wordpress blog notifications set up to use qmail with > no TLS have been rejected) > > Of course it probably won't be too long until the mass mailers start > using TLS, but I'm enjoying the lower spam volume in the present ;) I've come across that approach more and more. Definitely possible to cause a lot of breakage -- so not an option for the big ISPs I suppose -- but for smaller, company & personal servers, I've been reading a bunch of "well worth the risk" sort of comments. > For restrictions that are not IP based - I believe reject is better on > the off chance that the filters are wrong and it is false positive. > That way the sender can notify me of a problem. With just discard, they > don't know it never got to where it is going. I have some helo checks, etc that are, in my book, "definites", but I get your point. > It's just data, it can't act by itself, so yes it is safe to accept the > whole thing and trash it. That's fair re: the safety part; only other issue, I suppose, is the performance/load of accepting a 'large' message. > You can't scan the payload with your malware checker if it isn't there, Yep > but if you are so confident an IP is sending you bad stuff like that - > just firewall the IP to prevent it from trying to exploit other services > you have running. Thinking about it, REJECT as policy, with Fail2Ban for the nastier stuff seems like a good mix. > In my opinion. Which others may have valid disagreements with. Appreciated! That's what I was asking for. Jason
