On Sun, Aug 22, 2021 at 02:51:02PM -0400, post...@ptld.com wrote:
> So another way to look at it...
>
> address_verify_positive_refresh_time
> Is when the cached data becomes stale and any mail event after
> this time would cause another address query to refresh the cached
>
On 08-22-2021 1:49 pm, Viktor Dukhovni wrote:
Cached data is used until it *expires*. When a cache hit is *found*
it is immediately used to determine the address status. If however,
the refresh timer has expired, a new probe is sent to try to bring
the cache up to date.
The key difference from
On Sun, Aug 22, 2021 at 12:42:26PM -0400, post...@ptld.com wrote:
> With address_verify_*_*_time im not understanding the difference in
> behavior between refresh and expire. The manual says:
Cached data is used until it *expires*. When a cache hit is *found*
it is immediately used to
post...@ptld.com:
> With address_verify_*_*_time im not understanding the difference in
> behavior between refresh and expire. The manual says:
>
> "parameters that control how long address verification results are
> cached before they need to be refreshed, and how long results can remain
>
With address_verify_*_*_time im not understanding the difference in
behavior between refresh and expire. The manual says:
"parameters that control how long address verification results are
cached before they need to be refreshed, and how long results can remain
unrefreshed before they expire"
> Could it be a transient DNS/network problem? If it only
You can check which nameservers are responsible:
1) with dns (/etc/resolv.conf)
[user@server ~]$ dig +short radio-z.net ns
robotns3.second-ns.com.
ns1.first-ns.de.
robotns2.second-ns.de.
2) with dns (tracing from dns root, asking every
