SUMMARY * Scenario/repeatability: - Typical default postfix configuration - An alias is added, but with a typo. - Incoming email is rejected as expected, "Recipient address rejected: undeliverable address: unknown user: "address" - Typo corrected. newaliases is used. Postfix can be restarted. Doesn't matter. - Local email to the alias now works - Incoming email is still rejected, as it fails reject_unverified_recipient. Even ten hours later.
* Expected result - After newaliases, and particularly after postfix reload, the alias should function. * Turned on debugging to log level 10. Revealed nothing interesting. * Analysis - See www.postfix.org/ADDRESS_VERIFICATION_README.html#caching - Since Postfix 2.7, there's a persistent verification database. - By default, address_verify_map = btree:$data_directory/verify_cache - By default, the database survives newaliases, postfix reload, and postfix stop - By default, all failed probes (even of local/aliases) expire after three days. - Workaround: postfix stop; rm $data_directory/verify_cache.db; postfix start * Discussion - This is a very non-intuitive implementation, and very difficult for an average admin to diagnose: no information points to the verification cache. - Having examined the (verify.c) code, I realize a 'nice' solution (clear cache of local address entries after newaliases) isn't that simple. Someone with more experience can likely design a proper fix. * Suggestions - At the very least, this needs to be highlighted in documentation for newaliases etc - Next step: distinguish local and non-local addresses; enable reset of local cache entries after newaliases. [end] _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
