On Sun, Aug 27, 2023 at 01:41:19PM -0600, Pete Holzmann wrote:
> Ummm... Viktor, how many people do *you* think have read the fine
> documentation on every verification option they use in their main.cf
> restriction configurations?
I don't know. What I do know is that using features whose documentation
has not been read is liable to lead to naïvely surprising behaviour. :-(
> Beyond that, from experience this statement is false:
>
> >As documented, but there should also be a background refresh every 3
> >hours, so that the second try 3h after correcting the problem, will
> >succeed:
>
> > address_verify_negative_expire_time = 3d
> > address_verify_negative_refresh_time = 3h
> > address_verify_positive_expire_time = 31d
> > address_verify_positive_refresh_time = 7d
If the aliases(5) table has actually been rebuilt, and the message
is now deliverable, the background refresh is supposed to happen:
address_verify_negative_refresh_time (default: 3h)
The time after which a failed address verification probe needs to be
refreshed.
Specify a non-zero time value (an integral value plus an optional
one-letter suffix that specifies the time unit). Time units: s
(seconds), m (minutes), h (hours), d (days), w (weeks). The default
time unit is h (hours).
This feature is available in Postfix 2.1 and later.
https://github.com/vdukhovni/postfix/blob/v3.8.1/postfix/src/verify/verify.c#L512-L550
If you have detailed log evidence of refresh probes not happening,
please share.
> I have 100% default values. Ten hours after correcting the problem,
> it still failed. Perhaps a bug?
During those 10 hours, how many deliveries were attempted to the
problem address after the source table was updated and the indexed
"database" file rebuilt. The "refresh" probes only run in response
to delivery attempts, in the background, after returning a cached
response to the SMTP client.
> >Only if you haven't read the documentation.
>
> Whether or not the fine documentation has been read, no information
> in the log, even at log-level 10, points to the verification cache.
Well, "log level 10" (whatever that means) is a good way of not seeing
the forest for the trees. At most one "-v" is generally all that one
might temporarily enable to get more insight into the details of message
processing. In this case for the smtpd(8) and/or verify(8) services.
> >No, newaliases have nothing to do with this. This is entirely material
> >for ADDRESS_VERIFICATION_README and verify(8), but perhaps the timer
> >parameters could be also mentioned prominently in the README file.
>
> Why would it not make sense for newaliases to trigger a refresh?
> Clearly, newaliases implies that aliases have been changed, so it is
> quite possible that prior failures are now successes. ;)
Because there are over 1000 tunable parameters, with many of them
potentially affecting the deliverability of messages to a recipient.
There nothing particularly remarkable about the content of aliases(5).
The behaviour of recipient verification is documented in verify(8) and
ADDRESS_VERIFICATION_README, with per-parameter details in postconf(5).
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
