RE: [Exim] Request for comment: changing Received header tim…

Góra strony
Delete this message
Reply to this message
Autor: Nick Ragouzis
Data:  
Dla: 'Fred Viles', exim-users
Temat: RE: [Exim] Request for comment: changing Received header timestamps
Fred,

> Queue write time

I was just responding in the context of the original use case.
That is, the confusion by a (new?) administrator of whether
the message sat on the queue or was still being received in
that time span.

> reflect start or ended

Right. Reflect start.

I view advent times are the crucial times for tracing problems
and synchronizing with the related facilities. Debugging mail
forwarding and gatewaying only one among many. And the tracing
I'm addressing has as much to do with real-time-ish automation
across many services as it does after-the-fact humans.

Transaction duration and completion times are another aspect
altogether.

> Philip's proposal ... add both

(DATA ended at xxxxxx) is fine with me.

Best,
--Nick

-----Original Message-----
From: exim-users-admin@??? [mailto:exim-users-admin@exim.org] On Behalf Of Fred Viles
Sent: Thursday, March 11, 2004 10:21 AM
To: exim-users@???
Subject: RE: [Exim] Request for comment: changing Received header timestamps


On 11 Mar 2004 at 7:25, Nick Ragouzis wrote about
    "RE: [Exim] Request for comment: cha":


| Just catching up on the list ...

|
| My own view is that this is an inappropriate change.

|
| The semantics of those headers belong to message transmission not
| queue management.


True. But the question is simply whether the Received: header should reflect when the message transmission *started* (DATA) or when
it
*ended* (<CRLF>.<CRLF>). Ended seems to make more sense logically, because the message hasn't actually been received until then.

| In the service of the confused admin, I think it *would* be
| appropriate to add an additional log message in the case of
| (configurable? 10 minutes is ok with me) excessive queue write time.


Queue write time isn't really the issue, message reception time is. Philip's proposal to log both start and end times does address
the problem that a single timestamp must misrepresent queue residence time on one end or the other when transmission time is long.

- Fred





--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##