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

Re: smtp_fallback_relay

Expand Messages
  • 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 1 of 17 , Jun 13, 2013
    • 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 2 of 17 , Jun 13, 2013
      • 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 3 of 17 , Jun 14, 2013
        • 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.