ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
In the particular case I mentioned the messages my MUA sees are
entirely normal. They are packaged up as part of the submission
process and unpackaged as part of the delivery process.
So my original statement is entirely true (nb the "tool" part):
| I have to send a message to myself (or save it to the Drafts folder)
| and then forward the resulting message, which destroys secondary
| context such as threading, unless of course I have a tool that does
| all of this on my behalf. Even then, somebody can take the embedded
| message out of its context and all of the intended features and
| benefits will be lost.
We are left to disagree on the practicality of having external monitoring
agents which encode and decode such messages on our behalf, according to
some heurestic, rather than having this occur within the scope of the MUA
itself. Personally I consider decoupling the transfer headers from the
message headers as the more appropriate long-term objective for multiple
reasons (obviously), not the least of which is the ability to have the
MUAs do this stuff.
A more interesting question is how to merge Received: field
information in such a setup.
Transfer headers are naturally related to the envelope ("here are the
delivery instructions"; "here is how I complied with the instructions"),
and are not naturally related to the contents of the message.
The undiscussed secondary point here is that MUAs should also get the
envelopes (along with the messages), rather than having delivery agents
discard the envelope as is the current practice. See RFC 2298, which
requires MDAs to convert ORCPT parameter values to Original-Recipient
header fields for the MUA's benefit as an example of where this separation
between the envelope and message content is not currently preserved, and
how MUAs would benefit from having the envelope.
But more generally, if a desire for increased security warrants pushing
encryption further towards the user, a tension necessarily develops
between the need to keep things hidden and the need to expose things
for indexing and other similar activities not directly associated with
the handling of a message in isolation. Unfortunately, this tension is
fundamental and chosing different syntaxes for things doesn't change
it significantly.
Agree that there is a natural conflict here. The basic information in an
envelope tells hostile parties a lot: "Joe sent Fred a mesage at 9:02pm
from his home computer" is a lot of information if you have other
contextual data. There has to be a point where the underlying network
security takes over, obviously. But today the line exists at a point where
you not only know that Joe sent a message, but you also get to see the
Subject of the message, the References threading details, and a bunch of
other information that is much more useful than the envelope alone. The
difference between these lines is the difference between pen registers and
annotated summaries.
Virus scanning signed or encrypted packages is problematic, for
instance.
Those are still available, but at the recipient's system instead of at the
gateway. Certainly this remains as a valid concern however.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/