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: 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: 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*
