mail-ng
[Top] [All Lists]

Re: Transport Protocol vs. Message Format

2004-02-26 17:38:07
Martin Duerst wrote:

See e.g.
http://lists.w3.org/Archives/Public/public-ietf-w3c/2004Feb/0000.html
for an example (look for "Respond" at the top, and please try this out,
but stop short before actually hitting the SEND button). We include
Subject, In-Reply-To, and References headers, but no other headers,
and no body (which you would have to copy, but that's not that a big
deal).

First attempt (from corporate work computer) failed; Symantec Web
Security denied access for "Reason: Found in Denied List (Sex/Acts).
Entry causing block is lists.w3.org".

I can access it from my laptop, but I have a couple of comments:
1. security/privacy -- the mailto link indeed opens my MUA ready for
   message composition.  You say In-Reply-To and References header
   fields are initialized, but my MUA (in composition mode) doesn't
   show me those. I have no easy way to verify exactly what is
   initialized (I can see the mailto URI in my browser, but it's so
   long that I can't see all of it).  How do I know it doesn't
   include something that I don't want included? [rhetorical
   question]  I can trust my MUA when it's replying to a message,
   but when it gets input from a mailto link I seem to be at the
   mercy of the link author.
2. unfortunately (or maybe fortunately, in light of the above) not
   all mailing list archive web sites have such a feature. The
   mail-ng archive doesn't, for example.
3. privacy revisited: note that the mail-ng archive obfuscates
   domain names for display (xxxxxxxx) and in mailto links
   (DOMAIN.HIDDEN).  The w3c site does neither.  Obviously there's
   a tradeoff between functionality and privacy, and different
   sites have different policies.

For practical reasons, you could do both
content negotiation as well as have a link on the HTML page to
a specific URI for the message/rfc822 format.

Another security issue: with HTML generated by processing a
message, I have to trust the author of the processing software
as well as the operator of the web site that the HTML is an
accurate representation of the message.  With message/rfc822,
assuming the message hasn't been munged, I can validate the
message if it's signed -- I can't do that with HTML even if
the original message has been signed; the conversion to HTML
will have invalidated the signature.  So availability of
message/rfc822 would help (but I note that that option doesn't
seem to be available from the W3C archive referenced above).

for many purposes (in particular
browsing the archive), HTML usually works much better.

Perhaps. But as far as I can tell, message/rfc822 or equivalent
(e.g. via imap or pop schemes) would be the only one (assuming
the content originated as email) that can be authenticated by
the viewer (assuming he has a way to find the appropriate public
key or certificate for the originator).

Just for kicks, I'm signing this message. The public key should
be available from wwwkeys.pgp.net. [but I wouldn't be surprised
if the list exploder breaks the signature -- I'm fairly certain
that the HTML version appearing in the archive will be unverifiable]

Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>