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

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

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