From: Bruce Lilly (blilly@erols.com)
Date: Tue Feb 03 2004 - 06:31:58 CST
Russ Allbery wrote:
> J B Moreno <planb@newsreaders.com> writes:
>
>>His message
>>==
>>Content-Type: multipart/mixed;
>>==
>>and then further down
>>==
>>Content-Disposition: inline;
>> filename*=ISO-8859-1'en-us'Re%3A%208.6
>>==
>
>
>>Looks like an included file to me.
>
>
> Yes, it had an included file.
"file" is a nebulous term w.r.t. a multipart message. It's just a
message, with well-defined parts. The optional "filename" parameter
is included for UAs that wish to save a part *as* a file, but the
inline MIME part cannot be said to *be* a file in any meaningful sense.
>>He forwarded a message as an attachment -- and an attachment is an
>>attachment, whether it's a rfc 822 message with a copy of the Lord of
>>the Rings body, or an MPG of the Lord of the Rings, it's still an
>>attachment.
>
>
> Yes, it's an attachment. So what? Do you think there's something wrong
> with attachments?
Actually, no. There is a difference between
Content-Disposition: inline
and
Content-Disposition: attachment
and the part in question was clearly inline, not attachment.
> You said it was a binary. It wasn't a binary.
J.B. somehow seems to have missed, or in any event failed to include, the
relevant MIME-part header lines:
Content-Type: message/rfc822;
name*=ISO-8859-1'en-us'Re%3A%208.6
Content-Transfer-Encoding: 7bit
which clearly indicate that that MIME part is a text message and is 7bit
(not 8bit, not binary, and not encoded).
All of which is completely unrelated to the Subject field body content,
including whether or not that content begins with "Re: ".