多部分/替代内容类型需要内容传输编码吗?

old*_*god 2 email postfix-mta smtp content-type sendmail

我有一个发送电子邮件的应用程序,并且好几个月,它运行正常.我最近遇到了utf-8发送到iPhone的编码电子邮件的问题Exchange account(即没有IMAP).
所有的接收者都必须看到一大堆毫无意义的人物LS0tLS0tPV9QYXJ0XzE0N18[....].

将我的电子邮件标题与Gmail进行比较后,我注意到我有一个额外的Content-Transfer-Encoding关联Content-Type: multipart/alternative;.
我的电子邮件看起来像

Delivered-To: ...
Received: ...
...
MIME-Version: ...
Content-Type: multipart/alternative; 
    boundary="----=_boundary" 
Content-Transfer-Encoding: Base64  # <= the extra setting

----=_boundary
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: Base64

YmVu0Cg==

----=_boundary
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: Base64

PGh0bWwgeG1sbnM6bz0iIj48aGVhZD48dGl0bGU+PC90aXRsZT48L2hlYWQ+PGJvZHk+YmVub2l0
PC9ib2R5PjwvaHRtbD4NCjx9IjAiIC8+Cg==

----=_boundary
Run Code Online (Sandbox Code Playgroud)

如果我删除了额外的设置,我的电子邮件将被收到并正确显示.

我的问题:

  1. 是否Encoding基本需要设置Content-Type: multipart/alternative;,即使是特定情况?
  2. 删除它是否安全,并像以前一样继续使用我的应用程序?

编辑 我发现IETF:

编码注意事项:多部分内容类型不能包含编码.

但我也发现Wikipedia:

多部分类型的内容传输编码必须始终是"7比特","8比特"或"二进制",以避免多级解码所带来的复杂性.

这不矛盾吗?

qqx*_*qqx 6

来自IETF和维基百科的声明并不是真的相互矛盾.7bit,8bit或者binary不是真正的内容编码,因为它们没有指定内容的任何转换.他们只是声明内容尚未编码.在7bit它的情况下,它还指定不需要编码内容,即使消息需要通过非8位清除的传输发送.

只有最底层的消息应该有一个实际的Content-Transfer-Encoding,如base64quoted-printable.在您从外部引用的消息中肯定不是base64编码的,因此声明它不仅违反了标准而且也是不正确的.这肯定会导致显示该消息的问题.


tri*_*eee 5

实际上,multipart的每个部分都有自己的编码,为multipart容器声明一个没有意义.无论如何,我无法理解维基百科的报价; 无论如何,它几乎不具有权威性.