Re: unverified_recipient_tempfail_action = permit
>From: Wietse VenemaHi Wietse,
>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.
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
Jul 1 12:46:48 pike postfix/smtpd: connect from mo2.mail-out.ovh.net[126.96.36.199]
Jul 1 12:46:48 pike postfix/smtpd: NOQUEUE: reject: RCPT from mo2.mail-out.ovh.net[188.8.131.52]: 450 4.1.1 <mark@...>: Recipient address rejected: unverified address: lost connection with mx1.xxxxxx.com[184.108.40.206] while receiving the initial server greeting; from=<nicolas@...> to=<mark@...> proto=ESMTP helo=<mo2.mail-out.ovh.net>
Jul 1 12:46:48 pike postfix/smtpd: disconnect from mo2.mail-out.ovh.net[220.127.116.11]
None of the address verification cache settings on either mail server have
been changed from their default (we are using the standard Debian Squeeze
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).
- Charlie Orford:
>I know I am starting to sound like a broken record but I reallyIndeed, and that is not what "tempfail_action = permit" does. That
>think a sensible, clean method to run a secondary mx that is capable
>of verifying recipients and accepting mail (rather than deferring)
>with or without the primary being up would be a nice feature to
explicitly verifies no recipients while the primary is down. I have
seen no credible report that your verify cache contains information
about a significant fraction of the recipient population.
>A postfix feature like: address_verify_sequence =That is unnecessary complexity: just use relay_recipient_maps and
be done with it. After all, relay_recipient_maps is the only
available measure against backscatter when the primary is down,
and you already have to maintain it anyway.