ietf-smtp
[Top] [All Lists]

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

2005-09-08 09:56:35

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.

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.

Tony.
-- 
f.a.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.