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)
如果我删除了额外的设置,我的电子邮件将被收到并正确显示.
我的问题:
Encoding基本需要设置Content-Type: multipart/alternative;,即使是特定情况?编辑
我发现IETF:
编码注意事项:多部分内容类型不能包含编码.
但我也发现Wikipedia:
多部分类型的内容传输编码必须始终是"7比特","8比特"或"二进制",以避免多级解码所带来的复杂性.
这不矛盾吗?
来自IETF和维基百科的声明并不是真的相互矛盾.7bit,8bit或者binary不是真正的内容编码,因为它们没有指定内容的任何转换.他们只是声明内容尚未编码.在7bit它的情况下,它还指定不需要编码内容,即使消息需要通过非8位清除的传输发送.
只有最底层的消息应该有一个实际的Content-Transfer-Encoding,如base64或quoted-printable.在您从外部引用的消息中肯定不是base64编码的,因此声明它不仅违反了标准而且也是不正确的.这肯定会导致显示该消息的问题.
| 归档时间: |
|
| 查看次数: |
4751 次 |
| 最近记录: |