SCO going after BSD???

[Terry Lambert]

Gregory Sutter wrote:
>   Content-Type: text/plain; charset=iso-8859-1
>   Content-Disposition: inline
> 
> These headers show that the part is not an attachment but should be
> displayed inline, and that it contains pure text that doesn't need a
> special handler to be displayed.  Why Outlook Express fails to
> recognize this, and why Microsoft fails to issue a patch to fix the
> problem, is unknown.

Most mail worm implmentations uses an inline disposition to force
the activation of an exploitable helper program to interpret content
when the message is opened.

Yes, they should recognize that text/plain is not an exploitable
type unless there is a registered external "helper" for that type
that overrides internal rendering as plain text (e.g. "Word"),
even though text/html is, bt at least they are attempting to prevent
exploits these days.

FWIW, most mail programs don't recognize multipart/*, and will only
render in the case of multipart/mixed or multipart/message messages.

Also, for a signed message, there is no reason to put the text part
in a separate container object, unless your mail program is stupid,
since there is still a global RFC-822 message body that pertains
following the <cr><lf><cr><lf> at the end of the last header line,
and prior to the declared "boundary=" from the RFC-822 header's
"Content-Type:" header line.  In other words, a content type part
of "text/plain", even on a "multipart/mixed" is unnecessary extra
encapsulation, and just makes the mail a PITA to read because you
can't trust attachments, and stupid programrs should stop doing
MIME encapsulation unnecessarily, just because it's easier, or
because they've figured out how, or because they're too lazy to
deal with the text part being at a higher point in the hierarch than
the signature part, or because they're using limited capability
class libraries to implement their MIME.

-- Terry