|
Excellent discussion! Thanks to both hadaso and Scott Kitterman for thoughtful comments. I am not convinced by the technical arguments (see below), but I am seeing a strong preferrence for making a Received line mark the border, regardless of actual chronological sequence. If Scott was confused by my unusual header order, others will be also.
Let's think in terms of what the user sees, and what we might do to amend RFC-2821. We are sacrificing a little simplicity for less deviation from what is expected by people who have seen many Received headers. We might think of a new "canonical form" for "Received blocks", with the Received line always at the bottom of the block.
Rule for users:
Find the topmost X-Authent: line, then the next Received: line below that. Draw a boundary line just below that Received: line. Everything above the boundary can be trusted. Anything below may be forged.
Rule if we follow "strict chronology":
Find the topmost X-Authent: line. That line and everything above it can be trusted. Anything below may be forged.
# proposed amendment to RFC-2821
existing text:
RFC-2821, Sect 4.4 Trace Information
An Internet mail program MUST NOT change a Received: line that was
previously added to the message header. SMTP servers MUST prepend
Received lines to messages; they MUST NOT change the order of
existing lines or insert Received lines in any other location.
add:
If multiple lines are to be prepended, they MUST be kept together
as a block, and there MUST be only one Received: line, which MUST
be the bottommost line in the block. The other prepended lines
MUST be above that, regardless of the chronological order in
which those lines were created.
Suggestions on either the rule or the amendment will be appreciated.
As for the technical arguments, I see some flaws:
Re hadaso's argument:
I would not put much significance on "internal order" of the prepended headers. In our milter, there is no internal order until they are actually created, when the message is being forwarded. Prior to that, the information is kept in variables with names like IP, ID, auth_method, auth_result. The "order of events" in my original post is not exactly what happens internally with regard to the creating of headers.
I'm not familiar with other MTA's, but there is a definite order of events in Sendmail (connect, helo, envfrom, envrcpt,
header, eoh, body, eom). I suppose other MTA's might have minor variations, like processing all incoming headers in one call rather than one line at a time.
Re Scott's argument:
I believe the trust requirements are the same regardless of where we place the X-Authent header. There should be one and only one such header, and any appearance of a second one is either a serious configuration error or an attempt at forgery. Authentication should be done at the incoming Border MTA, never by an MTA on the sender's side. The X-Authent header should always be present, even if it reports only an IP address and None for the sender's Identity.
I can imagine situations with multiple MTA's at the Border, some doing authentication, others not, all going to one downstream processor that looks for an authentication header, but doesn't distinguish between the different Border MTA's. Seems to me this is also in the category of serious configuration error. Maybe you could give an example of where this would be a setup we should support.
We need to think about the details of this example. How does the placement of the X-Authent header make any difference in what the downstream processor needs to do? That processor must have some list of trusted hosts, so it can find the bottommost trusted Received line. It must have some logic to detect a bogus Received line, even if that line lists a trusted host. Having found the correct Received line, it should be trivial to look for an authentication header in the expected position, above or below the Received line.
Sendmail is very flexible. We can do anything we want with the headers.
Again, I appreciate these comments, and I am leaning toward changing the header order, even without a compelling technical reason.
|