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

Re: unverified_recipient_tempfail_action = permit

Expand Messages
  • Charlie Orford
    ... I d like to chime in and add my support to this. Frankly, some of the obtuse replies to this reasonable feature request have been bordering on rude imho. I
    Message 1 of 41 , Jul 4 4:48 AM
    • 0 Attachment
      --- In postfix-users@yahoogroups.com, Wiebe Cazemier <wiebe@...> wrote:
      >
      > Hi,
      >
      > I don't really know where to post feature ideas, but this seems the only viable option.
      >
      > I was setting up a fallback MX server with Postfix and was struggling with preventing backscatter mail. I thought I found a good solution, but it turned out to be an illegal option.
      >
      > Postfix has the ability to do recipient address verification. When postfix acts as a relay server, this prevents backscatter mail (bounces of messages because the server that is relayed to doesn't accept the user). Backscatter is usually caused by spam of course, because spam is sent to all kinds of users @....
      >
      > I had in mind to use recipient address verification to avoid that and then set "unverified_recipient_tempfail_action = permit". The idea behind this was:
      >
      > - Prevent backscatter mail when the primary host is up because every address is verified first.
      > - Accept all mail when the primary host is down, so that incoming messages aren't deferred.
      >
      > But permit is not a valid option for unverified_recipient_tempfail_action. Would it be an idea to implement this?
      >
      > I know I can use permit_mx_backup and permit_mx_backup_networks, but I'd rather not have to maintain a list of networks on the fallback server, partly because I want to be a fallback server for servers that I don't maintain and of which I have no idea if the address changes.
      >
      > Regards,
      >
      > Wiebe
      >


      I'd like to chime in and add my support to this. Frankly, some of the
      obtuse replies to this reasonable feature request have been bordering
      on rude imho.

      I had a very similar problem to Wiebe last week when our primary mx
      started crashing because it could no longer communicate with our
      Dovecot SASL provider (dovecot had killed itself due to the system
      clock suddenly changing by 86 seconds, which itself was caused by
      a misconfigured ntp.conf file).

      While the primary was down, our secondary mx accepted mail for 3 of
      the domains it is configured to backup but all email to the fourth
      domain was deferred because it just so happened that the relevant
      entries in the verify_cache had expired shortly before the primary
      went down.

      The outage lasted about 4 hours but it would have been nice if
      senders hadn't received defferal messages and I could have simply
      flushed the backup queue to get the mail across once the primary was
      running again. Instead we had to wait for the affected sender MTAs
      to re-try delivery.

      unverified_recipient_tempfail_action = permitĀ  would have solved this
      problem with the small penalty of a brief period of potential
      backscatter.

      Where is the down side?

      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 5:10 AM
      • 0 Attachment
        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.