长期以来，我们一直遇到我编写的群发邮件组件的问题，并且困难的确切性质，如何衡量它以及如何减轻它仍然难以捉摸。
已经到了这些问题变得至关重要的地步，我需要一些直接的答案，所以我希望这里有人可以提供它们。
基本上，这个群发邮件小部件一次只向邮件列表发送大约 25k 封电子邮件。这是我们更喜欢的消息，因为这意味着每个收件人都会收到一封发给他们个人的邮件，所以我们对这个循环很满意。
我们不满意的是，如果您在大约 6k 封电子邮件之后离开程序进行处理，我们会收到一个错误，即“最大 session 大小”已达到并且它不会再发送任何邮件。
目前我们没有真正的方法知道它收到了哪封邮件，我们唯一的节流方法是基于猜测工作，包括通过手动按钮每 90 秒发送 1k 封电子邮件。
我一直在搜索，直到我头疼为止，以寻找有关如何在电子邮件发出时跟踪它们，如何测量 session 大小或仅允许按一个按钮并使小部件自我节流的某些指示但似乎没有人想在网上谈论它。
我对相关查询提出了一些建议，这些建议建议完全修改小部件，甚至编写定制的群发邮件应用程序。
最后，我们要做的就是限制外发邮件，这样它就不会导致错误，或者，如果这是不可避免的，允许它计算发送的邮件并给我们一些线索，让我们在哪里接收，甚至优雅地处理错误。某物。任何事物。
有没有人有任何切实可行的建议来跟踪来自原始服务器的 .Net 2.0 生成的电子邮件？
最佳答案
为什么 session 增长？您是否在请求的生命周期内执行此操作？
我假设您通过保留有关 session 状态中发送的电子邮件的信息来“跟踪”。我会编写一个跟踪器，可以将跟踪信息批量写入外部存储，例如磁盘上的 xml 文件或 sql 数据库。
如果跟踪部分不是导致问题的原因，而是一次一封的电子邮件(或发送它们的小部件)，您可以尝试批量发送电子邮件并密件抄送它们，而不是一次发送一封。 Blind Carbon Copies 始终是个人地址，并且不会向收件人透露它是大量邮寄的。您只需要弄清楚您可以通过密件抄送发送的电子邮件数量的限制。
第三种选择是，在您的网络应用程序中，将生成这些电子邮件所需的内容放到一个公共(public)存储位置，并拥有一个 Windows 服务应用程序(或计划任务应用程序)，该应用程序会定期检查新的电子邮件作业并在您的网络之外处理它们应用程序...甚至可能在您的网络应用程序的主机服务器之外。当然，这种事情在共享托管服务器上是行不通的……
关于asp.net - SMTP 通过 ASP.Net 2 session 大小问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/627247/