On Sat, 19 Aug 2000 [EMAIL PROTECTED] wrote:
Well spotted Richard.
I haven't looked at this particular paper, but one of the benefits of all
the ATM development work that the Telcos have done over the last 5 or so
years is the intense focus on scheduling algorithms with an emphasis
on
On Aug 18 2000, Michael T. Babcock wrote:
I'm not Dan, but this is slightly less mathematical than it sounds. The
main point (if I understand DJB here) is:
Its only an hour late? Another 10 minutes will hurt about "this much".
Its a day late? Another hour will probably also hurt about
On Fri, 18 Aug 2000, Rogerio Brito wrote:
I was looking for more detains about the mathematical side of
the things (e.g., what is the measure of "hurt", in your words
or the cost to which Dan refers?) and like why the optimal
retry schedule is essentially independent
On Sat, Aug 19, 2000 at 07:42:04PM +0100, [EMAIL PROTECTED] wrote:
On Fri, 18 Aug 2000, Rogerio Brito wrote:
I was looking for more detains about the mathematical side of
the things (e.g., what is the measure of "hurt", in your words
or the cost to which Dan refers?) and like
I'm not Dan, but this is slightly less mathematical than it sounds. The
main point (if I understand DJB here) is:
Its only an hour late? Another 10 minutes will hurt about "this much".
Its a day late? Another hour will probably also hurt about "this much".
Its a week late? Another (day?)
On Thu, 17 Aug 2000, Eric Cox wrote:
[EMAIL PROTECTED] wrote:
If you only go to an hour granularity and assume a queuelifetime of no
more than seven days, then you only need 168 instances. I was kinda thinking
of something a little more elegant than that...
How about using
[EMAIL PROTECTED] wrote:
On Thu, 17 Aug 2000, Eric Cox wrote:
[EMAIL PROTECTED] wrote:
If you only go to an hour granularity and assume a queuelifetime of no
more than seven days, then you only need 168 instances. I was kinda thinking
of something a little more elegant than
Is there any way to change the queue time to where it will retry more often?
On Thu, Aug 17, 2000 at 11:12:30AM -0500, Shane Wise wrote:
Is there any way to change the queue time to where it will retry more often?
No, I'm afraid not.
However, giving qmail-send and ALRM signal will cause all deferred
deliveries to be retried.
james
--
James Raftery (JBR54
Shane Wise [EMAIL PROTECTED] writes on 17 August 2000 at 11:12:30 -0500
Is there any way to change the queue time to where it will retry more often?
No. Why do you think you need this?
The current algorithm is essentially exponential backoff by host. It
tries more often at first
PROTECTED]
Shane Wise [EMAIL PROTECTED] writes on 17 August 2000 at
11:12:30 -0500
Is there any way to change the queue time to where it will retry more
often?
No. Why do you think you need this?
The current algorithm is essentially exponential backoff by host. It
tries more ofte
by host algorithm.
- Original Message -
From: "Michael T. Babcock" [EMAIL PROTECTED]
To: "David Dyer-Bennet" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, August 17, 2000 10:23 AM
Subject: Re: Queue Time
The current algorithm is probably fine for most u
On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
This doesn't even make sense, are you looking to configure a different time
period for different users?
This isn't even possible, or neccessary.
Hmm. I think this'd be a pretty useful feature actually.
If I send an email to mother
Date: Thu, 17 Aug 2000 11:32:00 -0700
From: [EMAIL PROTECTED]
On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
This doesn't even make sense, are you looking to configure a different time
period for different users?
This isn't even possible, or neccessary.
[EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at 11:32:00 -0700
I can't see much harm in being able to define the queuelifetime on
an individual submission - perhaps limited to between 0 and some
multiple of control/queuelifetime.
The harm is in the increased complexity of
- Original Message -
From: "David Dyer-Bennet" [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at
11:32:00 -0700
I can't see much harm in being able to define the queuelifetime on
an individual submission - perhaps limited to between 0 and some
From: "David Dyer-Bennet" [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 13:49:00 -0500 (CDT)
[EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at 11:32:00 -0700
I can't see much harm in being able to define the queuelifetime on
an individual submission - perhaps limited
On Thu, Aug 17, 2000 at 11:59:08AM -0700, Ian Lance Taylor wrote:
From: "David Dyer-Bennet" [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 13:49:00 -0500 (CDT)
[EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at 11:32:00 -0700
I can't see much harm in being able to
Michael T. Babcock [EMAIL PROTECTED] writes on 17 August 2000 at 14:52:40 -0400
- Original Message -
From: "David Dyer-Bennet" [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at
11:32:00 -0700
I can't see much harm in being able to
Date: Thu, 17 Aug 2000 12:07:24 -0700
From: [EMAIL PROTECTED]
The information is passed via the environment variable
QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
todo file. qmail-send moves this new code over to the info file, and
honors it when
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
This doesn't even make sense, are you looking to configure a different time
period for different users?
This isn't even possible, or neccessary.
Hmm. I think this'd be a pretty
On Thu, Aug 17, 2000 at 12:13:11PM -0700, Ian Lance Taylor wrote:
Date: Thu, 17 Aug 2000 12:07:24 -0700
From: [EMAIL PROTECTED]
The information is passed via the environment variable
QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
todo file.
If I send an email to mother saying "I'll be home for lunch" I'd like to tell my
MTA to drop/bounce the mail after that event has occurred.
One frequently-proposed (and possibly implemented) solution for such
time-critical email is to avoid queuing the message in the first place.
[EMAIL PROTECTED] wrote:
Hmm. A more devious hack might be to adjust the mtime of the info file to be
time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
much closer to zero then - albeit at the cost of a misleading info file...
And qmail-send would be using the tail end of
- Original Message -
From: "Charles Cazabon" [EMAIL PROTECTED]
If I send an email to mother saying "I'll be home for lunch" I'd like to
tell my
MTA to drop/bounce the mail after that event has occurred.
One frequently-proposed (and possibly implemented) solution for such
Date: Thu, 17 Aug 2000 12:21:33 -0700
From: [EMAIL PROTECTED]
Off tangent, how does an SMTP submission get at this feature? Interestingly,
it should probably be something that each MTA knows about to be truly useful,
consider secondary MXes gateway systems, etc. Ahh, a change in
Michael T. Babcock [EMAIL PROTECTED] wrote:
One frequently-proposed (and possibly implemented) solution for such
time-critical email is to avoid queuing the message in the first place.
Instead, you call qmail-remote directly with your message. If it succeeds,
you know immediately that
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
One frequently-proposed (and possibly implemented) solution for such
time-critical email is to avoid queuing the message in the first place.
Instead, you call qmail-remote directly with your message. If it succeeds,
you know immediately that
On Thu, Aug 17, 2000 at 03:27:35PM -0400, Dave Sill wrote:
[EMAIL PROTECTED] wrote:
Hmm. A more devious hack might be to adjust the mtime of the info file to be
time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
much closer to zero then - albeit at the cost of a
why not just run 2 instances of qmail. one w/ a queuelifetime of a few
days or a week and one with a lifetime of a few hours. if it has to go
out and can't it'll end up bouncing out of the queue quickly. it'll be
queued often in that short amount of time as desired.
--
Michael Boyiazis
On Thu, Aug 17, 2000 at 02:39:11PM -0700, M.B. wrote:
why not just run 2 instances of qmail. one w/ a queuelifetime of a few
days or a week and one with a lifetime of a few hours. if it has to go
out and can't it'll end up bouncing out of the queue quickly. it'll be
queued often in that
[EMAIL PROTECTED] wrote:
If you only go to an hour granularity and assume a queuelifetime of no
more than seven days, then you only need 168 instances. I was kinda thinking
of something a little more elegant than that...
How about using Netscape's X-Priority header to set the queue
On Aug 17 2000, David Dyer-Bennet wrote:
The harm is in the increased complexity of the queue itself, and in
the programs that manage and access it. Increased complexity costs
in reliability, security, and resources consumed.
As far as I can see (but I may be wrong here), there's no
On Aug 17 2000, David Dyer-Bennet wrote:
The current algorithm is essentially exponential backoff by host.
I don't think so. qmail uses a quadratic schedule for
deliveries (both local and remote, with the difference being
the coefficient of the quadratic function -- a
On Aug 17 2000, David Dyer-Bennet wrote:
I'd agree for simply changing the schedule (assuming the new
algorithm isn't more complicated). My response was to a proposal
for making the schedule *variable* by message.
Oh, sorry for responding to a different matter (I confess that
How long qmail can queue a messages? Is there any control to
change it?
RTFM qmail-send
Chris
36 matches
Mail list logo
