SMTP通过ASP.Net 2会话大小问题

我写了很长一段时间的一个邮件群发组件，我们遇到了一个问题，这个问题的确切性质，如何衡量它，如何减轻它，都仍然是难以捉摸的

这些问题已经到了关键时刻，我需要一些直截了当的答案，所以我希望这里有人能提供答案

基本上，这个群发邮件小部件一次只向邮件列表发送大约25k封邮件。这是我们更喜欢的消息，因为它意味着每个收件人都会收到一封写给他们本人的邮件，所以我们对这个循环感到满意

我们不满意的是，如果您在收到大约6k封电子邮件后让程序继续处理，我们会收到一个错误，即已达到“最大会话大小”，并且不会再发送任何邮件

我们目前没有真正的方法知道它发到了哪封邮件，我们唯一的节流方法是基于猜测工作，通过手动按键每90秒发送1k封邮件

我一直在搜索，直到我的头很痛，寻找一些指示，如何跟踪电子邮件，如何测量会话大小，或者什么，只允许过程是一个按钮按下，小部件是自我节流，但似乎没有人想在网上谈论它

我对相关的查询提出了一些建议，建议完全修改小部件，甚至编写定制的群发邮件应用程序

最后，我们要做的就是限制发送的邮件，这样它就不会导致错误，或者，如果不可避免，允许它计算发送的邮件，并给我们一些线索，告诉我们从哪里接收邮件，甚至优雅地处理错误。某物什么都行

---

是否有人对从原始服务器跟踪.Net 2.0生成的电子邮件有任何实际可行的建议？

为什么会话在增长？您是否在请求的生命周期内执行此操作

我假设您正在“跟踪”会话状态中发送的电子邮件信息。我会编写一个跟踪程序，它可以将跟踪信息批量写入外部存储，例如磁盘上的xml文件或sql数据库

如果跟踪部分不是导致问题的原因，但一次性电子邮件（或发送邮件的小部件）是，那么您可以尝试批量发送电子邮件并以密件传给他们，而不是一次发送一封。盲文复写本通常是个人地址，不要向收件人透露它是群发的。你只需要计算出你可以通过密件抄送的电子邮件数量的限制

---

第三种选择是，在web应用程序中，将生成这些电子邮件所需的内容放入公共存储位置，并使用windows服务应用程序（或计划任务应用程序）定期检查新的电子邮件作业，并在web应用程序外处理这些作业。。。甚至可能在web应用程序的主机服务器之外。当然，这种事情在共享主机服务器上是行不通的…

我们做的事情大致相同，但我们每分钟发送500封电子邮件。前500个被发送，然后页面重新加载自身，接下来的500个继续工作

---

这需要一点日志记录和存储关于当前500个队列的信息，允许超时、提前重新加载等，但它已经工作了几年（在任何给定的晚上发送大约10000封电子邮件）。

我从未使用ASP.NET编写过一行代码，因此我无法帮助您进行编码，但我能做的是帮你指出错误。我对SMTP协议有深入的了解，并有运行SMTP服务器的经验，平均每天大约有一百万封个人电子邮件

您提到的“最大会话大小”错误是造成混淆的实际原因。即使这个错误明确地说“大小”实际的问题是“数量”，这对于您的电子邮件服务器来说是一个非常大的数字。出于安全原因，每个电子邮件（SMTP）服务器的配置方式都限制了各种因素的数量，如单个电子邮件号码、最终收件人号码等。假设有人试图向1000个收件人发送1MB大小的电子邮件，用户只需将大约1MB的数据从其主机端传输到SMTP服务器，服务器本身必须传输1GB的数据才能成功地发送到所有这些电子邮件。超过2GB的数据，以防反弹每封电子邮件。为了保护对邮件中继服务器的此类攻击，SMTP守护程序设置了某种限制。在您的情况下，您的脚本将连接到SMTP服务器一次，并开始在不断开连接的情况下转发数千封单独的电子邮件。服务器实际上并不关心您从ASP.NET程序或任何其他电子邮件客户端发送的邮件，当数量超过限制时，服务器将限制并拒绝您

当您谈到生成每封电子邮件的“循环”时，只需为每500封电子邮件中继设置另一个循环以断开并连接到SMTP。请记住，您的SMTP服务器拒绝您并不是因为您超过了某些大小限制，而是因为您达到了任何单个连接允许的最大电子邮件中继。连接，转发固定数量的电子邮件，断开连接，然后再次连接以发送下一批邮件，并循环发送，直到您完成需要发送的每一封邮件的转发

---

愉快地发送电子邮件（而不是垃圾邮件）…

就会话而言，我只是报告返回的错误消息所说的内容。虽然你给了我一个有趣的想法。第三个选项听起来像是一个常客。可能一个简单的应用程序作为计划任务运行是你最好的选择。