On Mon May 23 2005 10:30, John Leslie wrote:
wayne <wayne(_at_)schlitt(_dot_)net> wrote:
http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
which includes:
[...]
] The Received-SPF header is a trace field (see [RFC2822] section
] 3.6.7) and SHOULD be prepended to existing headers, above the
] Received: header that is generated by the SMTP receiver. It MUST
] appear above any other Received-SPF headers in the message.
This is a very interesting idea, with some promise of enabling a
chain of trust.
Except for a few inconvenient facts:
a) "It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet." RFC 2822, section 3.6
b) it's easy to write "is a trace field", but that won't cause existing
deployed MTAs to treat it any differently from any random extension
field.
We SHOULD discuss on this list whether such a header can be considered
a "trace field";
As none of the SMTP documents define "trace field" (it is defined in
RFCs 822, 2822), the ietf-822 mailing list might be be more appropriate.
and I'd like to suggest that we do so in a context of
what "envelope information" means.
Oy.
IMHO, it has become clear that we wish "envelope information" to
include more than the SMTP commands. (I think John Klensin had the
right general idea in his draft-klensin-email-envelope draft.)
Except (unlike 2821 re. Return-Path) it doesn't say what is supposed to
happen to the stuff at "final" delivery (which often isn't final at all),
and while there is a provision for "downgrading", there isn't one for
"upgrading". Nice try, but a simpler approach would be to wrap the
originating user's content in a MIME message/rfc-822 wrapper and let
the transport mechanism prepend its cruft to that wrapper. An MUA (or
an MDA at "final" delivery) could simply discard the wrapper to get to
the "real" content (which could be signed, encrypted, etc. w/o
interference). No need to "downgrade", no extension required. Existing
MIME UAs show a message/rfc-822 content, non-MIME-UA users just keep
reading to get to the content.
Unfortunately, we currently have vagueness about envelope.
So, my first question to the group is, "Is there anything beyond
SMTP commands and trace headers (however defined) that we want to be
included when we talk of "envelope information"?
Everything that isn't end-to-end, user-to-user communication. Including
List-* fields, the proposed Archived-At, etc. In short, anything roughly
analogous to markings made on the envelope of physical mail.