Steve,
There are (were?) a number of reasons for not including
message header fields within the PEM protection boundary, i.e.,
duplicating them within the boundary. I suspect John Linn can do a
better job than I of citing all of them. Nonetheless, let me try to
note several:
- 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.
- 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.
- 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.
Steve