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=<nag...@franz.com> to=<sa-nag...@franz.com> > > > > 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.
