On Sun, Apr 09, 2023 at 09:35:49AM +0800, tom--- via Postfix-users wrote:
> >> 2. Content-Transfer-Encoding: 7bit
> >
> > The 2nd is more of a property assertion, than an encoding. The
> > MIME-part content is transmitted as-is, but is asserted to consist
> > entirely of 7-bit octets (i.e. still 8-bit octets, but in the range
> > 0–127). Similarly, the "8bit" transfer encoding is also an "identity"
> > encoding, which makes no promise about the high bit of the content.
>
> (1) With testing (sent from roundcube, read from gmail) I found that:
>
> X-Sender: t...@myposts.ovh
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
>
> 两鬓可怜青，只为相思老。
> 无情不似多情苦，一寸还成千万缕。
>
>
> As you see with chinese UTF8 characters the transfer-encoding has been
> set to 8bit.
I am not sure what point you're trying to make...
> So my guess:
>
> (1) in smtp session, both 7bit, 8bit are allowed. for example, UTF-8 use
> 8bit for transfer.
No guessing, or even experiments are required, the MIME specification in
RFC 2045 is 26+ years old.
- When an SMTP server advertises the 8BITMIME ESMTP feature the sending
SMTP client can send 8bit text content without applying a transfer
encoding. This is useful for *line-oriented* text content. Such as
this message, with a bit of gratuituous non-ASCII content thrown in:
Ой у лузі червона калина похилилася,
Чогось наша славна Україна зажурилася.
А ми тую червону калину підіймемо,
А ми нашу славну Україну, гей-гей, розвеселимо!
- However, 8bit transfer encoding is not suitable for raw binary data,
such as image files, because:
o It is not line-oriented. Use of <CRLF> line-endings will corrupt
binary data.
o Conversion to some local text encoding will corrupt binary data.
o ...
For raw binary data SMTP generally uses base64.
> (2) If the content is binary, base64 or QP should be used. in transfer
> process, base64 still uses 7bit.
Quoted printable is for textual content which contains long lines, and
is mostly ASCII. It is not well suited for other binary data.
Read RFCs 2045–2047.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
