----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
To: "John Leslie" <john(_at_)jlc(_dot_)net>; "Tony Finch"
<dot(_at_)dotat(_dot_)at>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Friday, March 11, 2005 6:10 PM
Subject: Re: (lack of) message header field ordering
What it breaks is at least one detector for bogus or fraudulent
mail. If the rules of 2821 are followed, then there is no
mechanism by which headers can be injected into a message other
than at the beginning, making a message with fields ordered as
Return-path
Received
Received
To:
From:
Date:
Received
Received
MIME-version
a little dubious. Not nearly dubious enough, given the ways in
which things can be reordered, to reject or dump the message,
but perhaps worth a few points on an subjective probability
estimate that the message is at least partially faked.
Or perhaps the software is well, not too smart.
I'm still trying to figure out in a pure 2821 sense, how (or when) would it
be possible for a reordering can take place.
Off hand, the only reason I can see it happen is when the 2821 receiver has
determine there is a missing element or a message lacking a RFC header.
For example, depending on which is followed 822 or 2822, the receiver may
determine there is no valid RFC header and hence it will add its own. Or it
may add individual required headers, i.e, Message-Id: The latter is
possibly a mode where an reordering is more possible.
Which begs the question, what is the minimum requirement for an valid RFC
header required by a x821 process?
For a MUA, none.
For a MTA, Received: (before the server adds its own) + x822
I am not sure if this is optional for other servers, but ours, like most
servers will accept a DATA block that does not contain a RFC header.
Definitely a legacy issue.
So what logic should a x821 receiver have to determine whether there is a
valid RFC header?
Of course, starting with RFC 822 Section 4.1, the original requirement was:
Date:
From:
Destination fields: (To: | CC: )
We jump to RFC 2822 Section 3.5, and the current minimum requirement is:
Origination Date: Date:
Originator Field(s): From: | Sender: | Reply-To:
But I believe we do have a baseline requirement according to RFC x821. A
missing RFC header will cause the MSA to generate a RFC header for the
transaction:
Return-Path: <--- required by the MDA
Received: <--- required by the MTA hop
Date: <--- current time stamp
From: <--- from x821.Mail From command
To: <--- from x821.Rcpt To command
Message-Id: <--- generated by the host.
Sender: <--- from x821.Mail From command (redundant)
This should conform with RFC 821/822 and RFC 2821/2822 as well.
On a related note, I believe Bruce's new proposal which relaxes the From:
2822 requirement, will change the logic decision on how to fit it in. If
the MDA supports Bruce's proposal, then should the From: header not be
added? If Sender: is supported, then it should not be an issue from a 2821
standpoint.
However, at a minimum, for the sake of the gateway and the final MUA, the
Date:, From: and To: should be made available too for presentation reasons.
So this is another area where reordering may take place.
These are some issues that I am currently researching simply because the RFC
header is currently technically not required.
What's the BCP in this area?
Is this on topic, important? a non-issue?
Thanks
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
http://www.winserver.com (support)
http://www.santronics.com