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

From: Wietse Venema (no email)
Date: Thu Dec 01 2005 - 10:54:09 EST

  • Next message: Wietse Venema: "Re: timeout after DATA Error"

    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


  • Next message: Wietse Venema: "Re: timeout after DATA Error"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD