在净IIS SMTP服务器有意义的互动 [英] Meaningful interaction with IIS SMTP Server in .Net
问题描述
我们的业务发送简讯每星期广大用户。当企业还很年轻，我加入之前，他们使用的花六个小时发送5K邮件摔在互联网上的每一个反向DNS检查的犯规有些群发邮件的免费版本。
Our business sends a newsletter to a vast number of subscribers every week. When the business was very young, before I joined, they used a "free" version of some mass mailer that took six hours to send 5K mails and fell foul of every reverse DNS check on the internet.
我升级这一个定制的.Net小工具，跑了正确的服务器上，并可以发送高达约20K的邮件在半小时内全DNS达标。不幸的是（或幸运取决于你的立场）现在我们的邮件列表已经超越这个简单的工具。特别是其缺乏足够的节流，它可以使更多的邮件比服务器可以轻松发送一次。我需要实际监测IIS SMTP服务器的可用传出邮件存储分配是否完整，并相应地扼杀负载。
I upgraded this to a bespoke .Net widget that ran on the correct server and could send up to about 20k mails in half an hour with full DNS compliance. Unfortunately (or fortunately depending on your standpoint) our mail list has now outgrown this simple tool. In particular its lack of adequate throttling, it can make more mails than the server can comfortably send at once. I need to actually monitor how full the IIS SMTP server's available outgoing mail storage allocation is and throttle the load accordingly.
不幸的是我能找到的地方一个邮件对象超出任何信息时（或者即使），它变成一个邮件。我可以实现一个FileSystemWatcher的，如果我有一个地方看，现在我不知道。如果没有实际的邮件文件是有史以来我想我将不得不创建一个实现该功能，但我需要知道在哪里把它。这也将是比较让人放心，让系统确认发送不知何故，但我不知道如何去检索从，说邮件已发送系统数据。
Unfortunately I can find no information on where a mail object goes when (or even if) it is turned into a mail. I can implement a filesystemwatcher if I have a place to watch, currently I don't. If no actual mail file is ever created I guess I will have to create one to implement the functionality but I need to know where to put it. It would also be more reassuring to allow the system to confirm sending somehow but I have no idea how to go about retrieving data from the system that says a mail has been sent.
谷歌搜索大量事实证明模糊在这些问题上;所以我想知道是否有人在这里知道在那里我能得到一个指导这些问题，或者本来点我在正确的方向。
Extensive Googling has proven vague on these points; so I was wondering if anyone here knew where I could get a guide to these problems, or could otherwise point me in the right direction.
非常感谢。
编辑：最后，我放弃了试图测量在IIS的SMTP服务器作为一个不好的工作吞吐量。它只是似乎要想玩没有。现在我履行我的日志在一个单独的位置，此后只是分流它通过对SMTP服务器。我还是不知道谁真正困扰试图保持标签上的IIS SMTP服务器的所作所为，因此这个问题作为本文写作去解答的。
In the end I gave up trying to measure throughput on the IIS SMTP server as a bad job. It just didn't seem to want to play. I'm now carrying out my logging in a separate location and just shunting it through to the SMTP server thereafter. I still don't know of anyone who really bothers trying to keep tabs on the doings of the IIS SMTP server and so this question as of this writing goes unanswered.
呵呵嗯......
推荐答案
好了，所以我一直在这个项目上的年龄了，我想我可能会分享我的发现与世界同步。
Okay so I've been working on this project for ages now and I thought I might share my findings with the world.
的IIS SMTP服务器
所有邮件使用创建IIS SMTP服务器发送，在第一时间，到分拣目录。如果要发送一个邮件，然后你将不得不在矩阵时间来操作真正见过它那里，因为它可能会只是去，立竿见影。
All mails created using the IIS SMTP server are sent, in the first instance, to the Pickup Directory. If you are sending one mail then you will have to operate in Matrix time to actually ever see it there because it will probably just go, straight away.
在个人邮件的出路是通过IIS中的队列文件夹门。
On an individual mail's way out of the door it passes through the queue folder in IIS.
如果你想观看的性能计数器来监视这个过程中，你乌尔德看看远程队列长度。 （这样做的原因是，本地队列长度监控邮件发送本地的网络中。远程在这种情况下指的是外闯天下。的本地的具体定义脱离了我和我们送没有本地邮件，但我想这意味着排队去包含IIS的服务器或其任何本地组的具体安装中的邮箱。）
If you wanted to watch the Performance Counter to monitor this process you ould look at the "Remote Queue Length". (The reason for this is that the "Local Queue Length" monitors mails sent "Locally" within the network. "Remote" in this instance refers to "Outside into the world". The specific definition of "Local" escapes me as we send no local mail but I imagine it means queued to go to mailboxes contained within the specific installation of IIS on the server or any local grouping thereof.)
从一个Exchange点查看这似乎是Exchange域以及发出该领域进入更广阔的世界内发送邮件的等价物。
From an Exchange point of view it seems to be the equivalent of mails sent within the Exchange Domain and those sent out of that domain into the wider world.
总之。远程队列长度并不能说明整个故事。您还可以看看远程重试队列，当前的出站连接的数量，并为带和背带的缘故队列目录中的文件的实际数量。
Anyhow. The Remote Queue Length doesn't tell the whole story. You also have to look at the Remote Retry Queue, the number of Current Outbound Connections and, for belt and braces sake the actual number of files in the queue directory.
下面是原因：
- 远程队列：有没有
尚未发送的所有邮件，但很多时候
本已试过。不计入当前分配给任何打开
连接
邮件的数量，因为它们
都以正在尝试的状态。 - 远程重试队列：即
的所有消息都尚未发出有，在
在过去的某个点上，被分配
到交货打开连接。
显然递送必须具有
失败或该消息将是
递送。 。任何消息目前千元分配到一个
重试的开放连接B $ B不计 - 当前出站连接：当
服务器尝试发送显示排队
邮件，一个以上的消息可以是分配到出站连接
。从而赋予
消息并不
无论是在远程队列或$计B $ b中的远程重试队列。物理 - 文件在队列中的目录：此$ B $ 1b示出仍然在
中的队列目录的邮件的数目。这将
减少，因为邮件是成功
交付
- Remote Queue: All messages that have not yet been sent, however many times this has been tried. The number of mails currently assigned to any open connections are not counted as they are in a state of "being tried".
- Remote Retry Queue: All messages that have not yet been sent that have, at some point in the past, been assigned to an open connection for delivery. Obviously the delivery must have failed or the message would have been delivered. Any messages currently assigned to an open connection for a retry are not counted.
- Current Outbound Connections: Shows when the server is attempting to send queued mails, more than one message can be assigned to an outbound connection. Messages thus assigned are not counted in either the Remote Queue or the Remote Retry queue. Physical
- Files in the queue directory: This shows the number of mails still in the Queue directory. This will decrease as mails are successfully delivered.
的例如：的若你必须在队列目录，然后远程队列，重试队列和物理文件将所有在50。当一个重试标志升起读0出站连接和50邮件（这是在IIS中设置）连接次数的增加和次数队列中的邮件的减小。直到邮件传递的物理文件的数量保持不变。然而，由于多个邮件可以在当前连接1连接发送，可能导致远程队列和重试队列长度的47或更低。如果在重试活动期间，任何邮件都成功交付在队列目录的物理文件的数量，然后将减少。当连接关闭队列柜台都应该重新稳定下来。
Example: If you have 0 outbound connections and 50 mails in the Queue directory then the Remote Queue, Retry Queue and Physical files will all read at 50. When a retry flag is raised (this is a setting in IIS) the number of connections increases and the number of mails in the queues decreases. Until a mail is delivered the number of physical files remains the same. However as more than one mail can be sent on a current connection 1 connection may result in Remote Queue and Retry Queue lengths of 47 or lower. If, during the retry event, any mails are successfully delivered the number of physical files in the Queue directory will then decrease. When the connection closes the queue counters should all stabilise again.
登录
这可能与.net的邮件库，指定拾取目录从IIS默认分开。在这里，您可以排队邮件并获得一个定制的服务，偶尔邮件移动到IIS目录所在的IIS服务将接管并发送排队的邮件。
It is possible with .Net's Mail library to Specify a Pickup directory separate from the IIS default. Here you can queue mails and get a bespoke service to occasionally move the mails into the IIS directory where the IIS service will take over and send out queued mails.
要做到这一点你将寻找其应设置为SmtpDeliveryMethod.SpecifiedPickupDirectory的SmtpClient对象的DeliveryMethod属性。
To do this you will be looking for the SmtpClient object's "DeliveryMethod" property which should be set to SmtpDeliveryMethod.SpecifiedPickupDirectory.
要实际设置应设置SmtpClient的PickupDirectoryLocation财产SpecifiedPickupDirectory。
To actually set the SpecifiedPickupDirectory you should set the SmtpClient's PickupDirectoryLocation property.
当邮件被传递到这个位置它们被存储作为.eml文件。该文件名是一个GUID。这意味着多个电子邮件地址将在一个基本上随机的顺序寄发。可以在理论上，如果需要编写代码来解决这种情况。 .eml文件遵循这可以通过在记事本中打开.eml时，读的标准格式。解析这将允许你提取的日志信息。
When mails are delivered to this location they are stored as .eml files. The filename is a GUID. This means that multiple emails will be despatched in an essentially random order. You could, in theory, write code to address this situation if desired. The .eml file follows a standard format which can be read by opening the .eml in notepad. Parsing this will allow you to extract information for a log.
我希望在IIS中的SMTP服务器的工作方式这个高层次的概述一些援助，有人在类似的位置，一个我在三月份。
I hope this high level overview of the way the SMTP server in IIS works is of some assistance to someone in a similar position to the one I was in in March.
这篇关于在净IIS SMTP服务器有意义的互动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
