于 2025年04月22日 摘录自 Postfix BDAT (CHUNKING) support。
概述
Postfix SMTP 服务器支持 RFC 3030 CHUNKING（BDAT 命令）而无需 BINARYMIME，适用于 smtpd(8) 和 postscreen(8) 中均支持。该功能默认启用。
本文档涵盖的主题：
禁用 BDAT 支持
BDAT 支持默认启用。要全局禁用 BDAT 支持：
/etc/postfix/main.cf: # 日志记录替代方案： smtpd_discard_ehlo_keywords = chunking # 不记录日志的替代方案： smtpd_discard_ehlo_keywords = chunking, silent-discard
在 smtpd_discard_ehlo_keywords=' 中指定 '-o smtpd_discard_ehlo_keywords'。5.html">master.cf 中，以启用 CHUNKING 支持。
对现有配置的影响
- smtpd_mumble_restrictions、smtpd_proxy_filter、smtpd_milters，或 postscreen 设置，除了上述用于抑制 SMTP 服务器 CHUNKING 服务公告的选项外。
- Postfix 队列文件内容未发生变化，下游 SMTP 服务器或队列后内容过滤器未发生变化，且 Milters 接收的信封或消息内容未发生变化。
示例 SMTP 会话
主要区别在于 Postfix SMTP 服务器在 EHLO 响应中宣布支持"CHUNKING"，并且远程 SMTP 客户端可能发送一个或多个 BDAT 请求，而不是一个 DATA 请求。在下面的示例中，"S:"表示服务器响应，"C:"表示客户端请求（粗体字）。
S: 220 server.example.com C: EHLO client.example.com S: 250-server.example.com S: 250-PIPELINING S: 250-SIZE 153600000 S: 250-VRFY S: 250-ETRN S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250-DSN S: 250-SMTPUTF8 S: 250 CHUNKING C: MAIL FROM:<[email protected]> S: 250 2.1.0 Ok C: RCPT TO:<[email protected]> S: 250 2.1.5 Ok C: BDAT 10000 C: ..随后是 10000 字节... S: 250 2.0.0 成功: 10000 字节 C: BDAT 123 C: ..随后是 123 字节... S: 250 2.0.0 成功: 123 字节 C: BDAT 0 LAST S: 250 2.0.0 成功:10123 字节已排队为 41yYhh41qmznjbD C: QUIT S: 221 2.0.0 再见
在 Postfix 内部，通过 BDAT 或 DATA 接收的邮件没有区别。Postfix 的 smtpd_mumble_restrictions、策略委托查询、smtpd_proxy_filter 以及 Milters 均行为一致，仿佛 Postfix 接收到了 (MAIL + RCPT + DATA + 数据结束标志)。然而，Postfix 会将与 BDAT 相关的失败记录为"xxx after BDAT"(其中 xxx = 'lost connection' 或 'timeout')，以避免故障排除复杂化，并在客户端发送格式错误的 BDAT 命令时记录警告。
CHUNKING (BDAT) 支持的优势（无需 BINARYMIME）
添加对 CHUNKING (BDAT) 的支持是为了提升与部分客户端的互操作性，据报告即使不支持 BINARYMIME，此优势仍存在。自 2018 年 6 月起，Wietse 的邮件服务器已接收来自多种系统的 BDAT 命令。
Postfix 目前不支持 BINARYMIME，原因如下：
- 支持 BINARYMIME 需要对 Postfix 进行较为侵入性的修改，以支持非行导向的邮件内容。在 BINARYMIME 模式下，Content-Length: 消息头指定内容的长度，该内容可能包含或不包含行边界。若不支持 BINARYMIME，邮件 RFC 要求二进制内容必须以 base64 编码，并格式化为文本行。
- 对于发送至不支持 BINARYMIME 的系统(包括 UNIX mbox)，可选方案包括将二进制内容转换为 8 位文本、7 位格式(base64 或 quoted-printable)，或将邮件标记为无法投递。任何转换都会破坏数字签名，因此转换必须在签名之前进行。
分块(BDAT)支持的缺点
RFC 3030 的作者未指定客户端如何管道化命令(即在未等待服务器响应时发送命令)的任何限制。如果服务器宣布支持管道传输(如 Postfix 所做)，则远程 SMTP 客户端可以在 EHLO 之后管道传输所有命令，例如 MAIL/RCPT/BDAT/BDAT/MAIL/RCPT/BDAT，而无需等待服务器响应。这意味着，对于 BDAT，Postfix SMTP 服务器无法根据客户端的命令管道传输行为区分正常客户端与垃圾邮件机器人。如果您需要使用 "reject_unauth_pipelining" 来阻止垃圾邮件机器人，则需按照上述方法关闭 Postfix 的 CHUNKING 公告。
在RFC 4468中，作者指出客户端可能进行命令管道传输，且在发送BURL LAST或BDAT LAST后，客户端必须等待服务器响应。但由于此文本未出现在定义 BDAT 的 RFC 3030 中，因此这是一个无用的限制，Postfix 不会强制执行。