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

RE: Accept message and defer delivery

Expand Messages
  • Mutter, James
    What s to prevent whatever in a header_check, body_check, or access table from catching the message when it s released from the hold queue and causing a loop
    Message 1 of 8 , Nov 30, 2005
    • 0 Attachment
      What's to prevent whatever in a header_check, body_check, or access
      table from catching the message when it's released from the hold queue
      and causing a loop of sort?

      Too bad about your DELAY patch, sounds like it's exactly what we're
      after.

      Thanks,
      Jim


      >
      > What's the best way to have Postfix accept messages and defer delivery
      > until a later, predetermined time?

      Put in the "hold" queue using "HOLD" in an access(5) table or
      header/body
      checks. Release it with "postsuper -H" at your convenience.

      # Release all held mail, to be selective:
      # postsuper -H - < list_of_queue_ids_one_per_line
      #
      postsuper -H ALL

      # Optional if you can't wait for the next deferred queue scan:
      #
      postkick public qmgr D




      _______________________________________________________

      Juniper Bank
      www.juniper.com
      _______________________________________________________

      This e-mail and any files transmitted with it may contain confidential
      and/or proprietary information. It is intended solely for the use of
      the individual or entity who is the intended recipient. Unauthorized
      use of this information is prohibited. If you have received this in
      error, please contact the sender by replying to this message and
      delete this material from any system it may be on.
    • Victor Duchovni
      ... Messages released from the hold queue are already in the queue and are not subject to any additional input processing on the same machine.
      Message 2 of 8 , Nov 30, 2005
      • 0 Attachment
        On Wed, Nov 30, 2005 at 01:36:16PM -0500, Mutter, James wrote:

        > What's to prevent whatever in a header_check, body_check, or access
        > table from catching the message when it's released from the hold queue
        > and causing a loop of sort?

        Messages released from the hold queue are already in the queue and are
        not subject to any additional input processing on the same machine.

        http://www.postfix.org/OVERVIEW.html

        What happens to them when they are forwarded to another machine is of
        course entirely up to the receiving systems.

        > Too bad about your DELAY patch, sounds like it's exactly what we're
        > after.
        >

        The HOLD option works very similarly and gives you more explicit control
        over the timing of the release.

        If you note the queue ids in the SMTP "." responses as you submit the
        mail, you have a list of queue ids to release later.

        --
        Viktor.

        Disclaimer: off-list followups get on-list replies or get ignored.
        Please do not ignore the "Reply-To" header.

        To unsubscribe from the postfix-users list, visit
        http://www.postfix.org/lists.html or click the link below:
        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

        If my response solves your problem, the best way to thank me is to not
        send an "it worked, thanks" follow-up. If you must respond, please put
        "It worked, thanks" in the "Subject" so I can delete these quickly.
      • Wietse Venema
        ... I copied and extended your code for the DELAY feature. The change did not go through last year because it made some invasive changes to the critical
        Message 3 of 8 , Nov 30, 2005
        • 0 Attachment
          Victor Duchovni:
          > On Wed, Nov 30, 2005 at 10:00:32AM -0500, Mutter, James wrote:
          >
          > >
          > >
          > > All,
          > >
          > > What's the best way to have Postfix accept messages and defer delivery
          > > until a later, predetermined time?
          >
          > Put in the "hold" queue using "HOLD" in an access(5) table or header/body
          > checks. Release it with "postsuper -H" at your convenience.

          I copied and extended your code for the DELAY feature. The change
          did not go through last year because it made some invasive changes
          to the critical infrastructure.

          After this year's code reorg it was mostly a matter of adding a
          few lines here or there without having to worry about collateral
          damage.

          The biggest change is in the user interface. I eliminated the need
          for a main.cf parameter that specifies the delay. Instead, user
          can specify the delay time together with the delay action.

          Wietse

          Quote from access(5) and header/body_checks(5):

          DELAY time
          Place the message into the deferred queue, and delay the initial
          delivery attempt by time. The time value may be followed by a
          one-character suffix that specifies the time unit: s (seconds),
          m (minutes), h (hours), d (days), w (weeks). The default time
          unit is s (seconds).

          Note: this action affects all the recipients of the message.

          Note: the delay value has no effect with remote file systems
          that don't correctly emulate UNIX local file system semantics.
          In that case, the delay will be half of $queue_run_delay on
          average.

          This feature is available in Postfix 2.3 and later.
        • Victor Duchovni
          ... Cool. Perhaps one more documentation caveat is in order: If an authorized (via $authorized_flush_user, default all users) user runs any of the equivalent
          Message 4 of 8 , Nov 30, 2005
          • 0 Attachment
            On Wed, Nov 30, 2005 at 09:09:25PM -0500, Wietse Venema wrote:

            > Quote from access(5) and header/body_checks(5):
            >
            > DELAY time
            > Place the message into the deferred queue, and delay the initial
            > delivery attempt by time. The time value may be followed by a
            > one-character suffix that specifies the time unit: s (seconds),
            > m (minutes), h (hours), d (days), w (weeks). The default time
            > unit is s (seconds).
            >
            > Note: this action affects all the recipients of the message.
            >
            > Note: the delay value has no effect with remote file systems
            > that don't correctly emulate UNIX local file system semantics.
            > In that case, the delay will be half of $queue_run_delay on
            > average.
            >
            > This feature is available in Postfix 2.3 and later.
            >

            Cool. Perhaps one more documentation caveat is in order:

            If an authorized (via $authorized_flush_user, default all users) user runs
            any of the equivalent commands:

            - postqueue -f
            OR - sendmail -q
            OR - postfix flush

            the mail may be delivered prior to the indicated time. For explicit
            manual control of release timing, putting the message in the hold queue
            many be more appropriate in some circumstances. If a lot (~100,000 or
            more) of messages are to be delayed, deferred queue scans can generate
            a significant I/O load on your system until the mail is delivered,
            once again the HOLD queue may be more appropriate in that case.

            --
            Viktor.

            Disclaimer: off-list followups get on-list replies or get ignored.
            Please do not ignore the "Reply-To" header.

            To unsubscribe from the postfix-users list, visit
            http://www.postfix.org/lists.html or click the link below:
            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

            If my response solves your problem, the best way to thank me is to not
            send an "it worked, thanks" follow-up. If you must respond, please put
            "It worked, thanks" in the "Subject" so I can delete these quickly.
          • Wietse Venema
            ... Is a feature still worth implementing when its documentation spends so much on disclaimers? Normally such an amount of bad news would be sufficient for
            Message 5 of 8 , Dec 1, 2005
            • 0 Attachment
              Victor Duchovni:
              > On Wed, Nov 30, 2005 at 09:09:25PM -0500, Wietse Venema wrote:
              >
              > > Quote from access(5) and header/body_checks(5):
              > >
              > > DELAY time
              ...
              > > Note: the delay value has no effect with remote file systems
              > > that don't correctly emulate UNIX local file system semantics.
              > > In that case, the delay will be half of $queue_run_delay on
              > > average.
              >
              > Cool. Perhaps one more documentation caveat is in order:
              >
              > If an authorized (via $authorized_flush_user, default all users) user runs
              > any of the equivalent commands:
              >
              > - postqueue -f
              > OR - sendmail -q
              > OR - postfix flush
              >
              > the mail may be delivered prior to the indicated time. For explicit
              > manual control of release timing, putting the message in the hold queue
              > many be more appropriate in some circumstances. If a lot (~100,000 or
              > more) of messages are to be delayed, deferred queue scans can generate
              > a significant I/O load on your system until the mail is delivered,
              > once again the HOLD queue may be more appropriate in that case.

              Is a feature still worth implementing when its documentation spends
              so much on disclaimers? Normally such an amount of "bad news" would
              be sufficient for me to immediately remove the feature from Postfix.

              The remote file system limitation is hard to work around even when
              we were to set aside a dedicated "delay" queue that is examined
              only when Postfix somehow figures out that it should. And if we
              have a dedicated "delay" queue, we just re-invented an existing
              mechanism, the HOLD queue. That's not good.

              The "postfix flush" etc. limitation is inherent to the use of the
              deferred queue, just like defer_transports and other mechanisms.
              We may very well want to have some "do not deliver now" queue but
              that requires some intelligence with respect to expiration. Until
              now I have avoided the need for cron jobs that clean Postfix queues
              and I would like to keep it that way.

              The disk I/O load issue is just plain stupid. When we know that
              the mail won't go out until several hours from now, Postfix should
              not be wasting resources on it.

              Let's withdraw the DELAY feature until we have a proper design.

              Wietse
            • Victor Duchovni
              ... Well, to be honest, I am no longer confident that the answer is yes. We really would need a bunch of new queues (neither hold nor deferred ) before this
              Message 6 of 8 , Dec 1, 2005
              • 0 Attachment
                On Thu, Dec 01, 2005 at 10:54:09AM -0500, Wietse Venema wrote:

                > Victor Duchovni:
                > > On Wed, Nov 30, 2005 at 09:09:25PM -0500, Wietse Venema wrote:
                > >
                > > > Quote from access(5) and header/body_checks(5):
                > > >
                > > > DELAY time
                > ...
                > > > Note: the delay value has no effect with remote file systems
                > > > that don't correctly emulate UNIX local file system semantics.
                > > > In that case, the delay will be half of $queue_run_delay on
                > > > average.
                > >
                > > Cool. Perhaps one more documentation caveat is in order:
                > >
                > > If an authorized (via $authorized_flush_user, default all users) user runs
                > > any of the equivalent commands:
                > >
                > > - postqueue -f
                > > OR - sendmail -q
                > > OR - postfix flush
                > >
                > > the mail may be delivered prior to the indicated time. For explicit
                > > manual control of release timing, putting the message in the hold queue
                > > many be more appropriate in some circumstances. If a lot (~100,000 or
                > > more) of messages are to be delayed, deferred queue scans can generate
                > > a significant I/O load on your system until the mail is delivered,
                > > once again the HOLD queue may be more appropriate in that case.
                >
                > Is a feature still worth implementing when its documentation spends
                > so much on disclaimers? Normally such an amount of "bad news" would
                > be sufficient for me to immediately remove the feature from Postfix.

                Well, to be honest, I am no longer confident that the answer is yes.
                We really would need a bunch of new queues (neither "hold" nor
                "deferred") before this works properly. I think it should wait.

                > The "postfix flush" etc. limitation is inherent to the use of the
                > deferred queue, just like defer_transports and other mechanisms.
                > We may very well want to have some "do not deliver now" queue but
                > that requires some intelligence with respect to expiration. Until
                > now I have avoided the need for cron jobs that clean Postfix queues
                > and I would like to keep it that way.

                We agree.

                > The disk I/O load issue is just plain stupid. When we know that
                > the mail won't go out until several hours from now, Postfix should
                > not be wasting resources on it.
                >
                > Let's withdraw the DELAY feature until we have a proper design.
                >

                Yes, seconded.

                --
                Viktor.

                Disclaimer: off-list followups get on-list replies or get ignored.
                Please do not ignore the "Reply-To" header.

                To unsubscribe from the postfix-users list, visit
                http://www.postfix.org/lists.html or click the link below:
                <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                If my response solves your problem, the best way to thank me is to not
                send an "it worked, thanks" follow-up. If you must respond, please put
                "It worked, thanks" in the "Subject" so I can delete these quickly.
              Your message has been successfully submitted and would be delivered to recipients shortly.