>From: Wietse Venema >Sent: Monday, July 4, 2011 9:10 PM >Subject: Re: unverified_recipient_tempfail_action = permit > >My previous reply suffered from damage while editing. This is an >attempt to fix it. > >The problem with recipients not in the verify cache is easily >addressed with existing Postfix features. > >With unverified_recipient_tempfail_action=defer_if_permit or defer, >Postfix will pass mail for recipients that were added to the verify >cache up to 31 days ago. In addition, Postfix attempts to refresh >information after 7 days so that active recipients don't expire. >These are the default settings, which you can change. > >To avoid the expiration of known recipients after 31 days, you can >increase the address_verify_positive_expire_time setting to a larger >value. If you set the expiration time too long, there will be >backscatter after a recipient's account is terminated. Don't set >it to years. > >That leaves the rare case of a recipient who almost never receives >email. I think it would not be a problem if such email is delayed >by a few hours when the primaty MX host is down.
> Wietse Hi Wietse, Although the address caching should have worked as you describe, we found that it failed for a number of addresses despite the fact that these addresses had received email in the last 31 days (most had in fact received mail in the last 24 hours). Here is an excerpt from the log of our secondary mx, taken about two hours after the primary went down (domains and IPs fudged slightly for privacy): Jul 1 12:46:48 pike postfix/smtpd[18924]: connect from mo2.mail-out.ovh.net[178.32.228.2] Jul 1 12:46:48 pike postfix/smtpd[18924]: NOQUEUE: reject: RCPT from mo2.mail-out.ovh.net[178.32.228.2]: 450 4.1.1 <m...@xxxxxx.com>: Recipient address rejected: unverified address: lost connection with mx1.xxxxxx.com[11.12.13.14] while receiving the initial server greeting; from=<nico...@yyyyyy.com> to=<m...@xxxxxx.com> proto=ESMTP helo=<mo2.mail-out.ovh.net> Jul 1 12:46:48 pike postfix/smtpd[18924]: disconnect from mo2.mail-out.ovh.net[178.32.228.2] None of the address verification cache settings on either mail server have been changed from their default (we are using the standard Debian Squeeze postfix package). The only setting directly related to address verification that appears in both the primary and secondary main.cf is: address_verify_map = btree:$data_directory/verify_cache The verify_cache file exists on both machines and contains data. My conclusion is that either we have misconfigured something or everything is working as intended but the reason the secondary started deferring email is because it had never seen these addresses before (as it's cache is obviously seperate from the primary's cache)? If my second conclusion is correct, this situaiton could have been avoided with unverified_recipient_tempfail_action=permit (I think). Kind Regards, Charlie