Am 15.09.2014 um 22:31 schrieb Andrew J. Schorr: > li...@rhsoft.net wrote: >> what i recently implemented was >> * give thx MX a second IP >> * add it everywehere as backup-mx >> * disable postcreen WL on that IP > > I am doing the same thing here. It is helpful, but I don't think it solves all > problems. The implicit greylisting of the deep protocol tests seems to help a > lot. > > Thanks for sharing your postscreeen dnsbl and spamassassin configurations. My > experience is also that the default spamassassin scores don't seem to be > properly weighted to stop the spam we are receiving. The deep protocol > greylisting, however, is really effective, so the spamassassin configuration > becomes much less important. > > I could be wrong, but if greylisting works reliably, it feels safer > to me than adding a ton of blacklists. I'd rather get a legitimate email > a bit late than not at all due to a false positive blacklist reject.
my expierience is that greylisting makes often headaches a ton of blacklists itself is unsafe because a mistake on one of them is absolute, "a ton" of blacklists with careful chosen scores prevents false positives of a single RBL and playing a lot while watching logs shows that most real spam is on at least 3 or 4 lists reaching the count to block besides dialup-ranges i don't trust any RBL enough to make a final descision, backscatterer as example must not be used for blocking desicisons - but i see a lot of cases where the other RBL's reached a score of 7 and the one point from the backscatterer list (alone zero power) made the final decision to reject backed by others there is for sure some space what weight each lists becomes but the summary is a low-brainer because if someone is on 3 or 4 RBL's i can argue "look, you did something wrong" a single RBL - well, Spamhaus recently blocked a large german hosting company (1&1, web.de, GMX) by mistake, not on the dialup lists but on the spam-list - using that lost for blocking -> a lot of phone calls what i did additionally is setup 4 internal DNSWL lists with different trust levels as well a internal RBL feeded by a honeypot listening on unsued IP's - that DNSWL are also used in SpamAssassin for scoring and depending on the trustlevel override other postfix settings like SPF checks, HELO-restrictions, spoofing protection and so on the goal was doing most decicions score / trust based with the knowlege of the past years where own users are sending with the wrong outgoing server, what are real money institutes to throw a measureable negative score and prevent catch them with fraud scoring - makes the decision "money spam or a real bank" safer and gives the opportunity to raise the phising scores really high without risk too much false positives well, there will be never a perfect solution, otherwise spam would not exist because 100% blocked but for 10 mail accounts 5-10 spam mails to feed bayes with no known false positive for some weeks (the inbound system replaced a commercial solution 3 weeks ago) feels fine - in summary not really more junk making it to the backend servers but *a lot less* false positives than before
