-(defvar mm-8bit-char-regexp "[^\x20-\x7f\r\n\t\x7\x8\xb\xc\x1f]")
-
-(defvar mm-body-charset-encoding-alist
- '((us-ascii . 7bit)
- (iso-8859-1 . quoted-printable)
- (iso-8859-2 . quoted-printable)
- (iso-8859-3 . quoted-printable)
- (iso-8859-4 . quoted-printable)
- (iso-8859-5 . base64)
- (koi8-r . 8bit)
- (iso-8859-7 . quoted-printable)
- (iso-8859-8 . quoted-printable)
- (iso-8859-9 . quoted-printable)
- (iso-2022-jp . base64)
- (iso-2022-kr . base64)
- (gb2312 . base64)
- (cn-gb . base64)
- (cn-gb-2312 . base64)
- (euc-kr . 8bit)
- (iso-2022-jp-2 . base64)
- (iso-2022-int-1 . base64))
+;;
+;; Note that CR is *not* included, as that would allow a non-paired CR
+;; in the body contrary to RFC 2822:
+;;
+;; - CR and LF MUST only occur together as CRLF; they MUST NOT
+;; appear independently in the body.
+
+(defvar mm-7bit-chars "\x20-\x7f\n\t\x7\x8\xb\xc\x1f")
+
+(defcustom mm-body-charset-encoding-alist
+ '((iso-2022-jp . 7bit)
+ (iso-2022-jp-2 . 7bit)
+ ;; We MUST encode UTF-16 because it can contain \0's which is
+ ;; known to break servers.
+ ;; Note: UTF-16 variants are invalid for text parts [RFC 2781],
+ ;; so this can't happen :-/.
+ ;; PPS: Yes, it can happen if the user specifies UTF-16 in the MML
+ ;; markup. - jh.
+ (utf-16 . base64)
+ (utf-16be . base64)
+ (utf-16le . base64))