On Mon May 23 2005 14:44, John Leslie wrote:
Bruce Lilly <blilly(_at_)erols(_dot_)com> wrote:
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:
N.B. "generally" != "always and unconditionally"
thus giving a limited sense
of order -- the first "Received" header is essentially known
No. Not "known", "assumed". And we all know what happens when one assumes.
to have
been added by the last MTA before you.
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.
No, the functionality is not limited to SMTP, as acknowledged in section 3.8.2
of RFC 2821: "As another consequence of trace fields arising in non-SMTP
environments, [...]".
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.
I find "Unless it has negotiated other arrangements" vague and open-ended.
Were we starting from scratch [...]
Well, John's draft expired in July 2004, so we might as well, as it
appears that the idea lacked traction.
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.)
Believe it or not, there is a reason that components are separated into
"envelope", "header", and "body", and why the application is called
"electronic mail" and not "electronic foo". The header and body are
part of user-to-user communication (as with non-electronic mail) and the
envelope is where various markings pertaining to transport, filing, etc.
of unopened messages are placed.
I believe there's rough consensus that a MailingList "re-inserts"
messages,
To the extent that any other part of the store-and-forward transport
process also does so. The message (as indicated by invariant message
identifier) is the same message (RFC 2822 section 3.6.4).
and that List-* fields are meaningful for list management --
at both the sending and receiving end.
Yes, in the same way that routing or filing instructions, postmarks,
etc. are meaningful on physical mail envelopes.
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.
As you say, "were we starting from scratch". The existing system provides
no such guarantee.