Bruce Lilly <blilly(_at_)erols(_dot_)com> wrote:
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
[...]
] 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
Trace headers are generally prepended: thus giving a limited sense
of order -- the first "Received" header is essentially known to have
been added by the last MTA before you. (I agree, BTW, that a "Received-SPF"
header appearing first in the mish-mash of non-trace headers says nothing
dependable about when it was added.)
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.
I agree completely. (Which is what makes John Klensin's idea attractive.)
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.
I don't agree. We're talking about a SMTP transport function. If we
can't agree what we mean here, it seems pointles to take it to ietf-822.
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),
Except for semantic quibbles, I believe the draft does.
and while there is a provision for "downgrading", there isn't one for
"upgrading".
I agree with John Klensin that "upgrading" would be unwise.
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.
Were we starting from scratch, I'd have to agree.
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).
'Twould be a better design, were we starting from scratch...
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.
That definition is facile, but I don't find it useful. (You prove
my point about vagueness, BTW.)
Including List-* fields, the proposed Archived-At, etc.
I believe there's rough consensus that a MailingList "re-inserts"
messages, and that List-* fields are meaningful for list management --
at both the sending and receiving end.
In short, anything roughly analogous to markings made on the envelope
of physical mail.
... which are, in fact, much more limited than we're talking about
here -- and also include all the "bounce" information that we've long
since agreed to treat as a completely separate message.
I believe we need to talk about SMTP-as-we-know-it, not SMTP-NG.
I further believe that most of us mean one-way-transport information
when we talk about "envelope information".
And I further believe that any such information would be more useful
if it were prepended than if it were interspersed in the swamp of
headers.
Anyone else want to comment?
--
John Leslie <john(_at_)jlc(_dot_)net>