interaction significative avec IIS SMTP Server .Net

Question

Notre entreprise envoie un bulletin d'information à un grand nombre d'abonnés chaque semaine. Quand l'entreprise était très jeune, avant de rejoindre, ils utilisaient une version "gratuite" d'un expéditeur de masse qui prenait six heures pour envoyer des courriers de 5K et qui tombait sous le coup de toutes les vérifications DNS inversées sur Internet.

Je mis à jour à un widget de mesure .Net qui a couru sur le serveur correct et pourrait envoyer jusqu'à environ 20k mails en une demi-heure avec le plein respect DNS. Malheureusement (ou heureusement en fonction de votre point de vue), notre liste de diffusion a maintenant dépassé cet outil simple. En particulier, son manque de limitation adéquate, il peut faire plus de mails que le serveur peut envoyer confortablement à la fois. J'ai besoin de surveiller réellement combien l'allocation de stockage de courrier sortant disponible du serveur SMTP est complète et de limiter la charge en conséquence.

Malheureusement, je ne peux trouver aucune information sur l'endroit où un objet de courrier va quand (ou même si) il est transformé en poste. Je peux implémenter un système de fichiers si j'ai un endroit à regarder, actuellement je ne le fais pas. Si aucun fichier mail n'est créé, je devrais en créer un pour implémenter la fonctionnalité, mais j'ai besoin de savoir où le mettre. Il serait également plus rassurant de permettre au système de confirmer l'envoi d'une manière ou d'une autre, mais je n'ai aucune idée de la façon de procéder pour récupérer les données du système indiquant qu'un courrier a été envoyé.

recherche sur Google a étendu ses preuves vagues sur ces points; alors je me demandais si quelqu'un ici savait où je pourrais obtenir un guide de ces problèmes, ou pourrait autrement me diriger dans la bonne direction.

Merci beaucoup.

EDIT: Au final, j'ai abandonné l'essai de mesurer le débit sur le serveur SMTP IIS comme un mauvais travail. Ça ne semblait pas vouloir jouer. J'effectue maintenant ma journalisation dans un endroit séparé et je la redirige vers le serveur SMTP par la suite. Je ne sais toujours pas de quelqu'un qui s'inquiète vraiment d'essayer de garder un œil sur les actions du serveur SMTP d'IIS et ainsi cette question à ce jour reste sans réponse.

Eh bien ...

Answer 1

Bon alors je travaille sur ce projet depuis des siècles maintenant et je pensais que je pourrais partager mes découvertes avec le monde.

Le SMTP du serveur IIS

Tous les mails créé à l'aide du serveur SMTP IIS sont envoyés, en premier lieu, le répertoire de collecte. Si vous envoyez un courrier, vous devrez le faire à l'heure de Matrix pour l'y voir car il ira probablement tout de suite.

À la sortie d'un message individuel, il traverse le dossier de la file d'attente dans IIS.

Si vous voulez regarder le compteur de performance pour surveiller ce processus, regardez la "Longueur de la file d'attente à distance". (La raison en est que "Local Queue Length" surveille les mails envoyés "Localement" dans le réseau. "Remote" dans ce cas fait référence à "Outside into the world" .La définition spécifique de "Local" m'échappe quand nous envoyons pas de courrier local mais j'imagine que cela signifie en attente d'aller aux boîtes aux lettres contenues dans l'installation spécifique de IIS sur le serveur ou tout groupement local de celui-ci.)

D'un point de vue Exchange, il semble être l'équivalent de mails envoyés dans le domaine d'échange et ceux envoyés de ce domaine dans le monde plus large.

De toute façon. La longueur de la file d'attente à distance ne dit pas toute l'histoire. Vous devez également regarder la file d'attente Retry distante, le nombre de connexions sortantes actuelles et, pour la ceinture et les accolades, le nombre réel de fichiers dans le répertoire de la file d'attente.

Voici pourquoi:

• file d'attente à distance: Tous les messages qui n'ont pas encore été envoyés , cependant plusieurs fois cela a été essayé. Le nombre de courriers actuellement affectés à toutes les connexions ouvertes n'est pas pris en compte car ils sont dans un état "en cours d'essai".
• File d'attente de nouvelle tentative à distance: tous les messages qui n'ont pas encore été envoyés et qui ont déjà été attribués à ont été affectés à une connexion ouverte pour la distribution. Évidemment la livraison doit avoir échoué ou le message aurait été remis. Tous les messages actuellement affectés à une connexion ouverte pour une nouvelle tentative ne sont pas pris en compte.
• Connexions sortantes actuelles: Indique lorsque le serveur tente d'envoyer en file d'attente mails, plus d'un message peut être affecté à une connexion sortante. Les messages ainsi attribués ne sont pas comptés dans la file d'attente à distance ou dans la file d'attente de nouvelle tentative à distance. Physique
• Fichiers dans le répertoire de la file d'attente: Ce indique le nombre de messages encore en le répertoire de file d'attente. Cela diminuera au fur et à mesure que les courriers seront livrés avec succès .

Exemple: Si vous avez 0 connexions sortantes et 50 mails dans le répertoire de file d'attente puis la file d'attente à distance, Retry Queue et les fichiers physiques lirons tous à 50. Lorsqu'un indicateur de nouvelle tentative est élevée (ce qui est un cadre dans IIS), le nombre de connexions augmente et le nombre de messages dans les files d'attente diminue. Jusqu'à ce qu'un courrier soit livré, le nombre de fichiers physiques reste le même. Cependant, comme plus d'un courrier peut être envoyé sur une connexion en cours, une connexion peut entraîner des files d'attente et des files d'attente distantes de 47 ou moins. Si, au cours de l'événement de nouvelle tentative, les courriers électroniques sont correctement remis, le nombre de fichiers physiques dans le répertoire de la file d'attente diminuera. Lorsque la connexion se ferme, les compteurs de file d'attente doivent tous se stabiliser à nouveau.

Connexion

Il est possible avec.La bibliothèque Mail de Net pour spécifier un répertoire de collecte séparé de la valeur par défaut IIS. Ici, vous pouvez mettre en file d'attente des courriels et obtenir un service sur mesure pour déplacer les courriels dans le répertoire IIS où le service IIS prendra le relais et enverra des courriels en file d'attente.

Pour ce faire, vous allez rechercher la propriété "DeliveryMethod" de l'objet SmtpClient qui doit être définie sur SmtpDeliveryMethod.SpecifiedPickupDirectory.

Pour définir réellement SpecifiedPickupDirectory, vous devez définir la propriété PickupDirectoryLocation de SmtpClient.

Lorsque les messages sont livrés à cet emplacement, ils sont stockés en tant que fichiers .eml. Le nom de fichier est un GUID. Cela signifie que plusieurs courriels seront expédiés dans un ordre essentiellement aléatoire. Vous pourriez, en théorie, écrire du code pour répondre à cette situation si vous le souhaitez. Le fichier .eml suit un format standard qui peut être lu en ouvrant le fichier .eml dans le bloc-notes. L'analyse de ceci vous permettra d'extraire des informations pour un journal.

J'espère que cette vue d'ensemble de haut niveau sur la façon dont fonctionne le serveur SMTP dans IIS est d'une certaine aide pour quelqu'un dans une position similaire à celle que j'étais en Mars.

Answer 2

Je voudrais utiliser le composant PerformanceCounter à lire Longueur de la file d'attente locale comptoir du service SMTP. Cela devrait vous garder le contrôle :-)

Answer 3

Si votre widget .net est sur mesure, pourquoi ne pas limiter sa sortie à un débit (définissable)? En alternative, vous pourriez être en mesure de jouer avec certains paramètres de registre pour le serveur SMTP.

http://blog.rednael.com/CommentView,guid,dc20366c-3629-490a-a8ee-7e8f496ef58b.aspx

Apparemment, il y a aussi des compteurs WMI (SMTP Server \ Longueur de la file d'attente à distance et le serveur SMTP \ distant Retry Queue Length) qui vous donnera des informations utiles.

http://www.tech-archive.net/Archive/Internet-Server/microsoft.public.inetserver.iis.smtp_nntp/2008-02/msg00011.html