Re: Re(2): The subject line leakage problem

[ned.freed@xxxxxxxxxxx]

> > 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