[bug-mailutils] Re: 7bit transfer encoding

[Simon Josefsson]

Sergey Poznyakoff <address@hidden> writes:

>> I found the code in attachment.c, line 468.
>> "Content-Type: message/rfc822\nContent-Transfer-Encoding: 7bit\n\n";
>> 
>> It seems unreasonable to hardcode "7bit" to content transfer encoding.
>> It may prevent mail client from displaying 2-byte characters correctly.
>
> Well, I'm not quite sure. The valid RFC 822 message cannot contain the
> 8-bit ascii characters anyway, so that's hardly any use setting another
> encoding.
>
> Opinions?

The MIME type doesn't necessarily denote strict RFC 822 conforming
messages, so it could contain non-ASCII characters.  I'm not familiar
with the API to tell whether this is really a problem, but generally
speaking it may be.

5.2.1.  RFC822 Subtype

   A media type of "message/rfc822" indicates that the body contains an
   encapsulated message, with the syntax of an RFC 822 message.
   However, unlike top-level RFC 822 messages, the restriction that each
   "message/rfc822" body must include a "From", "Date", and at least one
   destination header is removed and replaced with the requirement that
   at least one of "From", "Subject", or "Date" must be present.

   It should be noted that, despite the use of the numbers "822", a
   "message/rfc822" entity isn't restricted to material in strict
   conformance to RFC822, nor are the semantics of "message/rfc822"
   objects restricted to the semantics defined in RFC822. More
   specifically, a "message/rfc822" message could well be a News article
   or a MIME message.

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.  The message header fields are
   always US-ASCII in any case, and data within the body can still be
   encoded, in which case the Content-Transfer-Encoding header field in
   the encapsulated message will reflect this.  Non-US-ASCII text in the
   headers of an encapsulated message can be specified using the
   mechanisms described in RFC 2047.