Steve,
Thanks for the list of reasons. The idea that the sender might not
want to disclose the local alias is a useful observation; I agree it's
important for the user to know what's going into his message and for
the mail system to be as useful as possible in this regard.
- Some header fields are changed as part of submission
processing and they would not be accessible to mail software if they
are inside the boundary. So, for example, local email and mailing
list aliases would be unchanged and these are at best useless, if not
misleading to a receiver. One could even argue that these local
aliases might be something that the sender would not, as a matter of
course, want disclosed to recipients.
- One can, in principle, move any type of data via PEM. If
message header fields were a mandatory part of the enclosed data this
would make PEM more 1822-specific, potentially less general. Note
that one can optionally duplicate header fields in PEM, but there is
not requirement to do so. Perhaps the shortcoming you are citing is
that there is not a standard way to identify them if they are
included.
Yes, it's the lack of a standard way to do this that bothers me. That
is, even if the user's mail agent is set up to include the headers
inside the boundary, there isn't any way for the receiver's mail agent
to take this into account.
- The ability to implement PEM as a filter would be degraded
if there there was a requirement to include message header info, since
that info might not be available at the time the filter is applied.
I think if there were a well defined place for the header, filters
would add/remove the header without trouble. The only reason for
trouble is if there is confusion about whether the header will or
won't exist.
- There was a concern that the inclusion of header info within
the protection boundary would lend credence to its authenticity,
whereas there are no guarantees of such. For example, any sender ID
within the boundary is under the control of the sender and thus not to
be trusted. An indication of other recipients in the CC field could
be misleading, i.e., there is no indication that the messsage was
actually sent to anyone else. The DATE field is similarly under the
sender's control and generally may not represent a useful value for
non-repudiation purposes.
This is an interesting list of potential pitfalls. It's complementary
to the list of issues under the present regime. At present, the
Subject and To lines arrive only on the outer envelope. If they were
included in the inner envelope, the receiver would know these were
what the sender wanted him to see.
As a general proposition, the validity of *all* of the information
inside the boundary is dependent on the sender. In order to ensure
reliability of, say, the date, it would be necessary to have some
other agent insert the information under seal and signature.
I agree there are possible pitfalls if headers are included, but my
sense of things at this time is we erred onthe wrong side.
Steve