On 2000-12-05 15:49:53 +0100, Anand Buddhdev wrote:
> So the problem boils down to the MUA not generating full and
> correct MIME headers. In this case, mutt isn't inserting all the
> headers that courier expects (it assumes that the relevant
> information will be infered according to RFC 1847).
Sections 5.2 and 6.1 of RFC 2045 and 4.1.2 of RFC 2046 are pretty
clear on what the defaults are. Additionally, RFC 2046 explicitly
states this in section 5.1:
A body part is an entity and hence is NOT to be interpreted as
actually being an RFC 822 message. To begin with, NO header
fields are actually required in body parts. A body part that
starts with a blank line, therefore, is allowed and is a body
part for which all default values are to be assumed. In such a
case, the absence of a Content-Type header usually indicates that
the corresponding body has a content-type of "text/plain;
charset=US-ASCII".
The "usually" is made more precise a little bit later in section
5.1.1:
If no Content-Type field is present it is assumed to be
"message/rfc822" in a "multipart/digest" and "text/plain"
otherwise.
As a consequence, there is NO, repeat: ABSOLUTELY NO, reason to fill
in these defaults in transit, thereby violating relevant standards.
With respect to Sam's notion of a default Content-Transfer-Encoding
being specified on the top level: I'd _really_ like to see a
reference to one of the relevant specifications which says that a
multipart's "top level CTE" is to be used as a default for subparts.
It seems to me that RFC 2045 clearly says that 7bit is the default,
and nothing else.
--
Thomas Roessler <[EMAIL PROTECTED]>
