Hi, On Mon, Dec 28, 2015 at 1:48 AM, Patrick Ben Koetter <p...@sys4.de> wrote: > * Alex <mysqlstud...@gmail.com>: >> Hi, >> >> I'm using amavisd-new-2.10.1 and postfix-3.0.3 on fc22. I have a bunch >> of IPs that I need to effectively whitelist to allow all mail to skip >> being processed by amavisd. >> >> I'm trying to understand how to use the %interface_policy capability, >> and whether that's a better option than to just add the IPs to a >> $policy_bank. > > Interface policies are triggered by the interface/port via which mail enters > the amavis framework. This requires logic on the sending side (here: Postfix) > and on the receiving side. The sending side must know to via which interface > it should route messages to amavis. amavis on the receiving side must provide > interfaces and policies as required. > > I suggest you use an approach that requires no logic on the Postfix side. Use > @client_ipaddr_policy in amavis to identify specific IPs/IP ranges and map > them to policies.
That's what I thought, and overnight, I read a ton more docs about interface_policy, and just couldn't get it to work. I'm actually doing it using client_ipaddr_policy with postfix already, but wasn't sure it was the right way for what I was trying to do. When people spoke about bypassing amavisd, I was thinking they were bypassing amavisd altogether, when they were really talking about just the bypass_* options in the policy banks, which is what I was already doing. I realize you can actually bypass amavisd altogether, but it's messy and appears to require an additional IP. > We're using MILTER to connect Postfix and amavis. You are using content_filter > to hand mail over to amavis. You're log line may vary. The approach to use > @client_ipaddr_policy remains the same. Can you explain this further? You're not using something like "content_filter = smtp-amavis:[127.0.0.1]:10024" with postfix? I'm actually thinking of also implementing MIMEdefang, and believe you need to use a MILTER to do that, but wasn't sure how that would be done. Thanks so much for your help, as always. Alex