The subject line issue is not a problem in the X.400 world. SMTP carries
the subject line is in the envelope.
On the contrary, in SMTP the subject field is part of the content, not part
of the envelope. Specifically, it is part of the message header.
The corresponding X.400 protocols
(P1, P3, and P7) do not. In X.400, the subject line is part of the content.
This part is correct, but it fails to get at the reason why X.400 and SMTP
differ in their ability to protect the entire content of a message end to
end.
The real reason the two differ is that X.400, unlike SMTP, in theory supports
the transmission of completely different forms of messages. Because of this you
can define, say, a new type of message for EDI. Or voice mail. These things are
called content types in X.400 parlance (not to be confused with a MIME content
type, which is a different thing). Any new content type can carry other content
within it, so a new content type can be nothing but a security enclosure with
the actual content nested inside. Several such security enclosures have been
defined, making it possible to secure X.400 as a whole just underneath the
envelope.
Now, in theory X.400 MTAs only deal with the envelope and are able to pass
arbitrary content types around, making it possible to introduce new ones at any
time. Howevr, I've found that sometimes this works in practice and often it
doesn't. Support for this in real world X.400 implementations is far from
uniform. At least part of the reason why this is so is because this capability
is rarely used, and rarely used capabilities are bound to have bugs, especially
given that most X.400 implementations are rarely updated these days.
SMTP doesn't have this ability to carry arbitrary sorts of messages around.
However, it isn't because it is impossible to add to SMTP or adding it hasn't
been considered. It is possible and it has been considered. The problem is that
it would mean upgrading every SMTP server out there to support it, and this was
and is not considered to be a viable thing to do. Because of this we instead
choose to use MIME facilities to define a security enclosure for SMTP. These
can be used to protect the subject and so forth, but it isn't as clean as the
X.400 scheme. It does, however, interoperate with existing SMTP servers, which
was and is a huge win.
X.400 does have similar issues with TO, CC, and FROM. Both SMTP and X.400
would like to integrity protect these.
If you're talking about header fields, then the issues for X.400 and SMTP
protection of this information are the same as for subject lines. If, on the
other hand, you're talking about envelope information, then yes, this is a
problem. There are various solutions in this space, but short of deploying a
public key infrastructure that every MTA can use to verify signed recipient
information, there is no real way to completely address the problem.
There are, however, things you can do in SMTP. One of them is to secure
a batch SMTP session (RFC 2442). There are a number of email systems
that support this approach. I suppose something similar is possible in
X.400 (a P1 content type?), but AFAIK nobody has ever defined such a thing.
Ned