On Fri, Mar 05, 2004 at 11:53:41AM -0500, Tabor J. Wells wrote:
> you'd think that the message was submitted to the queue on central
> at 22:00:01 and then sat on queue for close to 4 hrs before being delivered
> to mercury. However that was not the case. It was a script that started at
> 22:00 and slowly wrote data to the BSMTP pipe over the next 4 hrs.
>
> Arguably, the way things are now give an inaccurate portrayal of the message's
> lifetime on the queue. I also think that that having them written before the
> entire message is received is counter-intuitive.
Without thinking about the architectural considerations first, it might be
sensible to have a comment that details how long the message took from, say,
MAIL FROM to final dot. In this way, the queue wouldn't be so inaccurate.
Also, as a question, would you expect, say, spam-scanning or demiming or
virus-scanning delays to be featured in this figure. Either way, not putting
the whole lifetime of a transaction makes one or other machine's queue look
broken, so it's probably worth adding an indication of the length of time
taken rather than just changing when the timestamping happens.
Of course, architecturally, that means that you add this header after final
dot. That is fun when it comes to writing out the -H queuefile, because
you need to create it at header time with the current architecture.
This does make the message receipt code significantly more complex, I
imagine, which is, really, the major reason not to do it. However, it would
seem to be a nice addition if it is possible.
Cheers
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
