On Fri, 2004-10-01 at 02:40, william(at)elan.net wrote:
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
recipient. 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 overriding 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
information and at best you can hope to find EHLO name and
ip address of the SMTP Client and even that is not for certain.
There has been some consideration given this within CSV. It would be
helpful to mark the Received header indicating a successful validation
using the CSV record. This would assist in locating the weak-link and
perhaps to deprecate message assertions as a result.
Once the HELO domain has been validated, then the address list technique
of SPF and Sender-ID can be abandoned and replaced by the use of a name
list. This name list approach is much more expedient and safer.
Any reputation assertions should be based upon the HELO information and
not the mailbox domain. A name list referenced by the mailbox domain
will allow rejection of obviously spoofed mail or alert the receiver of
this potential. The mailbox domain identity carried through the mail
channel is not strong enough to safely base negative assertions. If to
stop the problem, stop it at the source. The source is the mail
transfer agent, and any name involved with blocking must be constrained
to exclusively identify the administration of the mail transfer agent.
-Doug