Is there something like check_recipient_access for postscreen?
Hello List Since a few weeks i am using postscreen on our mailservers. I really like the postscreen_dnsbl_* settings as in july they blocked 75% of spammers. But now i have a user which fears, that the blacklists could also block legitim clients because of false positives. So he wants us to let trough all mails with a RCPT TO: set to his address. He is aware, that he will then get a lot of spam. But he does not care about that. In the former setup - without postscreen - i would just have added a check_recipient_access before the reject_rbl_client which says something like user@domain OK As far as i have seen this is not possible when using postscreen. The only solution i could think of is setting postscreen_dnsbl_sites = and postscreen_dnsbl_action = ignore and then using reject_rbl_client. But then i would loose the abilty of having one process blocking the big masses instead of using a lot of smtpd processes. So my question is: Am i right or am i doing some reasoning error? And a little question to Wietse: Would it make sense to also have settings like the check_recipient_* and check_sender_* for postscreen? Thank you for your time and best regards Matthew -- Matthias Egger ETH Zurich Department of Information Technology maeg...@ee.ethz.ch and Electrical Engineering IT Support Group (ISG.EE), ETL/F/24.1 Phone +41 (0)44 632 03 90 Physikstrasse 3, CH-8092 Zurich Fax +41 (0)44 632 11 95
Re: Is there something like check_recipient_access for postscreen?
On Tue, Aug 23, 2011 at 12:25:29PM +0200, Matthias Egger wrote: But now i have a user which fears, that the blacklists could also block legitim clients because of false positives. So he wants us to let trough all mails with a RCPT TO: set to his address. He is aware, that he will then get a lot of spam. But he does not care about that. Sorry, postscreen is for keeping away zombies, and has no per-user policy. Apply only conservative tests and convince your user or his management that this is safe enough. -- Viktor.