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 Netscape's X-Priority header to set the queue lifetime
> according to the admin's wishes. Set 5 different queue lifetimes
> according to based on the 5 settings of the X-Priority header. This
> could be accomplished with Ian's patch, and some preprocessing before
> qmail-inject.
qmail-send doesn't read the contents of the mesdsage, so qmail-queue would
have to do this to set the appropriate value into the queue control files
that qmail-send does read.
Considering the case of 'this mail message is no longer of use unless
delivered to the recipient BY time X'. On a qmail system we only have
control of the retry schedule on suystems which we control: if the MX
records for my mother's ISP's mail servers points to something other than
her machine (and it does) then I loose control of the delivery timing. In
fact if I'm emailing her to tell her what time I'm going to be home for
lunch (improbably given we're several thousand miles apart) I need to set
the time to much less than the real value by which I need to let her know
when I'll be home, so any bounce message has time to make it back from her
ISP to me so I know to telephone her.
Consider the case of 'this message is URGENT, deliver it first' this is
okay, however when email systems become congested I have observer that
people start marking all messages as urgent just so thier mail gets
delivered quickly (this is analogous to ordinary users being able to use
negative values for nice(1) and so boosting their prioity) eventually
everyone figures out how to do this and the benefit diminishes. I'm not
sure that retrying delivery frequently is going to get an urgent delivery
delivered /that/ much more frequently than it would have anyway. At the
start of the delivery schedule the times are every few seconds, growing to
every few minutes and then to every few hours. if the message were truly
URGENT then if immediate delivery is not available it should be returned
quicker than for normal delivery. (This principle was used in the Glasgow
mail package I was using on prime9955 minicomputers in the 1980's.) Urgent
messages got returned in half the time of normal messages and non-urgent
messages had twice the queuelifetime of normal messages.
so, the last case is one which is worthwhile, but only applies to This
MTA, once this mta has disposed of a message then all bets are off as to
when it will get delivered (if at all).
oh, for MUA integrated delivery status tracking like you can get out of
X.400 <evil grin> (I've received X.400 DSNs vie internet mail and the
first time you get one you think what on earth is this huge chunk of
binary data)
RjL
