On Sun, Aug 27, 2023 at 04:06:18PM -0400, Viktor Dukhovni via Postfix-users wrote:
> 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. FWIW, I am running an experiment on my end, asking the verify(8) service to verify a non-existent virtual mailbox: #define DEL_RCPT_STAT_OK 0 #define DEL_RCPT_STAT_DEFER 1 #define DEL_RCPT_STAT_BOUNCE 2 #define DEL_RCPT_STAT_TODO 3 # date; postconf address_verify_negative_refresh_time; printf 'request\0query\0address\0postfix-lus...@dukhovni.org\0\0' | nc -NU /var/spool/postfix/private/verify | tr '\0' '\n' Sun Aug 27 16:35:39 EDT 2023 address_verify_negative_refresh_time = 1200s protocol address_verification_prrotocol status 0 recipient_status 3 reason Address verification in progress The initial query returns a pending (TODO) result, which in short order resolves to an error (BOUNCE) status: Aug 27 16:35:39 amnesiac postfix/cleanup[55691]: C8FA712A3DC: message-id=<...> Aug 27 16:35:39 amnesiac postfix/qmgr[55681]: C8FA712A3DC: from=<double-bounce@...>, size=273, nrcpt=1 (queue active) Aug 27 16:35:39 amnesiac postfix/error[55692]: C8FA712A3DC: to=<postfix-lus...@dukhovni.org>, relay=none, delay=0.02, delays=0/0.02/0/0, dsn=5.1.1, status=undeliverable (User unknown in virtual alias table) Aug 27 16:35:39 amnesiac postfix/qmgr[55681]: C8FA712A3DC: removed # date; postconf address_verify_negative_refresh_time; printf 'request\0query\0address\0postfix-lus...@dukhovni.org\0\0' | nc -NU /var/spool/postfix/private/verify | tr '\0' '\n' Sun Aug 27 16:36:18 EDT 2023 address_verify_negative_refresh_time = 1200s protocol address_verification_prrotocol status 0 recipient_status 2 reason User unknown in virtual alias table After waiting out the 20 minute refresh TTL, another verify(8) query returns the same result: # date; postconf address_verify_negative_refresh_time; printf 'request\0query\0address\0postfix-lus...@dukhovni.org\0\0' | nc -NU /var/spool/postfix/private/verify | tr '\0' '\n' Sun Aug 27 16:55:44 EDT 2023 address_verify_negative_refresh_time = 1200s protocol address_verification_prrotocol status 0 recipient_status 2 reason User unknown in virtual alias table However, there's also a background probe: Aug 27 16:55:44 amnesiac postfix/cleanup[55843]: 9E78612A27D: message-id=<...> Aug 27 16:55:44 amnesiac postfix/qmgr[55681]: 9E78612A27D: from=<double-bounce@...>, size=273, nrcpt=1 (queue active) Aug 27 16:55:44 amnesiac postfix/error[55844]: 9E78612A27D: to=<postfix-lus...@dukhovni.org>, relay=none, delay=0.02, delays=0/0.02/0/0, dsn=5.1.1, status=undeliverable (User unknown in virtual alias table) Aug 27 16:55:44 amnesiac postfix/qmgr[55681]: 9E78612A27D: removed If I had already added the problem user, this probe would have updated the database to indicate that the user exists. After dropping the refresh time to 120s, and adding the table entry, we see: # date; postconf address_verify_negative_refresh_time; printf 'request\0query\0address\0postfix-lus...@dukhovni.org\0\0' | nc -NU /var/spool/postfix/private/verify | tr '\0' '\n' Sun Aug 27 17:02:28 EDT 2023 address_verify_negative_refresh_time = 120s protocol address_verification_prrotocol status 0 recipient_status 2 reason User unknown in virtual alias table But now the resulting background probe succeeds: Aug 27 17:02:28 amnesiac postfix/cleanup[55936]: 29A8112A603: message-id=<...> Aug 27 17:02:28 amnesiac postfix/qmgr[55921]: 29A8112A603: from=<double-bounce@...>, size=273, nrcpt=1 (queue active) Aug 27 17:02:28 amnesiac postfix/virtual[55937]: 29A8112A603: to=<...>, orig_to=<postfix-lus...@dukhovni.org>, relay=virtual, delay=0.03, delays=0/0.02/0/0, dsn=2.0.0, status=deliverable (delivers to maildir) Aug 27 17:02:28 amnesiac postfix/qmgr[55921]: 29A8112A603: removed So that, shortly after verification returns sucess (OK): # date; postconf address_verify_negative_refresh_time; printf 'request\0query\0address\0postfix-lus...@dukhovni.org\0\0' | nc -NU /var/spool/postfix/private/verify | tr '\0' '\n' Sun Aug 27 17:06:08 EDT 2023 address_verify_negative_refresh_time = 120s protocol address_verification_prrotocol status 0 recipient_status 0 reason delivers to maildir On the basis of this, I am sceptical that you'll be able to product contradictor evidence that shows that verification refreshes after the configuration updated fail to reset the database status for the next request after the one that triggers the probe. -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
