On Tue, Jun 2, 2015 at 1:30 PM, francis picabia <fpica...@gmail.com> wrote: > 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
Thinking about this more, I don't think an access file is the place for content filter. It has to leave the stream and come back into the queue again. I can see how to do different kinds of filtering in amavis based on the client IP, but I'd rather it did not pass to amavis at all. I don't see how to do this purely in postfix without something like a dedicated IP or port the remote party uses for sending us email.
