Well, that's why I have been working on this project for many years, and I thought that I could share my discoveries with the world.
SMTP IIS Server
All messages created using the IIS SMTP server are sent primarily to the distribution directory. If you send one mail, you will have to work in Matrix time to actually see it there, because it will probably just go right away.
On an individual mail path from a door, it goes through the queue folder in IIS.
If you want to look at the performance counter to track this process, you can look at "Remote queue length." (The reason for this is that the “Local Queue Length” keeps track of mail sent “Locally” on the network. “Remote” in this case refers to “Out of the World.” The specific definition of “Local” eludes me as I send no local mail , but I suppose that means queuing up for access to the mailboxes contained in a specific IIS installation on the server, or their local grouping.)
From an Exchange perspective, this is similar to mail sent in an Exchange domain and sent from that domain to the wider world.
Anyway. The remote queue length does not tell the whole story. You should also look at the Remote Retry Queue, the number of current outgoing connections, and the belt and brackets for the actual number of files in the queue directory.
That's why:
- Remote queue: all messages that do not have but were sent, however many times this has been tried. The amount of mail that is currently assigned to any open connection is not taken into account, since they are in a “be tried” state.
- Remote re-queue: all messages that have not yet been sent, some point in the past, have been assigned to an open connection for delivery. Obviously, the delivery must have or the message would have been delivered. Any messages currently assigned to an open connection for repetition are not counted.
- Ongoing outgoing connections: shows when the server is trying to send to the mail queue, more than one message may be assigned to the outgoing connection. Messages assigned in this way are not counted either in the remote queue or in the Remote Retry queue. Physical
- Files in the queue directory: this shows the number of messages still in the queue directory. This will reduce the number of successful emails delivered.
Example. If you have 0 outgoing connections and 50 letters in the Queue directory, then the remote queue, retry queue, and physical files will be read at 50. When the retry flag is raised (this is a parameter in IIS), the number of connections increases and the number of letters in the queues decreases . Until the mail is delivered, the number of physical files will remain the same. However, as more than one mail can be sent over the current connection, 1 connection can result in a remote queue queue and a re-queue of 47 or lower. If during the retransmission event all messages are successfully delivered, the number of physical files in the queue directory will decrease. When the connection closes, the queue counters should stabilize again.
Logging
It is possible to specify a layout directory in the .Net Mail library that is different from the standard IIS. Here you can send mail to the queue and receive a custom service to sometimes move letters to the IIS directory, where IIS will be captured and sent to the queue by mail.
To do this, you will look for the SmtpClient object "DeliveryMethod Property", which should be set to SmtpDeliveryMethod.SpecifiedPickupDirectory.
To truly set SpecifiedPickupDirectory, you must set the SmtpClient PickupDirectoryLocation property.
When mail is delivered to this place, they are stored as .eml files. The file name is GUID. This means that several emails will be sent essentially randomly. Theoretically, you could write code to solve this situation if you want. The .eml file follows a standard format that can be read by opening .eml in notepad. Parsing data will allow you to extract information for the log.
I hope this high-level overview of how the SMTP server works in IIS can help someone in the same position as in March.