On Fri, 1 Oct 2004, Danny Angus wrote:
From a purely engineering point of view, it is nice and
reasonable. But for producing actual outputs, I doubt you will be able
to update RFC 2821 and 2822 on Received headers in the short term. Or
to modify the code of several MTAs.
Fair point.
What I'm actually proposing, though, is that a new, stricter, specification
for Recieved(etc) be written as an interim measure which would not obsolete
2822 but compliment it. Eventually the next iteration of 822 et al could
obsolete our rfc and adopt the chnage.
I really don't know if it helps but for some time I've been gathering data
on errors in Received lines and which MTAs are compliant and not. The
results I have so far is that virtually all MTAs under certain conditions
(and some always) add Received lines that are directly syntatically
incompatible with RFC2822. And in any case fixing Received is completely
diffirent task that will probably take quite a bit more effort even if
new draft is published.
Plus as far as which of the data that goes into Processed-By is also in
Received, there is only one value - envelope recepient (which is "for"
clause on received line). The envelope from (returnpath) is added in this
from by one mailer:
Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131])
by above.proper.com (8.12.11/8.12.9) with SMTP id i918GsKb059836
for <ietf-mxcomp(_at_)imc(_dot_)org>; Fri, 1 Oct 2004 01:16:55 -0700
(PDT)
(envelope-from Danny_Angus(_at_)slc(_dot_)co(_dot_)uk)
But if you look at RFC2822 it says that syntax of Received is:
received = "Received:" name-val-list ";" date-time CRLF
date-time = [ day-of-week "," ] date FWS time [CFWS]
time = time-of-day FWS zone
zone = (( "+" / "-" ) 4DIGIT)
Based on above addition of "(envelope-from
ph10(_at_)cus(_dot_)cam(_dot_)ac(_dot_)uk)" at the end
of Received after time violates RFC2822, so we should not promote this
behavior for the future. In addition I do not think it is appropriate
behavior to mandate adding "envelope-from" to every received line, its
of interest to know the value when it has changed, but repeating it every
time is waste of header space (did you call that "header blotting"?).
Additionally Processed-By provides for new "Original-*" headers for
recording previous values of Sender, CC, Reply-To, List-ID, etc. There
is no equivalent for this in current SMTP specs and if you send email
to mail list, it'll rewrite original Sender and its value is lost to
recepient. If you have message that went through more then one mail list,
you'll only see info about last email list, as each would want to add
the same list of headers overiding previous values (and sometimes
mixing it up which is even worth). When you add forwarding to the mix
the situation is even worth.
So I'm sorry but I really don't see how Received line is going to help
with all this, we do need new specification. And as far as Received
line - its also a good idea idea to write something up to explain to MTA
writers what they need to do with it, but this is separate task.
I think that most MTA's already validate and publish some degree of
optional information in received headers
Hahaha (sorry it the "most" part and "validate" that got me...)
As far as optional information - entire Received line is optional
informatio and at best you can hope to find EHLO name and
ip address of the SMTP Client and even that is not for certain.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/