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

smtp_fallback_relay

Expand Messages
  • Ralf Hildebrandt
    Currently, smtp_fallback_relay is being used after the first failed delivery. http://www.postfix.org/postconf.5.html#smtp_fallback_relay explicitly mentions:
    Message 1 of 17 , Jun 13 6:40 AM
    • 0 Attachment
      Currently, smtp_fallback_relay is being used after the first failed
      delivery.

      http://www.postfix.org/postconf.5.html#smtp_fallback_relay
      explicitly mentions: "With bulk email deliveries, it can be beneficial
      to run the fallback relay MTA on the same host, so that it can reuse
      the sender IP address. This speeds up deliveries that are delayed by
      IP-based reputation systems (greylist, etc.)."

      i thought this could be done easier, like:

      Why not have either a smtp_fallback_relay_threshold
      parameter, which specifies after how many delivery attempts the mail
      will be passed to the smtp_fallback_relay.

      It would have to default to 1 to be backwards compatible.

      Alternative/additional approach:

      smtp_fallback_relay_threshold_time (compare to
      smtp_pix_workaround_threshold_time)

      How long a message must be queued before the Postfix SMTP client
      passes the mail to the smtp_fallback_relay.

      No idea what an appropriate default would be...

      --
      [*] sys4 AG

      http://sys4.de, +49 (89) 30 90 46 64
      Franziskanerstraße 15, 81669 München

      Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
      Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
      Aufsichtsratsvorsitzender: Florian Kirstein
    • Viktor Dukhovni
      ... Postfix does not record the number of delivery attempts in the queue file. Updates of such a record (unless it is a one byte gauge that tops out at 255)
      Message 2 of 17 , Jun 13 8:28 AM
      • 0 Attachment
        On Thu, Jun 13, 2013 at 03:40:33PM +0200, Ralf Hildebrandt wrote:

        > Currently, smtp_fallback_relay is being used after the first failed
        > delivery.
        >
        > http://www.postfix.org/postconf.5.html#smtp_fallback_relay
        > explicitly mentions: "With bulk email deliveries, it can be beneficial
        > to run the fallback relay MTA on the same host, so that it can reuse
        > the sender IP address. This speeds up deliveries that are delayed by
        > IP-based reputation systems (greylist, etc.)."
        >
        > i thought this could be done easier, like:
        >
        > Why not have either a smtp_fallback_relay_threshold
        > parameter, which specifies after how many delivery attempts the mail
        > will be passed to the smtp_fallback_relay.
        >
        > It would have to default to 1 to be backwards compatible.

        Postfix does not record the number of delivery attempts in the
        queue file. Updates of such a record (unless it is a one byte
        gauge that tops out at 255) cannot be done atomically, it may
        not accurately reflect the number of delivery attempts, since
        when a destination is throttled, some recipients are deferred
        without being tried or re-tried. So at best we could have a
        one byte count of how many times a message has been deferred.

        This would need be a new queue-file envelope record, so cleanup
        would have to write it into new queue files and qmgr would have to
        update it when deferring a queue file.

        > Alternative/additional approach:
        >
        > smtp_fallback_relay_threshold_time (compare to
        > smtp_pix_workaround_threshold_time)

        This can be done without changing the queue file format.

        > How long a message must be queued before the Postfix SMTP client
        > passes the mail to the smtp_fallback_relay.

        Only after first trying the real destination. This may be the
        first attempt on a sufficiently congested system.

        > No idea what an appropriate default would be...

        The default should disable this new feature, some people rely on
        the fallback relay kicking in right away. Thus the default would
        be 0.

        Otherwise, 1-3 hours is about right, the geometric mean of 300s
        and 5d is 3hours. Use the lower end of the range if maximal_backoff_time
        is substantially smaller than 1 hour and the higher end if maximal
        backoff time is at least 1 hour.

        --
        Viktor.
      • Wietse Venema
        ... Problems: 1) There is no delivery attempt counter. That counter would have to be per-recipient. If this counter is larger than 1 byte, then it may span
        Message 3 of 17 , Jun 13 9:48 AM
        • 0 Attachment
          Ralf Hildebrandt:
          > Currently, smtp_fallback_relay is being used after the first failed
          > delivery.
          >
          > http://www.postfix.org/postconf.5.html#smtp_fallback_relay
          > explicitly mentions: "With bulk email deliveries, it can be beneficial
          > to run the fallback relay MTA on the same host, so that it can reuse
          > the sender IP address. This speeds up deliveries that are delayed by
          > IP-based reputation systems (greylist, etc.)."
          >
          > i thought this could be done easier, like:
          >
          > Why not have either a smtp_fallback_relay_threshold
          > parameter, which specifies after how many delivery attempts the mail
          > will be passed to the smtp_fallback_relay.

          Problems:

          1) There is no delivery attempt counter. That counter would have
          to be per-recipient. If this counter is larger than 1 byte, then
          it may span disk block boundaries, and it may become corrupted when
          the machine is shutdown without syncing the disk. Until now, message
          queue files have a strong guarantee against such corruption.

          2) As mentioned by Viktor the queue manager defers mail for dead
          destinations without contacting the SMTP client. In those cases the
          smtp_fallback_relay feature has no effect. For your suggestion to
          work we would have to move fallback_relay logic from the SMTP client
          into the queue manager. That's a lot of complexity for little gain.

          > Alternative/additional approach:
          >
          > smtp_fallback_relay_threshold_time (compare to
          > smtp_pix_workaround_threshold_time)
          >
          > How long a message must be queued before the Postfix SMTP client
          > passes the mail to the smtp_fallback_relay.

          A threshold would work, with the default of 0 meaning that the
          threshold is disabled.

          My time is very limited, and this feature is simple enough that I
          will take a patch for this.

          Wietse
        • Ralf Hildebrandt
          ... That sounds good. All I want is the machine to put some effort (a few tries) into delivery instead of going ah, no, give it to the fallback ... OK -- [*]
          Message 4 of 17 , Jun 14 1:52 AM
          • 0 Attachment
            > > Alternative/additional approach:
            > >
            > > smtp_fallback_relay_threshold_time (compare to
            > > smtp_pix_workaround_threshold_time)
            > >
            > > How long a message must be queued before the Postfix SMTP client
            > > passes the mail to the smtp_fallback_relay.
            >
            > A threshold would work, with the default of 0 meaning that the
            > threshold is disabled.

            That sounds good. All I want is the machine to put some effort (a few
            tries) into delivery instead of going "ah, no, give it to the fallback"

            > My time is very limited, and this feature is simple enough that I
            > will take a patch for this.

            OK

            --
            [*] sys4 AG

            http://sys4.de, +49 (89) 30 90 46 64
            Franziskanerstraße 15, 81669 München

            Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
            Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
            Aufsichtsratsvorsitzender: Florian Kirstein
          Your message has been successfully submitted and would be delivered to recipients shortly.