Construction d'un expéditeur de courrier en bloc

Question

Je souhaite créer une application qui permettra à mes clients d'envoyer des informations marketing par courrier électronique. Ce sera un outil soigneusement surveillé utilisé pour le courrier en vrac légitime seulement. Il aura toutes les fonctionnalités nécessaires de 'désabonnement', etc.

La solution sera construite en utilisant VB.NET.

Ma question porte sur la meilleure façon d'envoyer réellement les e-mails. Nous avons un serveur SMTP dans notre centre de données que nous pouvons utiliser. Je pense que nous pourrions écrire un genre de service Windows multithread pour surveiller une base de données d'e-mails à envoyer, puis faire des appels à l'API System.Net.Mail pour envoyer à travers ce serveur.

Est-ce que cela va me donner le niveau de performance dont j'ai besoin pour envoyer du courrier à des milliers d'utilisateurs dans un délai raisonnable?

Si ce n'est pas le cas, devrais-je envisager de faire les choses à un niveau inférieur, effectuer des recherches DNS dans un fil, envoyer directement au serveur concerné sur le port 25 dans un autre fil, etc.

Tous les pointeurs seraient appréciés!

---

Pas vraiment une réponse - mais une mise à jour pour toute personne intéressée ... Je cherche actuellement à un produit appelé ActiveMail de ActiveUp.

Cela semble être un MTA (effectuer ses propres recherches MX et envoyer le courrier directement), et il est livré avec une application de mise en file d'attente multi-thread.

Answer 1

La question ne suffit pas précis, mais je vais essayer de répondre de toute façon. Il y a quelques facteurs qui limitent vos options. Le meilleur "chemin" est vraiment à la hauteur de vos circonstances. À quelle date travaillez-vous?

La mise en œuvre d'un grand système d'envoi de courrier multithread bas niveau prendra beaucoup de temps par rapport à l'autre option que vous avez mentionnée. Bien sûr, écrire le tout à partir de zéro est beaucoup plus élégant que d'utiliser le serveur SMTP et la bibliothèque .NET pour envoyer les mails.

Il y a aussi la question de la bande passante entre les différentes données. L'application .NET et la base de données seront-elles exécutées sur le même serveur que le SMTP? Sinon, comment le pipeline de bande passante limitera-t-il le maximum de mails envoyés par seconde?

Personnellement, je suis un grand fan de le garder simple. La réutilisation des logiciels disponibles est un choix judicieux si l'horloge tourne. À quelle fréquence enverrez-vous des milliers de courriels? Cet intervalle définira si le laps de temps est sensible ou non. Est-il si petit que vous pourriez vous retrouver avec le système fonctionnant encore sur le premier "lot" lorsqu'une autre version est prête à être envoyée?

Answer 2

Tout d'abord obtenir un composant pour faire le levage lourd. Je recommanderais: aspnetmail

Ensuite, la configuration de Bulkmailing est aussi simple que de télécharger un exemple de code.
WebMailer: Sending 1000s of emails from a web page without timing out.

Le même fournisseur fournit également des vérificateurs de courrier vérificateur/rebond record mx etc. Cette solution est gratuite, mais le temps que vous enregistrez pas chasser les bugs/incohérences dans le composant de messagerie standard fera cette valeur de votre temps.

Oh et si vous voulez un logiciel de messagerie en vrac qui se trouve sur le bureau qui est également fourni: http://www.aspnetemail.com/rapidmailer/

Answer 3

Je pense qu'il est pas si difficile de rouler quelque chose comme ça sur votre propre. Il faudrait un jour ou deux pour construire. Mais vous devriez être beaucoup mieux d'utiliser quelque chose de existant.

Pourtant, certaines choses que je trouve fort importantes en vrac-Email:

Ne pas utiliser votre propre SMTP pour envoyer ceux-ci.

Lookup les entrées MX pour vos destinataires et connectez le smtpclient à leur SMTP, cela vous donne l'avantage que vous obtenez en retour une erreur instantanée msg lorsque la boîte aux lettres est introuvable ou autre chose ne va pas, et vous n Ne stressez pas votre propre serveur. Il y avait aussi un petit bogue dans SmtpClient qui m'a causé des problèmes car le nom d'hôte n'est pas un nom de domaine complet (comme demandé par la spécification SMTP) mais le nom de la machine (et c'est un champ interne dans SmtpClient). Certains serveurs SMTP prennent cela au sérieux et veulent un nom de domaine à la place, donc j'ai fini par définir ce champ avec la réflexion à un FQDN. (Nous espérons que cela a été changé depuis) ​​