Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
On 28. jan. 2015 23.33.45 lst_ho...@kwsoft.de wrote: block spam with Spamassassin block viruses with ClamAV greylist mail from freemail domains with one policy greylist mail from certain countries with another policy Don't do this. Greylisting should not be used to punish real MTAs. Use Greylisting with automatic whitelist so only the Spam-Bots get cut away and let already know MTAs pass by. Works exceptionally well here, the Bots go away after 2-3 tries and 90% of the sending MTAs are on the whitelist after some time. mtpolicyd can call greylist when ip is on dnsbl or simply not on dnswl, ips that is on dnswl will not be greylisted so, readding docs in mtpolicyd seems to show it can self do the greylist part, but i have not yet seem it works, but it can use another policy server called from mtpolicyd else try sqlgrey where its possible to have more fine grayned configs pr ip / hostname / what ever :)
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Zitat von srach hndls...@tutanota.de: I have read the documents for some different Greylisting opportunities for Postfix This built into Postfix http://www.postfix.org/SMTPD_POLICY_README.html#greylist and popular ones http://wiki.policyd.org http://postgrey.schweikert.ch I am not finding a modern comparison of these and a decision point for choosing one to use best in the latest Postfix versions. Many online postings have a comment but they are most for older versions of Postfix. I wonder if Postfix with modern versions is integrating better ideas and to do it all in one? I think maybe that the choice is not just the recommended built in one of Postifx? It depends on the goals? My interested goals are to block spam with Spamassassin block viruses with ClamAV greylist mail from freemail domains with one policy greylist mail from certain countries with another policy Don't do this. Greylisting should not be used to punish real MTAs. Use Greylisting with automatic whitelist so only the Spam-Bots get cut away and let already know MTAs pass by. Works exceptionally well here, the Bots go away after 2-3 tries and 90% of the sending MTAs are on the whitelist after some time. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
I have read the documents for some different Greylisting opportunities for Postfix This built into Postfix http://www.postfix.org/SMTPD_POLICY_README.html#greylist and popular ones http://wiki.policyd.org http://postgrey.schweikert.ch I am not finding a modern comparison of these and a decision point for choosing one to use best in the latest Postfix versions. Many online postings have a comment but they are most for older versions of Postfix. I wonder if Postfix with modern versions is integrating better ideas and to do it all in one? I think maybe that the choice is not just the recommended built in one of Postifx? It depends on the goals? My interested goals are to block spam with Spamassassin block viruses with ClamAV greylist mail from freemail domains with one policy greylist mail from certain countries with another policy not use Amavis, it is too confusing for me My use will be usually less than 1 mails per day. What do the experts here do for these policies when all together? There are many choices I know, with so much information. It is like drinking from a firehose ! I enjoy though the option to learn and build each piece - it is a better road to sucess. Thanks for your good advice and experience! *S*
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 19:38 schrieb srach: I have read the documents for some different Greylisting opportunities for Postfix This built into Postfix http://www.postfix.org/SMTPD_POLICY_README.html#greylist and popular ones http://wiki.policyd.org http://postgrey.schweikert.ch I am not finding a modern comparison of these and a decision point for choosing one to use best in the latest Postfix versions. Many online postings have a comment but they are most for older versions of Postfix. I wonder if Postfix with modern versions is integrating better ideas and to do it all in one? I think maybe that the choice is not just the recommended built in one of Postifx? It depends on the goals? besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests postscreen_greet_action = enforce postscreen_bare_newline_enable = no postscreen_bare_newline_action = enforce postscreen_pipelining_enable = no postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_action = enforce
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:21 schrieb srach: 28. Jan 2015 19:17 by wie...@porcupine.org mailto:wie...@porcupine.org: There are good reasons to NOT integrate, and instead use the least-expensive solution before the most-expensive solution. postscreen implements a least-expensive solution that eliminates most of the spambots without even allowing them to talk to a Postfix SMTP server process. Spamassassin and Clamav are most-expensive solutions that should be used only for mail that cannot be stopped via other means. Okay I see that. Don not spend your money unless you have to! So if that is done using Postscreen for some greylisting what option in Postscreen for only greylisting with the depp protocl tests for some domains is there? I am looking but still see no maps for it *none* - read my previous mail and look how most junk is killed long, long, long before any chance to deliver and so you have *no reason* for do yourself the burden of slow down legit delivery for no benefit
Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
28. Jan 2015 18:43 by li...@rhsoft.net: besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests Yes I see that opportunity in Postscreen. I do understand the warning for the large clusters. Then I have to be careful for choosing domains I know. For some I care , but for some I do not. But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. I think that is making some sense? *S*
Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
srach: And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. There are good reasons to NOT integrate, and instead use the least-expensive solution before the most-expensive solution. postscreen implements a least-expensive solution that eliminates most of the spambots without even allowing them to talk to a Postfix SMTP server process. Spamassassin and Clamav are most-expensive solutions that should be used only for mail that cannot be stopped via other means. Wietse
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:08 schrieb srach: 28. Jan 2015 18:43 by li...@rhsoft.net mailto:li...@rhsoft.net: besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests Yes I see that opportunity in Postscreen. I do understand the warning for the large clusters. Then I have to be careful for choosing domains I know. For some I care , but for some I do not. honestly with postscreen *without deep protocol tests) and rbl-scoring (DSNBL as well as DNSWL) there is no point for greylisting at all postscreen_dnsbl_ttl = 5m postscreen_dnsbl_threshold = 8 postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.4*1 hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.[18;19;20]*-2 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 hostkarma.junkemailfilter.com=127.0.0.1*-2 _ if you additionally configure a honeypot-backup-MX always responding with 450 if not already blacklisted around 50% of all bots will try the backup MX and never come back to the primary and they ones coming back are waiting some minutes by assuming greylisting and in the meantime many are on RBL's which where not at the first contact postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? it can't by design, if it would have such capapbilities it would no longer be a lightweight daemon in front of spmtpd And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. I think that is making some sense? that makes *zero* sense postscreen kills 90% of all junk long before it connects to a expensive smtpd at all, independent of contentfilters that's much more value then pass every connection to limited smtpd and to harm with misconcepts like greylisting
Re: Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
28. Jan 2015 19:17 by wie...@porcupine.org: There are good reasons to NOT integrate, and instead use the least-expensive solution before the most-expensive solution. postscreen implements a least-expensive solution that eliminates most of the spambots without even allowing them to talk to a Postfix SMTP server process. Spamassassin and Clamav are most-expensive solutions that should be used only for mail that cannot be stopped via other means. Okay I see that. Don not spend your money unless you have to! So if that is done using Postscreen for some greylisting what option in Postscreen for only greylisting with the depp protocl tests for some domains is there? I am looking but still see no maps for it. *S*
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
maybe you need some numbers why the below config is good and greylisting not needed peak day 2015/01 * postscreen rejects: 9 * spamassassin: 120 * clamav: 15 * delivered mail: 850 that are numbers for a single day Am 28.01.2015 um 20:19 schrieb li...@rhsoft.net: Am 28.01.2015 um 20:08 schrieb srach: 28. Jan 2015 18:43 by li...@rhsoft.net mailto:li...@rhsoft.net: besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests Yes I see that opportunity in Postscreen. I do understand the warning for the large clusters. Then I have to be careful for choosing domains I know. For some I care , but for some I do not. honestly with postscreen *without deep protocol tests) and rbl-scoring (DSNBL as well as DNSWL) there is no point for greylisting at all postscreen_dnsbl_ttl = 5m postscreen_dnsbl_threshold = 8 postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.4*1 hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.[18;19;20]*-2 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 hostkarma.junkemailfilter.com=127.0.0.1*-2 _ if you additionally configure a honeypot-backup-MX always responding with 450 if not already blacklisted around 50% of all bots will try the backup MX and never come back to the primary and they ones coming back are waiting some minutes by assuming greylisting and in the meantime many are on RBL's which where not at the first contact postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? it can't by design, if it would have such capapbilities it would no longer be a lightweight daemon in front of spmtpd And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. I think that is making some sense? that makes *zero* sense postscreen kills 90% of all junk long before it connects to a expensive smtpd at all, independent of contentfilters that's much more value then pass every connection to limited smtpd and to harm with misconcepts like greylisting
Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
28. Jan 2015 19:19 by li...@rhsoft.net: honestly with postscreen *without deep protocol tests) and rbl-scoring (DSNBL as well as DNSWL) there is no point for greylisting at all postscreen_dnsbl_ttl = 5m postscreen_dnsbl_threshold = 8 postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = http://b.barracudacentral.org=127.0.0.2*7 That is a good idea approach! I did not know that so far. if you additionally configure a honeypot-backup-MX always responding with 450 if not already blacklisted around 50% of all bots will try the backup MX and never come back to the primary and they ones coming back are waiting some minutes by assuming greylisting and in the meantime many are on RBL's which where not at the first contact postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all Yes this I did to the 2nd MX IP I have But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? it can't by design, if it would have such capapbilities it would no longer be a lightweight daemon in front of spmtpd I think then the fear I am having for too much loss for some greylisting means that I will not use the greylisting in Postscreen. So turning off the deep protocol testing. postscreen kills 90% of all junk long before it connects to a expensive smtpd at all, independent of contentfilters that's much more value then pass every connection to limited smtpd and to harm with misconcepts like greylisting I think that is the same idea that Wietse said to me. Okay, some good ideas! *S*
Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
28. Jan 2015 19:28 by li...@rhsoft.net: maybe you need some numbers why the below config is good and greylisting not needed peak day 2015/01 * postscreen rejects: 9 * spamassassin: 120 * clamav: 15 * delivered mail: 850 that are numbers for a single day Okay that is very good! Numbers are good to see. And they make a clear story. Wow that is really good percents. So I think I leave alone the greylisting idea and the deep protocol tests. For the later steps of both Spamassassin CLamav, to keep them less expensive too what recomends are there? Still the policyd or the spamc? I am starting to read the documents for these now with new eyes, not wanting the greylisting integrated or not. I am arriving to a good solution with these ideas. Asking with getting good answers here changes it for the better. I am seeing the documents are like a fat Oxford Dictionary. Many many words with official particular definitions. They are like a book for childs too, that it tells some very simple stories. But to write stories richly someday like Mr. Shakespeare we must have advise from old authors writing some bad books already in the past! :-)
Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
28. Jan 2015 19:19 by li...@rhsoft.net: postscreen_dnsbl_sites = http://b.barracudacentral.org=127.0.0.2*7 http://dnsbl.inps.de=127.0.0.2*7 I see from the example you give that these are I think all DNSBL that are domain name searching only In the notes I am keeping from reading I see also a saying of good value for reject_rhsbl_client http://dbl.spamhaus.org reject_rhsbl_reverse_client http://dbl.spamhaus.org reject_rhsbl_sender http://dbl.spamhaus.org How is it to add these to the Postscreen not expensive checking too? I do not read in the Postsreen documents any regards rhsbl *S*
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:46 schrieb srach: 28. Jan 2015 19:28 by li...@rhsoft.net mailto:li...@rhsoft.net: maybe you need some numbers why the below config is good and greylisting not needed peak day 2015/01 * postscreen rejects: 9 * spamassassin: 120 * clamav: 15 * delivered mail: 850 that are numbers for a single day Okay that is very good! Numbers are good to see. And they make a clear story. Wow that is really good percents. see attached mailgraph So I think I leave alone the greylisting idea and the deep protocol tests. For the later steps of both Spamassassin CLamav, to keep them less expensive too what recomends are there? Still the policyd or the spamc? I am starting to read the documents for these now with new eyes, not wanting the greylisting integrated or not. * spamass-milter with spamd * clamav-milter both are acting before-queue what's no problem given only a small amount of mail make it there and the benefits are that you can tag from let say 5.0 to 7.9 points and reject = 8.0 http://www.postfix.org/MILTER_README.html having that setup since august 2014 for 1200 users replacing the previous Barracuda Networks appliance and the results are great, the server load is zero, it's running stable and no complaints well, there are HELO/PTR-filters and python-spf-policyd in front of the milters too - if would have imagined how well that all works at the end (after a lot of hours for tuning and config) i would own that setup for years now instead a few months I am arriving to a good solution with these ideas. Asking with getting good answers here changes it for the better. I am seeing the documents are like a fat Oxford Dictionary. Many many words with official particular definitions. They are like a book for childs too, that it tells some very simple stories. But to write stories richly someday like Mr. Shakespeare we must have advise from old authors writing some bad books already in the past! :-)
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 21:00 schrieb srach: 28. Jan 2015 19:19 by li...@rhsoft.net mailto:li...@rhsoft.net: postscreen_dnsbl_sites = http://b.barracudacentral.org=127.0.0.2*7 http://dnsbl.inps.de=127.0.0.2*7 I see from the example you give that these are I think all DNSBL that are domain name searching only no - a DNSBL/DNSWL is IP-based In the notes I am keeping from reading I see also a saying of good value for reject_rhsbl_client http://dbl.spamhaus.org reject_rhsbl_reverse_client http://dbl.spamhaus.org reject_rhsbl_sender http://dbl.spamhaus.org spamassassin does URIBL anyways adjust the scores and be happy the point si the score-based result it avoids false positives postfix reject_ is asking for troubles How is it to add these to the Postscreen not expensive checking too? these are not postscreen settings these are smtpd settings for clients passing postscreen I do not read in the Postsreen documents any regards rhsbl because it don't make sense there postscreen is the first and lightweight shield in a concept
