Re: Transport Protocol vs. Message Format

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]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAPlkBMC9lBMvxJOkRAsLBAJ9A9FCbEOovMwwbaPiYKPT+Tdhu3ACaAmgW
BNnOv5+6T/sy4T8GO3Cgqco=
=t2s3
-----END PGP SIGNATURE-----