however message headers were originally intended for use by the author
or his user agent. a couple of exceptions were made for MTAs
(Received) and delivery agents (Return-Path). now things have gotten
out of hand, and we have everybody and his brother scribbling on the
message, so much that it's hard for the recipient (or his user agent)
to make sense of it.
Very interesting. Incidentally, I had been under the impression that
the exceptions you mention were actally part of the original
intention, ie that the header area was supposed to be a catchall for
anything that isn't body content.
as I understand it, ARPAnet mail grew out of a practice of sending
messages by using FTP to append to a file on the recipient's computer.
the entire message (both header and body) was created by the author,
there were no intermediaries that were aware enough of the message
content to be able to modify the header. SMTP came along and added
Received fields and Return-Path. whether the original practice was
"intention" or just the way it happened to work is not something I can
comment on, since I wasn't there at the time. but I have heard
complaints since at least the mid-1980s that there was too little
separation between envelope and transport in Internet mail , even
though Received and Return-Path were the only layering violations in
the design. for various reasons, the situation is much worse now than
it was then.
what we need IMHO is something akin to an annotation facility in IMAP
and/or POP, that stores the annotations separately from the actual
message.
A few thoughts (or one single thought anyway) which come to mind:
Such an external facility won't make the annotations readily
transferable, or rather it leaves the door wide open for ad-hoc
transfer mechanisms. Full messages are easily transferred by
copying.
it depends on what you mean by transferable. surely a mail client
could use IMAP to move a message+annotations from one server to another
(as long as both source and destination servers supported that
feature), or from one folder to another.
OTOH, it's not at all clear that annotations should be forwarded along
with a forwarded message. certainly there are cases where this is not
appropriate. IMHO if you want to forward your annotations along with a
message, you should forward the annotations as a separate MIME body
part, along with the message/rfc822 body part of the forwarded message.
and you should probably have the opportunity to edit those annotations
before you forward the message. because while you might want to be
able to expose (some of) your annotations to a recipient, your
annotations should not become the recipient's annotations.
Whether in fact annotations should be transferable in sync
with a message is a separate question perhaps worth debating?
it makes sense to discuss what behavior would be desirable.