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.
I don't know what X.400 systems you are basing the above comment on. I've
been involved with interoperability testing STANAG 4406 PCT (just CMS really),
and we have not seen a single problem with an X.400 MTA being unable to relay
the new content type.
Well, maybe things have improved. It has been some time since I wrote the
support for this in PMDF-X400 and I no longer recall the specifics, but I don't
believe I was ever successful in getting this to work with another MTA. I
would have tried MAILbus 400 at a minimum and probably Exchange; the
exact timing of the work would have determined which of the several dozen
other MTAs were available for testing at the time.
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.
The X.400 standard defines a double-envelope content-type precisely to allow
protection of the envelope where required.
Interesting. I don't recall that being possible. There is a way to nest
messages, but I didn't believe the support for included envelope information
was sufficient for it to be used for this.
Ned