Hector,
Some of the issues here are connected to the reasoning behind
wanting a Message Submission protocol. Those have been kicked
to death already; I don't want to go there again.
To identify intent, rather than specific text,
No non-gateway MTA should be changing the order of
message headers, or even reading and interpreting the
headers it received, unless it is acting in a "gateway"
role and, then, only if necessary.
I don't know how to be more clear about that.
More below.
--On Saturday, 12 March, 2005 19:20 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
----- 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
...
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.
If what you mean by "smart" is that it reorders headers, then
your term "smart" is a synonym for "broken" or "non-conforming".
The text in 2821 that bars tampering with messages by MTAs that
are neither in "submission" nor in "final delivery" roles is as
clear as I knew how to make it. But that text did not change
the clear intent of 821, just repeated it more strongly.
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.
Really simple: never.
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.
2821 allows some flexibility for a submission MTA, but the
problems and issues with that were part of what motivated the
Message Submission Protocol. Even then, the only reordering
should be to insert missing headers below the first Received
field. There is no requirement or justification for reordering
existing fields.
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.
Still should not require reordering. MTAs that are not the
submission server should not even be looking at the headers to
determine that the information is missing. The delivery MTA
may look (although it doesn't have to), but there is a strong
case to be made that, if it doesn't like what it receives, it
should bounce the message rather than trying to fix it up. The
standard doesn't require that-- it encourages delivery on the
basis of the envelope only, i.e., not looking at the headers to
determine what might be missing.
Which begs the question, what is the minimum requirement for
an valid RFC header required by a x821 process?
There is an old controversy about this. One interpretation is
that, unlike 2821 with MIME, 821 does not require any particular
message format at all and, in particular, does not require any
822-style headers. Some people have taken the position for
many years that a header-free message was essentially required
for an implementation of SEND to make any sense at all.
If one takes a strong version of the "MTAs don't look at the
headers" principle, and states your question as above, the
answer is "none". Of course, one might then claim that
delivery from the delivery MTA into the mail store (or to the
receiving MUA) is not part of the "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.
See comments about 821 and SEND, above.
So what logic should a x821 receiver have to determine whether
there is a valid RFC header?
If it is not the final delivery MTA, it doesn't need any
"logic", because it should not be asking.
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:
None of those requirements apply to the MTA. Under 821, it was
clearly possible for a mail system to be 821-conforming without
being 822-conforming. Under 2821, the rules are different, but
the MTA is not supposed to be acting in a police function.
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)
Yes, or to bounce the broken message, which is what it is
supposed to do if it can't figure out, with considerable
authority, what should be in those fields. It is doubtful that
Sender should be generated, and the MSA is forbidden to generate
Return-path unless it is somehow also the MDA (final delivery
MTA).
This should conform with RFC 821/822 and RFC 2821/2822 as well.
Yes
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.
It does not require reordering. It may require insertion below
the trace fields, or may not.
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?
In an MTA, do not tamper with headers, other than adding trace
fields, without explicit sender authorization. If you must
tamper with the headers, do so as little as possible.
Is this on topic, important? a non-issue?
Mostly a non-issue, I think.
john