bypass amavisd after OK from policy daemon?

[Franz Schwartau]

On Tue, Aug 06, 2013 at 04:53:27PM -0500, /dev/rob0 wrote:
> 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.

A policy daemon configured in smtpd_recipient_restriction and smtpd_data_restrictions is asked before amavisd scans the DATA block. So in general it would be possible to skip scanning the DATA block within amavisd based on a "flag" the policy daemon called in smtpd_recipient_restriction or smtpd_data_restrictions sets.

What I'm trying to figure out is how to influence amavisd not to scan the DATA block if an arbitrary condition is met.

> > 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.

It's not a problem of resources. I don't wan't to risk a SMTP transaction is rejected via amavisd if a whitelist entry is matched. content_filter isn't an option because of legal issues.

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

Yes, that's right. Although the extra header will never escape outside it's a risk. This is why I'm not happy with this setup. Furthermore the extra header can be evaluated in spamassassin only. Thus I'm not able to skip virus scanning.

> > 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.

Using a content_filter it's right. Using smtpd_proxy_filter it's not.

> > 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.

Proven otherwise by implementation.

> Your only answer is to build 
> your policy decision into amavisd-new.

Yes, but how? This is my question which is still unanswered. How can amavisd be configured to skip certain checks if some generic condition is met.

	Best regards
		Franz