在接收服务器评估所有消息身份验证之前，可能会发生消息大小拒绝。它也可能在上游服务器接受消息并且后面的跃点应用较小的限制后出现。诊断剔除啤酒花时的尺寸状况，而不是将每个永久性剔除视为一次 SPF, DKIM 或者 DMARC 缺点。
区分策略和存储的大小
RFC 3463将 X.3.4 定义为对于接收系统来说太大的消息，将 X.2.3 定义为超过邮箱管理限制的消息长度。这些与 X.2.2 邮箱已满不同。请阅读完整的诊断信息，因为产品可能会添加自己的限制、单位和解释性措辞。单独的通用“552”标签并不能建立确切的配置限制。 RFC 3463第 3.3 和 3.4 节.
身份验证失败涉及身份、签名或策略，而不是消息八位位组的数量。减小大小不是DKIM修复；更改签名内容本身会使签名失效，因此授权替换必须通过正常的签名工作流程。相反，在SPF中授权另一个 IP 不会增加收件人允许的邮件大小。除非独立证据表明两项调查均失败，否则将两项调查分开。
正确阅读广告中的 SIZE 功能
SMTP SIZE 扩展允许服务器在其内通告支持和可选的最大邮件大小。 EHLO 回复。支持客户可以提供估计的尺寸 邮件来自，在传输整个消息之前允许拒绝。不带数字的 SIZE 不传达固定最大信息； SIZE 0 明确表示没有固定的最大值。两者均不保证接受。后续处理和其他跃点仍然会施加限制。 RFC 1870第 3 节和第 4 节.
对于RFC 1870 SIZE，计算消息八位字节，包括 CRLF 行结尾、标头、 MIME结构和编码内容，但排除 DATA 终止点和额外的点填充字节。不要只计算附件文件。 Base64 编码扩展了二进制数据，换行符和周围的消息部分添加了更多字节。看 RFC 2045第 6.8 节。提供商界面可能会以不同方式显示舍入单位。记录测量的八位位组和确切的广告或记录的限制，而不是比较两个未解释的“MB”标签。
比较受控变体
创建两个仅在尺寸相关内容上有所不同的授权变体。保留每个结果的较小和较大的序列化大小以及SMTP阶段。说明性对可以包含相同的简短说明文本，并用批准的访问控制文件链接替换大附件。请勿假设文件链接适合机密材料或收件人有权访问。
RFC 5321第4.5.3.1 .7 节要求支持至少 64K 八位位组的消息大小，包括标头。以下 100,000 个八位字节限制高于协议最小值，不是建议的提供商设置。
对于假设的算术检查，假设同一端点通告 SIZE 100000。假设的 115,900 八位字节消息超出了该限制 15,900 八位字节；假定的 20,100 个八位位组替换比它低 79,900 个八位位组。第一个可以在 MAIL FROM 处拒绝；第二个有资格进行进一步处理，但不保证被接受。这些数字是发明出来的，而不是测量结果或执行的SMTP结果。他们没有描述任何提供商的附件上限。
修复最窄的相关约束
询问拒绝系统的所有者，该大小是有意的服务限制还是组织控制的设置。如果业务需求可以通过较小的文件来满足，请使用该路由，而不是提高整个邮件系统的限制。如果授权限制更改，请在应用之前考虑资源消耗、恶意软件扫描和下游兼容性。
不要继续重试相同的永久拒绝的内容不变。确认原件未被其他跃点或其他收件人接受，然后提交已批准的替换件，并与之前的尝试有明确的关系。保留自己的消息和队列标识符。一条新消息就是一个新的传递事件，即使用户将其视为同一个附件。
关闭测量的邮件大小、确定的拒绝限制和纠正尝试的结果。将收件箱放置和收件人对链接内容的访问权限保留为单独的检查。
将限制与解决方法分开
- 测量：使用 SIZE 定义计算完整的序列化消息，而不仅仅是附件。
- 定位：捕获拒绝跳跃、命令阶段、诊断和适用限制。
- 修复：选择经批准的较小消息或访问控制的传递方法。
- 复核：记录替换尺寸和每个收件人的结果；不要假设每个下游限制都匹配。
- 关闭：确认收件人访问与SMTP接受分开。