postscreen questions
in [Postfix]
|
From: Andy Dills on 28 May 2010 06:45 On Thu, 27 May 2010, Wietse Venema wrote: > 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. That seems worth investigating, thank you. I appreciate how you're evolving postfix to address this (and the improvements to handle content filtering pre-queue, we will be moving to that once amavisd-new is more mature with regards to that). > > 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. That makes sense. I was just looking for a way to provide some "shared knowledge" among the servers in the cluster. Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
From: lst_hoe02 on 28 May 2010 08:13 Zitat von LuKreme <kremels(a)kreme.com>: > 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"). Hm. The infamous dispute with the austrian NIC comes to mind... We have throw out all spamhaus.org related blacklists since then. Regards Andreas
From: "Roderick A. Anderson" on 28 May 2010 13:52 Andy Dills wrote: > On Thu, 27 May 2010, Wietse Venema wrote: > >> 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. > > That seems worth investigating, thank you. I appreciate how you're > evolving postfix to address this (and the improvements to handle content > filtering pre-queue, we will be moving to that once amavisd-new is more > mature with regards to that). > >>> 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. > > That makes sense. I was just looking for a way to provide some "shared > knowledge" among the servers in the cluster. Run a cron job that checks for changes in the RDBMS and then rebuilds the postscreen_cache_map "files" if needed. \\||/ Rod -- > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > ---
From: Wietse Venema on 28 May 2010 14:22 Roderick A. Anderson: > >>> 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. > > > > That makes sense. I was just looking for a way to provide some "shared > > knowledge" among the servers in the cluster. > > Run a cron job that checks for changes in the RDBMS and then rebuilds > the postscreen_cache_map "files" if needed. That implies shared access to the postscreen_cache_map _file_, and is not supported. Wietse
From: Robert Schetterer on 28 May 2010 14:43 Am 28.05.2010 14:13, schrieb lst_hoe02(a)kwsoft.de: > Zitat von LuKreme <kremels(a)kreme.com>: > >> 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"). > > Hm. The infamous dispute with the austrian NIC comes to mind... > We have throw out all spamhaus.org related blacklists since then. > > Regards whatever if you do selective rbl checks, you will nearly never get into trouble, after all there is a lot checks which you can do before rbls so not much leaves to spamhouse, not using them in any way is not really clever, if you like a rbl advanced configurable modus try policy-weight which you can also use selective and/or with whitelisting etc by the way its up to what your using, but i would miss rbls in my antispam chain > > Andreas > > > -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: illegal address syntax Next: recipient_delimiter and check_recipient_access |