[Top] [All Lists]

Re: trace header fields, was Re: Classifying gateways in 2821/ 2821bis

2005-09-08 11:55:33

--On Thursday, 08 September, 2005 17:45 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:

On Thu, 8 Sep 2005, John C Klensin wrote:

If we were to go down this path, would it be time to actually
revise the email model to provide a clean envelope/header
distinction, as outlined in the long-expired
draft-klensin-email-envelope-00?   I actually don't think so,
but maybe the point is that this is not the first time we have
started exploring those issues.

I think that draft-klensin-email-envelope-00 goes too far:
it's too late to impose a strong formal separation between
transport and user fields because of the other email protocols
(IMAP, POP) that assume they are muddled together, and the
enormous inertia in the deployed software. The advantages of
making the change are not large enough, especially if the
distinction is downgraded out of existence when messages leave
the SMTP world on final delivery.

I agree.  As I think that draft says (I haven't looked at it
since it was written), it was constructed partially to
demonstrate that we could do if if we were motivated enough.  I
question the motivation for the same reasons you do.

However a softer split, along the lines of 2822 but
extensible, would be compatible with other protocols and with
software that examines the header. (Existing software that
appends to the header tends to do so at its end so is less
likely to be compatible.) It might even be as simple as saying
that MTAs MAY add header fields other than Received: to the
start of the message, and extending the reordering restriction
so that everything before the textually-last Received: field
MUST NOT be re-ordered. That is, the trace part of the header
can contain more than just Received: and Resent-*. This
message's header contains an example of such extended trace
fields, including X-Cam-* fields from my AV scanner and a
configuration oddity on the mailing list server.

In fact, I'm inclined to think that everything that adds
header fields at an intermediate hop (including resending
MUAs, mailing list exploders, spam and AV scanners, etc.)
should do so at the start of the message data instead of at
the end of the header, so that it's more clear who is
responsible for doing so. It would also make header signing
protocols like DKIM more robust and more conformant with the
message format standard.

That would, of course, foul up some anti-spam arrangements that
assume that any headers intermixed with Received fields are
bogus and/or make subsequent Received lines bogus.

But this is the sort of thing that I don't think is worth
discussing without a specific proposal so, if you feel strongly
enough about it, either write an I-D or suggest to Pete (on
list) how this might be retrofitted into 2822bis without forcing
a reset on it.  I'm sure he would prefer such suggestions in the
form of specific text.