将Content-Transfer-Encoding:base64用于文本和HTML电子邮件会出现任何问题吗?

jkr*_*ill 6 email base64 smtp

我正在研究一个电子邮件项目.由于我不会在这里讨论的原因,对长电子邮件进行带引号可打印的编码在客户的环境中存在问题.

在我们发送的SMTP电子邮件的HTML和文本部分上执行base64编码似乎是一个可行的选择.在测试中,它似乎在几个测试客户端(如Gmail)中运行良好.

但是,我想知道这是否会在不同的电子邮件客户端中出现任何问题.从阅读RFC规范来看,看起来base64是文本部分的兼容编码,但对于我想知道是否存在任何潜在问题需要考虑的文本和HTML部分,这是不常见的.

看似有问题的事情:

  • 也许一些较旧或不太健壮的客户端不希望文本或HTML电子邮件部分中的base64,并且将无法对其进行编码
  • 也许某些电子邮件客户端会根据原始内容进行预览或搜索,因此收件人会看到base64而不是实际内容
  • 或许base64可能会对可传递性/垃圾邮件评分产生负面影响?

有没有人可以分享经验?这似乎是一个很好的解决方案,但我想确保我没有遗漏一些东西.

Jan*_*rát 8

这很难回答 - 是的,quoted-printable更经常地使用它只是因为它浪费了更少的字节,并且因为邮件正文部分的原始文本类似于解码输出.但是,没有任何禁止base64用于文本消息部分的内容.

这几乎是一个悬而未决的问题 - 你永远不能确定某个地方的MUA在没有显示任何东西的情况下不会无可救药地被打破.那里有很多"也许",你说得对 - 但问题是你永远不会知道.如果它会让你睡得更好,以下公司都在我收到的营销垃圾邮件中使用base64编码的HTML:

  • Mellanox公司
  • Alza.cz
  • Aukro.cz
  • 现代物理学报

任何可以显示嵌入图像的MUA都必须包含base64解码器.这是绝对有可能,一个可能MUA明确拒绝使用解码的代码text/plaintext/html,但在这种情况下,你只是拧反正.

作为一个有趣的事实,其中一家公司很乐意在多字节字符内的字节边界处打破UTF-8编码主题,并以单独的编码字(此处为RFC2047术语)对文本的两半进行编码.

  • Base64的开销是恒定的:1.33原始数据的大小.但是QP的开销取决于你的邮件语言(假设utf-8).如果您的所有邮件都是英文(ASCII兼容),QP带来的开销很小.对于非ASCII字符,QP编码数据是原始数据的3倍.如果您的邮件是中文,日文和韩文等东亚语言,Base64比QP更有效. (2认同)