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 <[email protected]>:
> > > > 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
