> -----Original Message-----
> From: exim-users-admin@??? [mailto:exim-users-admin@exim.org]
> On Behalf Of Fred Viles
> Sent: Friday, March 12, 2004 10:13 AM
> To: exim-users@???
> Subject: RE: [Exim] Request for comment: changing Received header timestamps
>
>On 12 Mar 2004 at 9:16, Nick Ragouzis wrote about
> "RE: [Exim] Request for comment: cha":
>
>|...
>| Relating those definitions to SMTP one might take many definitions.
>|But when one limits oneself to SMTP, without the involvement of
>|extra-layer services, the reality of the reception is certain once DATA
>|begins. That is, the uncertainty of reception of an offered, valid
>|complete message (within SMTP's realm) is completely expired at that
>|point.
>
>Well, that is certainly not true. The sender may drop the connection
>before delivering the <CRLF>.<CRLF>, or the receiver may respond with
>an error code rather than success. ISTM in neither case has reception
>(within SMTP's realm) actually occured.
Oh, sure. And if the circumstances call for the message to persist at the receiver my argument stands: with certainty the message
reception was *COMPLETED* once DATA started. That is: within SMTP after DATA there are no partial failures. (And if the message will
not be retained? q.v If a tree fell ...)
> On the language lawyering point, FWIW, I think that the concensus
> view on what the word "received" means is definitive in such a grey
> area. I mean that literally.
Oh, consensus, sure. I just thought that perhaps, to disqualify it as an argument for changing the status quo, it would be
sufficient to show that the word has *equal* standing on *six* axes, including that of the status quo.
> On the practical point, where your argument is on the same turf as the
> original poster's: A single timestamp *must* misrepresent time spent
> in either the sender's or the recipient's queue when the transmission
> time is long, and this thread demonstrates that admins can have different
> opinions about which better serves their needs.
Perhaps. If so I'd say that it is the proposal that carries the burden of demonstrating the unique urgency of a change in the
current Exim semantics of the SMTP standards portion of that header.
> So if a change is worth making
Agreed, that's the question ... I haven't seen that case for change ...
> it makes sense to include both times in some form, as Phillip already
> proposed.
... but if Philip's made -final- sense of this, then fine by me.
> You haven't made a clear *practical* argument for having the
> parenthetic time be the ending time rather than the starting time
> (it could also be a duration, like "in NNN sec").
Well I've made a quick pass at it. Note that I'm not advocating either change ... I've suggested that in place of the current weak
use case for changing the status quo semantics to the standards part of that header, the as-presented use case might be sufficiently
strong to justify a different request: a request for a change (addition) to the non-standards part of that header.
Of course it's all in the dismal context in which the confusion arises: as systems architects we've not yet been very good at
temporal constructs. And often for understandable reasons (well, excuses) -- once you start picking apart the various bits of
transactions there are many opportunities for time distinction.
I rush to agree that my suggestion for how the proposal might be changed (DATA ended xxxxxx) is no paradigm of clarity and point out
that while your (in NNN sec) offers improvements along some dimensions over (started at xxxxxx) it also is not unequivocally
distinctive related to unknown timestamp semantics. Further, that (in NNN sec) doesn't offer a timestamp points out that we've not
really agreed on the purposes of the time information (e.g. calculations or matching?) let alone why the semantics might be
*universally* better if changed.
In arguing that the request hasn't met a standard of argument I've presented three practical aspects of current use of the current
semantics. I've relied (1) on the purposes mentioned in the SMTP standard for the gatewaying case, tied to (2) the common cases for
time stamping potentially long-running processes (Internet-based or otherwise), in the pursuit of (3) network-wide systems
debugging.
All three of these categories are onset cases. Later (or automatically in semi-real-time) given a message having Received: headers
that have an onset time in the standard-defined date-time spot, administrators (and their tools, this is where I'm most cautious)
across multiple systems will easily find the initial thread of the related packet filter and firewall records, related process
launches, and file system events (among others). This activity would not be so automatic for a long-running delivery, the kernel of
the use case, if we change Exim's Received: date-time semantics to those of *COMPLETED*.
Further, although the current proposal's change doesn't really advance its use case in any context other than that of the final MTA
(making it really an MTA question). That administrator (and any tools) will be able pick up from the current status quo onset
timestamp to answer questions about MTA-related queue latency.
> I don't see that it makes much difference, so long as the wording
> is clear.
Well, your next question is more to the point, isn't it ...
> Is there any consistency to what other MTAs do?
... because it will often be OTHER MTA (Exim or otherwise) mail and network administrators that are reading the Exim headers and
working out which version of Exim handled the gatewaying and the semantics of the Received: date. And changing their tools to
support both versions. Or changing them back to align their Exim processing with their other MTAs Received: lines. I don't know
which -- unfortunately my time with other MTAs is long past (hooray! may it forever be so), and my rereading of various archives
didn't pop anything up. We need more eyes.
> - Fred
Best,
--Nick
