Umgebung:
- IIS-Webfarm
- 5 Server
- Windows Server 2008 R2
- IIS 7.5
- ASP.NET 3.5 und 4.0 Webanwendung
Unsere Web-App muss, wie viele andere auch, E-Mails senden. Nur senden, nicht empfangen.
In der Vergangenheit haben wir den IIS 6-SMTP-Dienst auf jedem Webserver aktiviert und die .NET-SMTP-Klassen verwendet, um E-Mail-Dateien im Abholordner abzulegen. Funktioniert gut.
Um die Umgebung zu vereinfachen und weniger Dienste auf den Webservern auszuführen, erwäge ich, den SMTP-Dienst auf nur einem Windows-Dienstprogramm auszuführen und das Abholverzeichnis den übrigen Webservern in der Farm mithilfe von a zur Verfügung zu stellen Dateifreigabe. Die ASP.NET-Webanwendungen legen ihre E-Mail-Dateien einfach im freigegebenen Abholordner ab, und der einzelne SMTP-Dienst verarbeitet den ausgehenden E-Mail-Fluss für alle Webserver. Ich mache mir keine Sorgen um das Volumen oder die Fähigkeit des SMTP-Dienstes, Schritt zu halten, das ist kein Problem.
Die Profis:
- Vereinfachte Verwaltung und Konfiguration
- Geringere Auslastung und reduzierter Angriffsvektor auf den Webservern
- Ein einziger Punkt zur Fehlerbehebung bei E-Mail-Problemen
Die Nachteile:
- Der Punkt des Versagens
- Wenn ich das Dienstprogramm neu starten muss, gehen die Funktionen für ausgehende E-Mails verloren. Dies könnte möglicherweise durch die Verwendung des Offline-Ordner-Caching für die Dateifreigabe auf den Webservern verringert werden. Ich habe es nicht getestet, aber möglicherweise können die Webserver, die keine Verbindung zur Dateifreigabe feststellen, ihre Dateien lokal löschen, um beim Neustart automatisch mit dem SMTP-Server synchronisiert zu werden.
- Konflikt zwischen E-Mail-Dateinamen - Sie müssen sicherstellen, dass ASP.NET beim Schreiben der EML-Dateien einen garantierten eindeutigen Namen für die gesamte Webfarm verwendet. Der SmtpClient-Quellcode gibt an, dass eine GUID zum Benennen der Dateien verwendet wird, aber MS könnte dies in einer zukünftigen Implementierung ändern.
Ob das funktioniert?
Bearbeiten: Wenn ich mehr über meine Idee für Offlinedateien nachdenke, bin ich mir nicht sicher, ob dies der beste Ansatz ist. Für Offlinedateien ist eine geplante Aufgabe erforderlich, um die Synchronisierung zu planen. Bei jeder Ausführung werden alle Mail-Dateien der anderen Webserver vom lokalen Cache jedes anderen Servers abgerufen. Vielleicht ist es eine bessere Idee, die Dateien einfach in einem lokalen Ordner zu stapeln, und ein anderer Job (geplante Robokopie) versucht, sie auf die Remote-Dateifreigabe zu kopieren, wann immer sie aktiv sind. Hatte über DFSR nachgedacht, aber ich werde wieder alle Mail-Dateien auf alle Webserver mischen, und das ist verschwenderisch.
quelle
Antworten:
Besser wäre es, SMTP über TCP / IP zu verwenden, dh Port 25 (oder einen anderen Port) abzuhören und dann MailMessage und SmtpClient von System.Net.Mail zu verwenden.
Sie können dann einen Load Balancer vor den SMTP-Server werfen und jeden Server mit diesem Load Balanced-Namen / dieser IP-Adresse verbinden lassen.
quelle
Ich kann Ihren Standpunkt hier nicht sehen. Sie versuchen, Ihre Einrichtung zu vereinfachen, indem Sie komplexere und sicherheitstechnische Probleme verursachen.
SMTP ist die Lösung für Ihr Problem. Jetzt müssen Sie nur noch nach einer guten Implementierung suchen. SMTP verfügt über eine integrierte Warteschlangenbehandlung (keine Kollisionen mit Dateinamen), ist ausfallsicher, redundanzbewusst aufgrund mehrerer MX und ist ein altes, gut getestetes Protokoll. Übrigens ist es betriebssystemunabhängig.
Sie möchten dies mit einem Single-Point-of-Failure-, Scheduler-abhängigen, betriebssystemgebundenen, undokumentierten und neuen, nicht getesteten Verfahren zur Neuerfindung des Rads austauschen. Außerdem stellen Sie nicht nur für diese 5 Server ein Drop-In-Box für alle bereit.
Verwenden Sie einen einfachen Store-and-Forward-Server (wie E-MailRelay ) auf den Webservern und einen zentralen SMTP-Server, an den die E- Mails weitergeleitet werden. Dieser SMTP-Server wird dann für die endgültige Zustellung verwendet. Dann können Sie Ihr zentrales SMTP so sichern, dass nur Verbindungen von diesen 5 Servern akzeptiert werden und absenderbasiert abgelehnt werden oder welche Filter / Blöcke Sie verwenden möchten, um das potenzielle (Spam-) Risiko für die Öffentlichkeit zu verringern.
Diese Lösung bietet alle Vorteile: Transparenz (Protokollierung + Überwachung), Einfachheit (ein Prozess), Konformität (Standard-Internetprotokoll) und Integrität (Zustellbestätigung). Keine Notwendigkeit, selbst erstellte Problemumgehungen auszutauschen.
quelle