It might be appropriate for the field name to start with List-*, at
least for those cases where the archive is associated with a list.
That
way, it's easier to separate fields added by a list from fields
supplied
by the sender.
Good point. But it is not really restricted to lists. There are
other potential applications, which are not related to mailing lists.
So starting with List-* would be confusing.
Maybe it should only start with List- when added by a list. But it
seems like we're finding more and more cases where it's a bad idea to
have a header field without very clear rules on who is allowed to set
that field. We've seen this with Reply-To and Sender and also with
Carl Malamud's Solicitation field proposal.
I'd also recommend that the link point to an archived copy of the
message in original form, rather than, say, one that is translated to
HTML. Translating to HTML causes a loss of information and
potentially
a loss of functionality. You should be able to reply to an archived
message, refile it into a folder, follow threads, etc., but those
things are harder to do if the message is no longer in its original
format.
I have added some text about different formats, along the lines
suggested by Graham. I think functions such as being able to reply,...
would be great. Actually, our archives have such a function;
look for "Mail actions: [ respond to this message ]". The functionality
is limited to what can be done with the 'mailto' URI, and only
preserves some headers, and not the body. If you have ideas on
how to implement improvements, that would be great.
There are limits on what you can do with HTML and HTTP. Being able to
access the archived message from IMAP is potentially a lot better, but
(as with many things) even IMAP needs some tweaking to make it work
well for this.