bypass amavisd after OK from policy daemon?

[/dev/rob0]

On Tue, Aug 06, 2013 at 10:58:21AM +0200, Franz Schwartau wrote:
> On Tue, Aug 06, 2013 at 08:37:09AM +0200, Patrick Ben Koetter wrote:
> > * Franz Schwartau <franz at electromail.org>:
> > > On 05.08.2013 18:31, Noel Jones wrote:
> > > > On 8/5/2013 10:42 AM, Franz Schwartau wrote:
> > > >>
> > > >> I configured postfix to use amavisd as a SMTP proxy 
> > > >> (smtpd_proxy_filter). Now I'd like to skip amavisd if a 
> > > >> policy daemon called in smtpd_recipient_restrictions returns 
> > > >> OK.
> > > >>
> > > >> Has anyone any idea how to accomplish this?
> > > >>
> > > >> As far as I unterstood postfix' restrictions there is no 
> > > >> "final" OK skipping any further checks.
> > > > 
> > > > The insurmountable problem is that amavisd is called before
> > > > the policy server is ever run.

^^ note again

> > > > Any bypass will need to be in amavisd itself.
> > > > 
> > > > The built-in bypass mechanisms in amavisd-new are the various 
> > > > bypass* and *lovers parameters. If they can't do what you 
> > > > want, custom code will be needed.
> > > 
> > > I'm aware of the fact that amavisd is run before the policy 
> > > daemon if configured as a smtpd_proxy_filter. This is why I 
> > > asked "Is there any way to flag anything so amavisd skips it's 
> > > checks?"
> > > 
> > > The only way I found so far is to set an extra header in 
> > > postfix via PREPEND. This extra header can be evaluted by 
> > > spamassassin setting a very low score. Unfortunatly this 
> > > doesn't cover virus or bad header checks.
> > > 
> > > amavisd's bypass and lovers maps are for recipients, only.
> > > 
> > > Any idea how amavisd can be configured to skip checks if an 
> > > extra header is set?
> > 
> > Not unless you add (read: program) a custom class.
> > 
> > What problem do you need to solve? Maybe we can use a
> > different approach.
> 
> Basically I'd like to skip any further checks based on a result
> of a policy daemon.

Yes, but again, that can't work because amavisd sees the mail before 
the policy daemon is consulted. You're going to have to incorporate 
your policy daemon logic within amavisd-new.

> I use smtpd_recipient_restrictions to ask a policy server using 
> check_policy_service. This policy server implements black- and 
> whitelisting in dependency of the recipient domain. The parameters 
> for black- or whitelisting are stored in a SQL database. The 
> parameters can be of all types (client name, client address, hello 
> parameter, sender, recipient). If some parameter is whitelisted 
> amavisd shouldn't perform any checks.

I'm wondering why this is a problem? If you don't have enough CPU 
power (and fast I/O) for smtpd_proxy_filter, switch to after-queue 
filtering.

Spammers can and do submit spam using compromised credentials. 
Content filtering is an important defense (the *best* actually) 
against such abuse.

> BTW. I know SMTP is a multi recipient protocol. Black- and 
> whitelisting can be complicated. But please don't let us discuss
> it here. Maybe I have to use another call to a policy daemon in 
> smtpd_data_restrictions to solve multiple recipient problems.

No number of policy daemons which run after the filter will be able 
to influence the filter.

> So I'm looking for a possibility to skip checks within amavisd 
> based on some critera, e. g. special header is present, external 
> file based on queue id is present.

If your policy daemon adds the header, again, amavisd sees the mail 
first, so your header does not exist. Your only answer is to build 
your policy decision into amavisd-new.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: