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

Re: DELAY action (was: Accept message and defer delivery)

Expand Messages
  • 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 1 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 2 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.