On Sun, 8 Feb 2004 05:35, Hadmut Danisch wrote:
That's why a message _must_ consist of at least three parts:
- a transport header
- a message header
- a message body (or some container like mime)
I agree with you. Here is how I would express the same idea.
First, let me suggest that the term "metadata" is perhaps more format-neutral
than "headers", since "headers" suggests data formatted as a preamble to a
document. According to my musings on the matter, we will need the following
three distinct data bundles.
1. The message itself ("Dear Sir, My daugher tells me..."). This includes
"attachments", and is thus really one or more arbitrary octet streams.
2. Message metadata (subject, date, from, to, etc).
3. Delivery metadata (on which the mail is routed).
We actually have this situation in the existing protocols, but the distinction
between message metadata and delivery metadata is not very clean. The
"received" headers are delivery metadata, as are the parameters to the "MAIL
From:" and "RCPT To:" stages of the SMTP dialogue, and the "return-path"
header, when it's added. In my view, this blending of data bundles is a
mistake that we don't want to repeat in mail-ng.
Another desirable difference in mail-ng would be for all the delivery metadata
to be transported to the MUA. At the moment, only that portion of the
delivery metadata which finds its way into the 822 headers is transported to
the MUA. Much of the routing information has been lost by this point in time,
especially if the message has been forwarded from one address to another in
transit. I see no reason why the complete delivery path information should
not be available to the MUA. (It's not always clear *why* a particular item
has been delivered to you, and having its full routing history can help.)
Regards,
TFBW