Disregard, I've obviously chosen a bad example - optimistic caching
until address_verify_positive_expire_time means the behavior was correct
in this case.
I did know that the exmployee in question hadn't been with the company
for months now and seemed to remember that they had disabled his e-mail
address months ago, but apparently this has happened only on Nov 22th.
I did have another case of such behavior with an address that has indeed
been invalid for a long time, and this correctly rejects now too, so
there seemed to be some form of corruption that is now fixed.
- Patrick
On 11.12.2016 10:48, Wagner, Patrick wrote:
On 10.12.2016 22:12, Wietse Venema wrote:
So there are two possible explanations:
1) Your SMTP server was recently under overload (look for "STRESS"
in the maillog file). To avoid accepting unverified mail under
overload, remove the "unverified_recipient_defer_code = 250" setting.
2) Your address_verify_map database is corrupted. Remove the .db
file, and execute "postfix reload".
Wietse
According to the log files the server wasn't in STRESS mode at this
point in time (about an hour before, it had entered and left STRESS
mode within 6 seconds), so this leaves a corrupted verify_cache.db.
I've removed the database, reloaded postfix, and a test mail to this
non-existent address has correctly detected and honored the
undeliverable status and I got the NOQUEUE: reject line that I expected.
Apparently the probe couldn't update the address status to
"undeliverable" result in the DB - the address in question was
actually perfectly valid until November 22th, so still within
address_verify_positive_expire_time = 31d , but not
address_verify_positive_refresh_time = 7d, which is why postfix kicked
off the probe every time someone tried to send a mail to this recipient.
There's no way to monitor for this kind of corruption then, as I've
got no messages in my log telling me that the verify service was
unable to update certain database entries?
- Patrick
