[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-mailutils] Re: 7bit transfer encoding
From: |
Simon Josefsson |
Subject: |
[bug-mailutils] Re: 7bit transfer encoding |
Date: |
Fri, 25 Apr 2003 19:47:38 +0200 |
User-agent: |
Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) |
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.