From: Andy Dills on 27 May 2010 09:34 I've been investigating postscreen, as we've been address probed/bombed for years, as we have a few domains that are very old (well, early 90s) that had a lot of users back in the dialup days. Our approach was to just throw hardware at the problem, and we've had a whole cluster of servers just sending out 550s all day long for years now. We don't do any RBL checks at the postfix level; we have amavisd-new handle all of that via spamassassin. I'm hesitant to allow a single blacklist to determine the fate of mail acceptance, especially when we have a very low false negative rate with amavisd/SA. Essentially, we'd rather throw hardware at the problem than potentially reject legit mail. My primary question is, would we see significant improvement by using postscreen if we don't use RBLs? Also, would postscreen_cache_map work with a mysql backend? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
From: Robert Schetterer on 27 May 2010 10:19 Am 27.05.2010 15:34, schrieb Andy Dills: > > I've been investigating postscreen, as we've been address probed/bombed > for years, as we have a few domains that are very old (well, early 90s) > that had a lot of users back in the dialup days. Our approach was to just > throw hardware at the problem, and we've had a whole cluster of servers > just sending out 550s all day long for years now. same here, old short domains, openrelays in early times but checked to handle it with one machine, but of course yours might be more spammy at all > > We don't do any RBL checks at the postfix level; why do you not use selective rbl checks, only for dynip etc, as well as greylisting, there are a lot good cheap tricks with restictions that should help and/or perhaps use recent with iptables and/or fail2ban we have amavisd-new > handle all of that via spamassassin. I'm hesitant to allow a single > blacklist to determine the fate of mail acceptance, especially when we > have a very low false negative rate with amavisd/SA. Essentially, we'd > rather throw hardware at the problem than potentially reject legit mail. amavis should not gamble a lot with spam/virus until if you have good checks before it i have one support ticket a week i.e. by 3000 Mailboxes, mostly problems of the sender, extrem rare rbl related, nothing that cant be handeled easy > > My primary question is, would we see significant improvement by using > postscreen if we don't use RBLs? as far i know postscreen should help anyway but you should measure aud investigate your logs if a cheap/short 550 is more usefull sometimes > > Also, would postscreen_cache_map work with a mysql backend? dont think so, but gurus should know exactly > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- after all dont expect spammers/bots will give up only cause you have new antispam features integrated you may clean up your logs and/or need less resources but at my spam domains , spam traffic was never related to what antispam feature i ever integrated it was always in waves -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
From: Wietse Venema on 27 May 2010 11:19 Andy Dills: > > I've been investigating postscreen, as we've been address probed/bombed > for years, as we have a few domains that are very old (well, early 90s) > that had a lot of users back in the dialup days. Our approach was to just > throw hardware at the problem, and we've had a whole cluster of servers > just sending out 550s all day long for years now. > > We don't do any RBL checks at the postfix level; we have amavisd-new > handle all of that via spamassassin. I'm hesitant to allow a single > blacklist to determine the fate of mail acceptance, especially when we > have a very low false negative rate with amavisd/SA. Essentially, we'd > rather throw hardware at the problem than potentially reject legit mail. > > My primary question is, would we see significant improvement by using > postscreen if we don't use RBLs? In my experience, the "pregreet" check kills off 50% of the zombies. Of course malware will "improve" and I expect to add deeper protocol checks (command pipelining, greylist) in anticipation. > Also, would postscreen_cache_map work with a mysql backend? postscreen needs very low latency (I put in explicit tests for this). Also, postscreen requires read, write, iterate support which is implemented only for file-based databases. If table access requires 10ms, then postscreen can handle only 100 connection requests per second. You would be better off not using postscreen and instead turning up the number of smtpd processes. Wietse
From: Nataraj on 27 May 2010 15:18 Andy Dills wrote: > I've been investigating postscreen, as we've been address probed/bombed > for years, as we have a few domains that are very old (well, early 90s) > that had a lot of users back in the dialup days. Our approach was to just > throw hardware at the problem, and we've had a whole cluster of servers > just sending out 550s all day long for years now. > > We don't do any RBL checks at the postfix level; we have amavisd-new > handle all of that via spamassassin. I'm hesitant to allow a single > blacklist to determine the fate of mail acceptance, especially when we > have a very low false negative rate with amavisd/SA. Essentially, we'd > rather throw hardware at the problem than potentially reject legit mail. > > My primary question is, would we see significant improvement by using > postscreen if we don't use RBLs? > > Also, would postscreen_cache_map work with a mysql backend? > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- > Using things like amavisd and spamassasin besides being very costly in terms of performance, is far more vulnerable to security exploits than rejecting as many connections as possible at an earlier time. I have used the various checks for valid domain names, helo names, etc, in conjunction with the RBL's to minimize scanning with spamassasin. I use restriction classes to define more and less conservative policys for different domains and even specific users when necessary. smtpd_restriction_classes = restrictive, permissive restrictive = reject_rbl_client zen.spamhaus.org reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net permissive = reject_rbl_client pbl.spamhaus.org reject_rbl_client dul.dnsbl.sorbs.net check_recipient_access hash:/etc/postfix/smtpd_recipient_access smtpd_recipient_access contains: mydomain.com restrictive # I get the abuse mail and don't want to see alot of spam abuse(a)otherdomain.com restrictive otherdomain.org permissive 127.0.0.1 OK The permissive class is very conservative and should cause practically no false positives. Even my restrictive class includes rbls known to have extremely low false positive rates. Spamhaus is known to be one of the most accurate rbl's with an excellent hit rate and low false positives. If you have a large site, check their web pages, since they do charge for high volume query rates and will block your access if you exceed the free limit. Nataraj
From: LuKreme on 27 May 2010 15:45 On 27-May-2010, at 07:34, Andy Dills wrote: > > I've been investigating postscreen, as we've been address probed/bombed > for years, as we have a few domains that are very old (well, early 90s) > that had a lot of users back in the dialup days. Our approach was to just > throw hardware at the problem, and we've had a whole cluster of servers > just sending out 550s all day long for years now. > > We don't do any RBL checks at the postfix level; That's just silly > we have amavisd-new > handle all of that via spamassassin. I'm hesitant to allow a single > blacklist to determine the fate of mail acceptance, especially when we > have a very low false negative rate with amavisd/SA. Essentially, we'd > rather throw hardware at the problem than potentially reject legit mail. Really? How much legit mail hits zen's rbl (hint, the number rhymes with "hero"). -- 'You don't think you've had enough, do you?' he said. I KNOW WHEN I'VE HAD ENOUGH. 'Everyone says that, though. I KNOW WHEN EVERYONE'S HAD ENOUGH. --Moving Pictures
|
Next
|
Last
Pages: 1 2 3 Prev: illegal address syntax Next: recipient_delimiter and check_recipient_access |