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.
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.
As to what you can do with the SMTP session between headers
and body time ...
... please note that the Exim MTA is bristling with extra-layer
and extra-protocol facilities and these extra-layer/protocol
systems are also part of the toolkit in managing Internet
services.
Now granted these extra-layer/protocol facilities are mostly
upward, to higher/other application layers. But this is not
an exclusive arrangement.
The realities of managing these environments is that traffic
management hosts should (must?) be made aware of all indicators
of undesired Internet-based activity ... ASAP.
These traffic management hosts are free to exercise their own
policies, even in real time. Such real time activities include
firewall-downing of network activity of any kind.
You may object to a single host blocking a transaction in mid-TCP
handshake ... but with multiple hosts feeding several downlayer
management hosts with information generated from multiple
protocol services, this kind of breakage is frequently seen.
So, even if one MTA, in the service of SMTP RFC fidelity, were
to hold on to that (virus) transaction to the bitter-SMTP-end,
its report will cause the firewalls to down the parallel traffic
on partner MTA hosts mid-SMTP.
The sooner the better.
Best,
--Nick
-----Original Message-----
From: exim-users-admin@??? [
mailto:exim-users-admin@exim.org] On Behalf Of Philip Hazel
Sent: Monday, March 08, 2004 01:55 AM
To: Tabor J. Wells; Ollie Cook; Matthew Byng-Maddick; Fred Viles
Cc: exim-users@???
Subject: Re: [Exim] Request for comment: changing Received header timestamps
On Fri, 5 Mar 2004, Tabor J. Wells wrote:
> I posed this question to Philip directly and he asked that I bring it
> up on the list for discussion. Currently Received: headers are written
> after the headers are received. I'd like to see that changed to them
> being written after the body is received.
On Fri, 5 Mar 2004, Ollie Cook wrote:
> My opinion is that "received" suggests "finished receiving" and it
> would therefore make sense to write the header after the whole message
> is received.
On Fri, 5 Mar 2004, Fred Viles wrote:
> FWIW I agree. I don't think it makes much difference in typical
> cases, but it does for unusual cases like Tabor's example. I can't
> think of any reason to object to the change conceptually, so it would
> just be a matter of implementation effort -vs- benefit.
On Fri, 5 Mar 2004, Matthew Byng-Maddick wrote:
> 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.
Thanks, guys. It seems that a change is perhaps in order. (I think the current arrangement goes right back to Exim 0.0.) I propose
the
following:
(a) Change the time to the time after the body was received, but
*before* the DATA or non-SMTP ACL is run (because you might want to inspect the Received: headers in those ACLs).
(b) If the difference between the time of starting to receive the message and this time is greater than 10 minutes (say), add an
extra comment to the Received: line saying "(started at xxxxxx)". This would be the start of the DATA segment rather than MAIL FROM
(because that is all contained in one module and I don't think the extra effort to take it from MAIL FROM is worth it - but you may
disagree...)
> 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.
No, that's not the way it currently works. It doesn't actually write the -H file until the -D file is safely written. Up to then,
the header lines are kept in main memory.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
## List details at
http://www.exim.org/mailman/listinfo/exim-users Exim details at
http://www.exim.org/ ##
