On Fri, Aug 21, 2020 at 10:32:10AM +0300, Thorsten Habich wrote: > > This is relevant, but probably not 100% accurate, likely some domains > > also intermittently failed routine CAfile-based validation. > > Thanks for the patch. There was no higher number of certificate > verification failures since I updated to Postfix 3.5.4. > > Checking the logs of the last 8 days, there is only one "Server > certificate not trusted" error for a CApath-based configuration and 348 > errors for TAfile based configurations. > The number of *CApath* (if that's relevant) based mandatory TLS > configurations per destination is currently FAR higher than the tafile > based configurations.
This is expected, given that most destinations are not using "tafile", the probability of failing a CApath validation during a concurrent successful "tafile" delivery is low, but not zero. If that one validation failure was transient (the destination otherwise verified before and after) then that could be the one low probability case. > Hope this patch is suitable: > > --- a/src/posttls-finger/posttls-finger.c 2019-02-12 > 14:17:45.000000000 +0100 > +++ b/src/posttls-finger/posttls-finger.c.new 2020-08-21 > 09:15:04.256945675 +0200 > @@ -1988,7 +1988,7 @@ > msg_fatal("bad '-a' option value: %s", state->options.addr_pref); > > #ifdef USE_TLS > - if (state->tlsproxy_mode && state->reconnect) > + if (state->tlsproxy_mode && state->reconnect > 0) > msg_fatal("The -X and -r options are mutually exclusive"); > #endif This has already been fixed in the 3.6 snapshots. Don't recall whether that's been backported to 3.4/3.5. -- Viktor.