作为接收 SMTP 服务器，设置最大邮件大小是有意义的。收到大邮件后会占用大量空间。磁盘已满会让用户不满意。
规定每个发件人在固定时间段内发送的最大邮件数量是有意义的，尤其是与其他垃圾邮件指标相结合时。垃圾邮件也会让用户不高兴。
我目前正在通过 SMTP 中继发送邮件，但它的限制与上述两种方式都不同：最大会话大小。它不受可接受邮件数量或邮件大小的限制。
一系列 1000 条消息（每条消息有几百 KB）只有在 TCP 连接关闭并在中途重新打开时才会通过。如果这些消息全部在一个 TCP 连接中发送，则会发生以下情况：
552 4.3.1 Session size exceeds fixed maximum session size
（有相关问题提到了相同的错误消息，但它只触及了问题的边缘；我的问题是关于政策决策，而不是关于在特定限制内需要进行什么精确的计算。）
从发送者的角度来看，这是一个很大的麻烦。它迫使你拆分发送批次以适应限制，而你直到遇到它才知道。
从接收者的角度来看，这有什么好处呢？发送者没有已预防发送太多消息或太大的消息。发送适量的中型消息只会带来不便。用户永远不可能知道使用一个 TCP 连接或多个 TCP 连接。
所以，主要问题：当实现者发明会话大小限制的概念时，他们脑子里在想什么？服务器管理员启用它的理由又是什么？
你可以在这里停止阅读，忽略其余部分，并解决主要问题
到目前为止，我还没有点名，因为我真的想在这里解释一下基本思想，而不是一些巧妙的客户端解决方法。现在我将添加详细信息...
这里的服务器和客户端由同一个组织控制。我运行（部分）客户端，它们是 Adobe ColdFusion Web 应用程序。我能从那一端影响 SMTP 会话大小的唯一方法是完全禁用连接重用。因此，我可以为每个连接发送一条消息，但这样我就会建立大量的连接，这可能会遇到其他限制（甚至是更合理的限制）。
该服务器是 IIS（不是 Exchange，后者在另一个问题中提到过）。它是这样标识自己的：
220 sendmail.example Microsoft ESMTP MAIL Service, Version: 7.5.7601.17514 ready at Wed, 1 Feb 2017 14:38:49 -0500
这个问题比你从错误消息中猜想的更烦人，因为 IIS 发送 552 响应并关闭连接立即地当达到字节限制时，而不是等待对话中轮到服务器说话的某个时刻。在发送消息的过程中被打断，ColdFusion 以最愚蠢的方式做出响应：它将消息记录为已成功发送。（我计划对此单独提交错误报告。）
消息随机消失根据它们在 TCP 流中的位置，我知道发生了什么的唯一原因是我最终用 Wireshark 捕获了它。
我想请求 SMTP 服务器管理员取消会话大小限制，因为它毫无用处，而且会触发一个严重的错误，导致邮件丢失。因此次要问题：在 IIS 中是否可以删除会话大小限制而不删除消息大小限制？据我所知，这两个限制目前具有相同的值。
答案1
从我从微软看到的一些小信息来看，见下面的引用，我认为这是为了防止当邮件客户端在会话中发送邮件时出现循环，邮件在会话期间被拒绝，然后邮件客户端重试发送。（从而形成循环）
选中“将会话大小限制为 (KB)”复选框，然后键入一个值来指示给定连接中所有消息的最大总大小（以 KB 为单位）。此数字将始终大于最大邮件大小，并且应谨慎设置，因为连接邮件传输代理 (MTA) 可能会重复重新提交邮件。默认大小为 10240 KB。此值应大于或等于限制邮件大小为 (KB) 中输入的值。
从我自己的角度来看；
我认为该限制有一个用途，例如，我开始通过电子邮件“宣传”销售一些伟哥，我可以在我的 IP 被列入公共 RBL 列表之前，针对邮件服务器并在一次会话中发送大量“宣传”，就像 Exchange 检查初始远程连接一样。（参考）
IP 阻止列表提供程序是 Exchange 中连接筛选功能的一部分。在计算机上启用 IP 阻止列表提供程序功能后，连接筛选器代理将查询指定的 IP 阻止列表提供程序服务，以确定要发送邮件的服务器是否已发起该连接是已知发送垃圾邮件的主机。
还请记住，如果您的服务器通过智能主机发送，例如您的 ISP smtp 服务器，ISP 通常会使用 RBL 列表扫描传出的电子邮件，以确保在其客户感染垃圾邮件机器人时限制其客户对互联网的影响。
我提出这一点，你可以搜索电子邮件限制，因为如果你在短时间内向许多大型服务发送过多电子邮件，它们会降低你的 IP 信誉分数。
附带说明一下，有一个有趣的问题有关发送大量电子邮件的网络服务。