- Previous message: Victor Duchovni: "Re: Another SPAM doubt"
- Maybe in reply to: Wietse Venema: "Re: DELAY action (was: Accept message and defer delivery)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Victor Duchovni (no email)
Date: Thu Dec 01 2005 - 12:11:05 EST
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:?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.
|
|
|