milter_default_action=accept not honored

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

milter_default_action=accept not honored

Jeremiah Rothschild
Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
configured with an OpenDKIM milter like so, which works fine under normal
circumstances:

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

However, when file permissions on the OpenDKIM key pair are wrong, resulting
in a failed signing, this happens and the message goes back into the queue:

Nov 14 00:00:27 food opendkim[2135]: can't load key from /etc/opendkim/keys/private: Permission denied
Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=<[hidden email]> to=<[hidden email]>

This looks like a "tempfail" action to me. Why isn't "accept" being honored?

Thanks in advance!

j
Reply | Threaded
Open this post in threaded view
|

Re: milter_default_action=accept not honored

Viktor Dukhovni
On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote:

> Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
> configured with an OpenDKIM milter like so, which works fine under normal
> circumstances:
>
> smtpd_milters = inet:127.0.0.1:8891
> non_smtpd_milters = $smtpd_milters
> milter_default_action = accept

The documentation says:

    milter_default_action (default: tempfail)

        The default action when a Milter (mail filter) application is unavailable or mis-configured.

and so not when the milter is "working", but returning 4XX
verdicts (are those a problem with the milter, or the milter
e.g. graylisting messages, ...?).

> However, when file permissions on the OpenDKIM key pair are wrong, resulting
> in a failed signing, this happens and the message goes back into the queue:
>
> Nov 14 00:00:27 food opendkim[2135]: can't load key from /etc/opendkim/keys/private: Permission denied
> Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=<[hidden email]> to=<[hidden email]>
>
> This looks like a "tempfail" action to me. Why isn't "accept" being honored?

It seems the tempfail is from the milter, not from Postfix.  Postfix
is not in a position to know that the milter is not working as it
should, the milter is responding "normally".

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: milter_default_action=accept not honored

Jeremiah Rothschild
On Tue, Nov 19, 2019 at 02:28:34PM -0500, Viktor Dukhovni wrote:

> On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote:
>
> > Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
> > configured with an OpenDKIM milter like so, which works fine under normal
> > circumstances:
> >
> > smtpd_milters = inet:127.0.0.1:8891
> > non_smtpd_milters = $smtpd_milters
> > milter_default_action = accept
>
> The documentation says:
>
>     milter_default_action (default: tempfail)
>
>         The default action when a Milter (mail filter) application is unavailable or mis-configured.
>
> and so not when the milter is "working", but returning 4XX
> verdicts (are those a problem with the milter, or the milter
> e.g. graylisting messages, ...?).

Ah, I see. I interpreted that differently. Thanks for clarifying.

> > However, when file permissions on the OpenDKIM key pair are wrong, resulting
> > in a failed signing, this happens and the message goes back into the queue:
> >
> > Nov 14 00:00:27 food opendkim[2135]: can't load key from /etc/opendkim/keys/private: Permission denied
> > Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=<[hidden email]> to=<[hidden email]>
> >
> > This looks like a "tempfail" action to me. Why isn't "accept" being honored?
>
> It seems the tempfail is from the milter, not from Postfix.  Postfix
> is not in a position to know that the milter is not working as it
> should, the milter is responding "normally".

That's too bad. I'm surely oversimplifying things but I figured the milter
would do something like pass a non-zero exit along, which postfix could then
use to make a decision on the status.

Sounds like I'll have to come up with a different solution.

Thanks for the help, Viktor, truly appreciated!

> --
>     Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: milter_default_action=accept not honored

Viktor Dukhovni
On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote:

> > It seems the tempfail is from the milter, not from Postfix.  Postfix
> > is not in a position to know that the milter is not working as it
> > should, the milter is responding "normally".
>
> That's too bad. I'm surely oversimplifying things but I figured the milter
> would do something like pass a non-zero exit along, which postfix could then
> use to make a decision on the status.

Postfix isn't executing the milter as a subprocess, they communicate over a
socket.  If the milter returns a 4XX verdict, that's normal milter behaviour.
If the milter drops the connection, times out, ... that's a milter failure,
and *then* the Postfix milter_default_action kicks in.

Your best bet is to invest effort in keeping your milter working properly,
optimizing what happens when it is not working is likely the lesser option.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: milter_default_action=accept not honored

Tom Hendrikx
Hi,

In http://opendkim.org/opendkim.conf.5.html there are several error
conditions defined, with the default actions for them, for instance
"On-SignatureError", "On-KeyNotFound". Ar least some conditions default
to tempfail. Configure the milter correctly and you should be fine.

Kind regards,
        Tom

On 19-11-19 20:45, Viktor Dukhovni wrote:

> On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote:
>
>>> It seems the tempfail is from the milter, not from Postfix.  Postfix
>>> is not in a position to know that the milter is not working as it
>>> should, the milter is responding "normally".
>>
>> That's too bad. I'm surely oversimplifying things but I figured the milter
>> would do something like pass a non-zero exit along, which postfix could then
>> use to make a decision on the status.
>
> Postfix isn't executing the milter as a subprocess, they communicate over a
> socket.  If the milter returns a 4XX verdict, that's normal milter behaviour.
> If the milter drops the connection, times out, ... that's a milter failure,
> and *then* the Postfix milter_default_action kicks in.
>
> Your best bet is to invest effort in keeping your milter working properly,
> optimizing what happens when it is not working is likely the lesser option.
>
Reply | Threaded
Open this post in threaded view
|

RE: milter_default_action=accept not honored

MICHEL, SEBASTIEN
In reply to this post by Viktor Dukhovni
>> > It seems the tempfail is from the milter, not from Postfix.  Postfix
>> > is not in a position to know that the milter is not working as it
>> > should, the milter is responding "normally".
>>
>> That's too bad. I'm surely oversimplifying things but I figured the milter
>> would do something like pass a non-zero exit along, which postfix could then
>> use to make a decision on the status.
>
> Postfix isn't executing the milter as a subprocess, they communicate over a
> socket.  If the milter returns a 4XX verdict, that's normal milter behaviour.
> If the milter drops the connection, times out, ... that's a milter failure,
> and *then* the Postfix milter_default_action kicks in.

I guess there is a missing feature to configure milter in test mode.
In smtpd_xxx_restrictions if you use external policy daemon you can configure warn_if_reject,check_policy_service unix:private/policy, the same for proxy filtering with  warn_if_reject, smtpd_proxy_filter=127.0.0.1:21111. I don't have seen similar feature for milter protocol

Regards,
S├ębastien
Worldline is a registered trade mark and trading name owned by Worldline through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Worldline therefore can accept no liability for any errors or their content. Although Worldline endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Worldline by email.
Reply | Threaded
Open this post in threaded view
|

Re: milter_default_action=accept not honored

Wietse Venema
MICHEL, SEBASTIEN:

> >> > It seems the tempfail is from the milter, not from Postfix.  Postfix
> >> > is not in a position to know that the milter is not working as it
> >> > should, the milter is responding "normally".
> >>
> >> That's too bad. I'm surely oversimplifying things but I figured the milter
> >> would do something like pass a non-zero exit along, which postfix could then
> >> use to make a decision on the status.
> >
> > Postfix isn't executing the milter as a subprocess, they communicate over a
> > socket.  If the milter returns a 4XX verdict, that's normal milter behaviour.
> > If the milter drops the connection, times out, ... that's a milter failure,
> > and *then* the Postfix milter_default_action kicks in.
>
> I guess there is a missing feature to configure milter in test mode.

You could temporarily add '-o soft_bounce=yes' in master.cf.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: milter_default_action=accept not honored

MICHEL, SEBASTIEN

>> I guess there is a missing feature to configure milter in test mode.
>
> You could temporarily add '-o soft_bounce=yes' in master.cf.

Good point. It has not the same behavior than warn_if_reject but it is also useful. thanks
Worldline is a registered trade mark and trading name owned by Worldline through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Worldline therefore can accept no liability for any errors or their content. Although Worldline endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Worldline by email.