From owner-freebsd-chat@FreeBSD.ORG Thu Nov 20 05:17:12 2003 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD6916A4D2; Thu, 20 Nov 2003 05:17:12 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1E1943F85; Thu, 20 Nov 2003 05:17:11 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfikl.dialup.mindspring.com ([165.247.202.149] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AMogG-00072I-00; Thu, 20 Nov 2003 05:17:09 -0800 Message-ID: <3FBCBDF9.A9F9EB66@mindspring.com> Date: Thu, 20 Nov 2003 05:13:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Sutter References: <20031120005218.GA76590@xor.obsecurity.org> <20031120013831.GT98272@klapaucius.zer0.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a429a5dfd8b590227ff4402f05b86b0f6293caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: SWIT cc: chat@FreeBSD.org cc: freebsd-questions@freebsd.org Subject: Re: SCO going after BSD??? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2003 13:17:13 -0000 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 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