Dealing with unreliable milters - revisited

5 msg	Loops back to myself
2 msg	Postfix, MySQL
6 msg	Trouble with MYSQL Query on SASL
3 msg	Inbound/OutBound Relay
10 msg	is hotmail blocking mail or does 'soft fail' me...
20 msg	Incorrect domainname
8 msg	Resolve some addresses and relay some addresses...
11 msg	setup postfix whitout mynetworks, just with per...
5 msg	commands for examining queue?
2 msg	writable proxymap service update
1 msg	Feature: output rate limiting
3 msg	mysql support in Postfix
14 msg	Installation Questions
6 msg	Re: smtpd_proxy_filter by size
3 msg	implementing pyspf
2 msg	Confused about hostnames & domainnames
5 msg	Too much logging information to mail.debug

Dealing with unreliable milters - revisited
\ Mark Martinec (30 Nov 2007)
. \ Victor Duchovni (30 Nov 2007)
. \ (Wietse Venema) (30 Nov 2007)
. . \ Mark Martinec (2 Dec 2007)

13 msg	ddos
75 msg	SMTP-SASL auth failure caching.

Subject:	Dealing with unreliable milters - revisited
Group:	Postfix-users
From:	Mark Martinec
Date:	30 Nov 2007

If you remember a topic I started at the beginning of September (2007),
just to refresh memories:

myself:
> Read the following as a suggestion or a feature request.
> Every now and then some new kind of bugs in milters pop up,
> causing them to misbehave or just crash. Luckily the setting:
> milter_default_action = accept
> deals with milter process crashes, and lets mail flow on
> without them, which is what I want.
> Unfortunately, only partly failing milters can still block
> mail by resulting in temporary failures.
[...]
> It would be nice if there were some way to let Postfix
> deal with such problems the same way as with crashed milters.
> Either letting milter_default_action=accept ignore temporary
> failures, or by introducing some stronger setting.

Wietse:
> Do you want to ignore SMFIR_TEMPFAIL results?

myself:
> Yes, that would be my desire, having a possibility to configure
> Postfix to just ignore SMFIR_TEMPFAIL and behave as if a
> milter were unavailable.

Viktor:
> Is it correct for the milter to tempfail in this case? Should it not
> in the worst case just fail to verify the signature?

myself:
> Wishful thinking...

Wietse:
> Perhaps the following text in dkim-filter.conf(5) helps:
> On-InternalError (string)
> On-BadSignature (string)

myself:
> Yes, this helps with this particular milter, adding a command line
> option '-C int=a' allows mail to pass. Thanks!

Jose-Marcio:
> The MTA shouldn't implement workarounds to handle unreliable
> milter answers (other than low level or protocol errors).

myself:
> Perhaps. Problems in milters undoubtedly need to be fixed eventually,
> but allowing to tell MTA to ignore such errors could make life
> easier to a mailing system administrator when he has to deal with
> less-then-perfect external software. But I can live with it,
> one way or another.

Well, I came across another case of a similar kind, with the same
milter (dkim in verifying mode, NOT configured to reject a message
or tempfail on errors (-C dns=a,int=a) but let's stick to the MTA-side
of the story here).

This time it decided to reject a message. Admittedly the message is
a degenerate, with lots of addresses in a long header, but Postfix
by itself can deal with it and deliver it just fine. This is what
happens:

dkim-filter[8423]: too much header data; rejecting
postfix/cleanup[26509]: E938439DCBB: milter-reject:
END-OF-MESSAGE from xxx[dd.dd.dd.dd]:
5.7.1 Command rejected; from=<xxx>
to=<xxx> proto=ESMTP helo=<xxx.ijs.si>

I would like to request a Postfix configuration setting
which could override any attempts of some milter
to reject or tempfail a message. It is unrealistic to
expect milters to match the reliability standards of Posfix.

Btw, the next version of amavisd-new is coming with its
own direct support for DKIM signing and verification
(using a Mail::DKIM module, thanks to Jason Long).
It was fun to play with milters, they've accomplished
their job, now it's time to get rid of them :)

Mark