Loading ...
Sorry, an error occurred while loading the content.
 

Re: unverified_recipient_tempfail_action = permit

Expand Messages
  • Charlie Orford
    ... 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
    Message 1 of 41 , Jul 5, 2011
      >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 <mark@...>: Recipient address rejected: unverified address: lost connection with mx1.xxxxxx.com[11.12.13.14] 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[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
    • Wietse Venema
      ... Indeed, and that is not what tempfail_action = permit does. That explicitly verifies no recipients while the primary is down. I have seen no credible
      Message 41 of 41 , Jul 6, 2011
        Charlie Orford:
        >I know I am starting to sound like a broken record but I really
        >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
        >have.

        Indeed, and that is not what "tempfail_action = permit" does. That
        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 =
        >address_verification_polling, relay_recipient_maps

        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.

        Wietse
      Your message has been successfully submitted and would be delivered to recipients shortly.