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

Accept message and defer delivery

Expand Messages
  • Mutter, James
    All, What s the best way to have Postfix accept messages and defer delivery until a later, predetermined time? We ve got a scenario where we would like to
    Message 1 of 8 , Nov 30, 2005
    • 0 Attachment
      Accept message and defer delivery

      All,

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

      We've got a scenario where we would like to populate the outgoing queues with messages in the middle of night and defer delivery until sometime in the early morning/afternoon hours.  The simple way seems to be to swap a new master.cf with a commented/uncommented smtp line, but it also seems a bit kludgy.  Is there a more elegant way to accomplish this?


      Thanks,
      Jim



      _______________________________________________________

      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
      ... 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
      Message 2 of 8 , Nov 30, 2005
      • 0 Attachment
        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.

        # 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

        > We've got a scenario where we would like to populate the outgoing queues
        > with messages in the middle of night and defer delivery until sometime
        > in the early morning/afternoon hours. The simple way seems to be to
        > swap a new master.cf with a commented/uncommented smtp line, but it also
        > seems a bit kludgy. Is there a more elegant way to accomplish this?
        >

        I once had a "DELAY" patch for this, but it never quite panned out to
        a feature that warranted inclusion in the official release.

        --
        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.
      • 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 3 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 4 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 5 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 6 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 7 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 8 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.