On Tue, Jun 2, 2015 at 12:13 PM, Wietse Venema <wie...@porcupine.org> wrote: > francis picabia: >> A remaining concern is bypassing the content_filter >> >> I've scanned through http://www.postfix.org/FILTER_README.html >> and googled this issue. >> >> I think I'd understand the FILTER documentation better >> with a real example. >> >> Let's say I want everything to go through the content filter unless >> it comes from 1.2.3.4/24 or 5.6.7.8/24 How is that configured? >> I don't understand the documentation. If the access >> table was used, then one uses: >> >> /whatever/ FILTER foo:bar > > If this is an access map, specify DUNNO for those blocks that > should not be filtered.
Does DUNNO skip to the next line in the access file, or the next check in the list under smtpd_client_restrictions? How to send everything else to amavis? Maybe the DUNNO approach doesn't help. Perhaps this is how to accomplish the goal in a (new?) access file: 1.2.3 OK 5.6.7 OK /./ lmtp-amavis [127.0.0.1]:10024 I'm not confident in the syntax for the left column. An existing access file has been used to whitelist IPs failing reverse DNS check, or block spam outbreaks from IPs. It starts with lines like: 213.39.74.39 PERMIT and it ends with lines like: 209.143.144.3 550 Rejecting email from this server We have over 1000 entries in access, built up gradually over the years. How is the existing PERMIT and REJECT integrated with the content filter logic? I'd think we need a second access file for this within smtpd_client_restrictions, preceded by "check_client_access" like our existing access file reference. Currently we have: smtpd_client_restrictions = reject_unlisted_recipient, check_client_access cidr:/etc/postfix/client.cidr, check_sender_access hash:/etc/postfix/whitelist, check_recipient_access hash:/etc/postfix/recipient_access, check_client_access hash:/etc/postfix/access, reject_invalid_hostname, reject_unknown_reverse_client_hostname
