Extmail 未严格遵守 RFC 导致 Claws Mail 看不到邮件内容的问题
实验室的邮件系统最近改用了国产开源邮件服务器——Extmail。我在使用过程中发现一个问题：Claws Mail 客户端收到来自 Extmail web 界面发来的带有附件的邮件，内容均为空白，既无正文也无附件。而使用 Foxmail 等其他客户端接收邮件，则正常。经测试，发现问题出在 Extmail web 界面生成的邮件头中的这一行：
- Content-Transfer-Encoding: base64
如果将这一行删除，则 Claws Mail 可以正确显示邮件正文与附件。那么，这是 Extmail 的问题还是 Claws Mail 的问题呢？既然这一问题只出现含有附件的邮件中，就从实现邮件附件的规范——MIME 的 Multipart Content-Type 入手分析。查阅 RFC 1341 相关章节，其中明确说明了 multipart 类型的 Content-Transfer-Encoding 只允许是 7bit、8bit 或 binary，而具体内容（正文和附件）的 Content-Transfer-Encoding 应在各个 part 的头部声明。因此，Extmail 在邮件头部指定“Content-Transfer-Encoding: base64”是不符合 RFC 的。而 Claws Mail 可能对标准的执行过于严格，容错能力不足，因此不能显示不符合规范的 multipart 邮件的正文和附件。
我又查看了 Foxmail、Coremail 等 X-Mailer 发来的 multipart 邮件，发现多数 X-Mailer 构造的 multipart 邮件在头部都不指定 Content-Transfer-Encoding，只在下面的各个 part 中分别指定 Content-Transfer-Encoding。作为具有缺省值、可以省略的字段，multipart 邮件头部不指定 Content-Transfer-Encoding 应该是符合 RFC 的，这些邮件在 Claws Mail 中解析正确。
因此，这个问题的根源在于 Extmail 未严格遵守 RFC。简单查了一下，构造 multipart 邮件的相关代码位于 libs/Ext/App/Compose.pm 文件，应该比较好修改。不过 Claws Mail 的“死板”也算一个原因，应对中国制造就要学会超强纠错（还记得这个例子吗）。
Update 2012-04-24: 经 Jeoygin 同学提醒，有关 MIME multipart 的更新标准是 RFC 2046。该 RFC 仍限制 Content-Transfer-Encoding 只能是 7bit、8bit 或 binary。另外，Extmail 修改这个 bug 并不是一行代码就能搞掂的，Compose.pm 里面有一些纠结的逻辑有待重构。
1 Trackback(s)