13
Exchange Mailinfrastruktur für 100 Mailboxen
Hallo zusammen,
momenten haben wir folgende Mailkonstellation im Einsatz für ca. 100 Mailbenutzer mit einem Mailaufkommen von ca. 500 am Tag:
Im lokalen LAN Exchange 2010 Server auf einer Windows Server 2008R2 Umgebung. Dort sind alle Mailboxen für die User angelegt und es wird auch viel mit öffentlichen Ordnern/Mailversand gearbeitet.
Der Exchange empfängt eMails aus dem Internet via einem POPCon Connector. Er holt eMails von einem Postfix Server ab, welcher ein Sammelpostfach für alle Mailadressen hat.
Alle 5min werden die Mails von dem Sammelpostfach aus dem Internet abgerufen und an die Exchange Mailboxen verteilt.
Zum Versenden wird ein Sendeconnector benutzt, welcher über einen Smarthost die Mails vom Exchange versendet. Dies ist auch wieder ein Postfix server, welcher auch im Internet steht. (Nicht der selbe wie incoming mails).
Da die Postfix Server auf zwei verschiedenen Hostern momentan laufen und sehr teuer sind, soll ein Umzug erfolgen bzw. ein komplett neues Mailinfrastrukturkonzept. Der Exchange bleibt wie bisher im Einsatz.
Nun zu meinen Fragen:
Wie würdet ihr die Umgebung gestalten was das Empfangen und Versenden der Mails betrifft. Leider steht kein Budget für eine kostenbasierten Lösung zur Verfügung.
Meine Vorschläge für die neue Infrastruktur:
Plan A: Der Exchange soll Mails direkt empfangen und auch direkt versenden ohne externen Smarthost. Dazwischen steht lediglich ein SMTP-Proxy für Spam und Virenprüfung (z.B. die OpenSource Lösung: Scrollout F1).
Macht diese Lösung Sinn? Kann der SMTP-Proxy auch im eigenen LAN stehen, oder sollte dieser im Internet gehostet sein?
Ich habe gelesen das man von so einer Lösung dass der Exchange direkt versendet und empfängt eher abrät, da man schnell in die Gefahr läuft geblacklistet zu werden und es nicht so einfach zu konfigurieren wäre.
Plan B: Wieder einen eigenen Postfix Server betreiben im WWW der für den Empfang- und Versand der Mails dienen soll. Da wir leider nicht soviel Postfix Knowhow haben und der Vorgänger diesen betreut hatte, würden wir gerne von dieser Lösung weg. Gäbe es eine Alternative?
Plan C: Besteht die Möglichkeit bei einem großen Hoster im Internet einen Mailserver für den Empfang und Versand oder evtl. nur Versand als Smarthost zu mieten für 100 User?
Ich habe zb. bei Strato geschaut. Muss ich dort 100 Mailboxen für den Mailserver angeben, die dort betreut werden sollen oder was benötige ich wenn ich den Server von Strato nur als Mailversandserver nutzen möchte?
Was würdet ihr empfehlen für die oben genannte Infrastruktur um möglichst geringen Administrationsaufwand zu haben und keiner Gefahr einzugehen geblacklistet zu werden oder virenversuchte Inhalte in das LAN zu bekommen?
Danke und Grüsse
staybb
momenten haben wir folgende Mailkonstellation im Einsatz für ca. 100 Mailbenutzer mit einem Mailaufkommen von ca. 500 am Tag:
Im lokalen LAN Exchange 2010 Server auf einer Windows Server 2008R2 Umgebung. Dort sind alle Mailboxen für die User angelegt und es wird auch viel mit öffentlichen Ordnern/Mailversand gearbeitet.
Der Exchange empfängt eMails aus dem Internet via einem POPCon Connector. Er holt eMails von einem Postfix Server ab, welcher ein Sammelpostfach für alle Mailadressen hat.
Alle 5min werden die Mails von dem Sammelpostfach aus dem Internet abgerufen und an die Exchange Mailboxen verteilt.
Zum Versenden wird ein Sendeconnector benutzt, welcher über einen Smarthost die Mails vom Exchange versendet. Dies ist auch wieder ein Postfix server, welcher auch im Internet steht. (Nicht der selbe wie incoming mails).
Da die Postfix Server auf zwei verschiedenen Hostern momentan laufen und sehr teuer sind, soll ein Umzug erfolgen bzw. ein komplett neues Mailinfrastrukturkonzept. Der Exchange bleibt wie bisher im Einsatz.
Nun zu meinen Fragen:
Wie würdet ihr die Umgebung gestalten was das Empfangen und Versenden der Mails betrifft. Leider steht kein Budget für eine kostenbasierten Lösung zur Verfügung.
Meine Vorschläge für die neue Infrastruktur:
Plan A: Der Exchange soll Mails direkt empfangen und auch direkt versenden ohne externen Smarthost. Dazwischen steht lediglich ein SMTP-Proxy für Spam und Virenprüfung (z.B. die OpenSource Lösung: Scrollout F1).
Macht diese Lösung Sinn? Kann der SMTP-Proxy auch im eigenen LAN stehen, oder sollte dieser im Internet gehostet sein?
Ich habe gelesen das man von so einer Lösung dass der Exchange direkt versendet und empfängt eher abrät, da man schnell in die Gefahr läuft geblacklistet zu werden und es nicht so einfach zu konfigurieren wäre.
Plan B: Wieder einen eigenen Postfix Server betreiben im WWW der für den Empfang- und Versand der Mails dienen soll. Da wir leider nicht soviel Postfix Knowhow haben und der Vorgänger diesen betreut hatte, würden wir gerne von dieser Lösung weg. Gäbe es eine Alternative?
Plan C: Besteht die Möglichkeit bei einem großen Hoster im Internet einen Mailserver für den Empfang und Versand oder evtl. nur Versand als Smarthost zu mieten für 100 User?
Ich habe zb. bei Strato geschaut. Muss ich dort 100 Mailboxen für den Mailserver angeben, die dort betreut werden sollen oder was benötige ich wenn ich den Server von Strato nur als Mailversandserver nutzen möchte?
Was würdet ihr empfehlen für die oben genannte Infrastruktur um möglichst geringen Administrationsaufwand zu haben und keiner Gefahr einzugehen geblacklistet zu werden oder virenversuchte Inhalte in das LAN zu bekommen?
Danke und Grüsse
staybb
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 335949
Url: https://administrator.de/contentid/335949
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
13 Kommentare
Neuester Kommentar
Moin,
Plan A wäre mit einer statischen öffentlichen IP die bessere Wahl.
Gruß
Uwe
Plan A wäre mit einer statischen öffentlichen IP die bessere Wahl.
Gruß
Uwe
Hallo,
hab ihr eine Feste IP? Dann nen MX eintrag setzten und den POPConnector in Rente schicken.
Wenn man es richtig macht gibt's auch keine Probleme mit Blacklists.
hab ihr eine Feste IP? Dann nen MX eintrag setzten und den POPConnector in Rente schicken.
Wenn man es richtig macht gibt's auch keine Probleme mit Blacklists.
ja wir haben eine statische IP. Insgesamt 3 WAN Standleitungen. Eine davon hat eine statische IP.
Also dann würde ich den SMTP-Proxy auch intern betreiben und dorthin den MX Eintrag setzen, richtig?
Anschliessend leitet der SMTP-Proxy nach Prüfung der Mails alle weiter an den Exchange.
Was sollte man den beachten das man nicht auf Blacklists landet? Reverse DNS und SPF Einträge, sonst noch etwas? Und wie genau erstelle ich diese, bzw. an was orientiere ich mich da speziell bei den SPF Einträgen
Also dann würde ich den SMTP-Proxy auch intern betreiben und dorthin den MX Eintrag setzen, richtig?
Anschliessend leitet der SMTP-Proxy nach Prüfung der Mails alle weiter an den Exchange.
Zitat von @wiesi200:
Hallo,
hab ihr eine Feste IP? Dann nen MX eintrag setzten und den POPConnector in Rente schicken.
Wenn man es richtig macht gibt's auch keine Probleme mit Blacklists.
Hallo,
hab ihr eine Feste IP? Dann nen MX eintrag setzten und den POPConnector in Rente schicken.
Wenn man es richtig macht gibt's auch keine Probleme mit Blacklists.
Was sollte man den beachten das man nicht auf Blacklists landet? Reverse DNS und SPF Einträge, sonst noch etwas? Und wie genau erstelle ich diese, bzw. an was orientiere ich mich da speziell bei den SPF Einträgen
Moin,
Gruß,
Dani
Plan A wäre mit einer statischen öffentlichen IP die bessere Wahl.
Sehe ich auch so. Allerdings kann ich nicht beurteilen, ob die genannte Anwendung etwas taugt.Was würdet ihr empfehlen für die oben genannte Infrastruktur um möglichst geringen Administrationsaufwand zu haben und keiner Gefahr einzugehen geblacklistet zu werden oder virenversuchte Inhalte in das LAN zu bekommen?
Das ist ein Widerspruch in sich. Wer eine eigene E-Mailserver Infrastruktur betreiben möchte, hat auch den Pflegeaufwand (Logs prüfen, Aktualisierungen für OS und Anwendung regelmäßig einspielen, Monitoring ob das System fehlerfrei funktioniert, etc...).Gruß,
Dani
Was würdet ihr empfehlen für die oben genannte Infrastruktur um möglichst geringen Administrationsaufwand zu haben und keiner Gefahr einzugehen geblacklistet zu werden oder virenversuchte Inhalte in das LAN zu bekommen?
In die Azure Cloud ziehen.
Ich würde auch zu Plan A tendieren.
Hab es bei mir genauso umgesetzt. In der DMZ läuft der kostenlose Hmailserver und der Exchange pollt permanent mit PopCon und der Exchange steht im LAN.
Abgehend fungiert der Hmailserver als Relay für den Exchange.
Läuft seit Jahr und Tag ohne Probleme.
Hab es bei mir genauso umgesetzt. In der DMZ läuft der kostenlose Hmailserver und der Exchange pollt permanent mit PopCon und der Exchange steht im LAN.
Abgehend fungiert der Hmailserver als Relay für den Exchange.
Läuft seit Jahr und Tag ohne Probleme.
Zitat von @Saftnase:
Ich würde auch zu Plan A tendieren.
Hab es bei mir genauso umgesetzt. In der DMZ läuft der kostenlose Hmailserver und der Exchange pollt permanent mit PopCon und der Exchange steht im LAN.
Abgehend fungiert der Hmailserver als Relay für den Exchange.
Läuft seit Jahr und Tag ohne Probleme.
Ich würde auch zu Plan A tendieren.
Hab es bei mir genauso umgesetzt. In der DMZ läuft der kostenlose Hmailserver und der Exchange pollt permanent mit PopCon und der Exchange steht im LAN.
Abgehend fungiert der Hmailserver als Relay für den Exchange.
Läuft seit Jahr und Tag ohne Probleme.
Für welche Zwecke nutzt du den Hmailserver genau? Bietet er eine Spam und Antivirscanfunktion oder welcher Zweck hat er genau? Irgendwas muss er ja mit den Mails prüfen wenn er in der DMZ steht bevor sie weiter in das LAN weitergeleitet werden dürfen oder?
Wie genau sieht die Routerkonfiguration bei dir noch aus? Ich habe auch vor alles intern zu hosten. Also SMTP Proxy und der Exchange.
Muss ich lediglich ein Portforwarding mit Port 25 auf den SMTP Proxy einrichten oder bedarf es noch mehr Konfigurationen, sodass der Mailincoming und outcoming einwandfrei funktioniert. Was hast du bei dir alles konfiguriert? Und wie hast du DNS Einträge eingetragen. Reverse DNS und SPF Einträge, wie werden die konfiguriert?
Sorry für die vielen Fragen auf einmal. Aber ich habe genau den gleichen Plan alles intern zu hosten, daher wäre es super wenn ich ein bisschen Tips von jemandem bekomme, der gleiche Konstellation bereits schon hat
Grüsse
Noch eine generelle Frage zu dem Thema SSL Zertifikat.
Ist es möglich das bereits bestehende gekaufe und geprüfte SSL Zertifikat zu nutzen, welches auch für die Firmenwebseite benutzt wird?
Oder benötigt man dann für den Mailserver ein eigenständiges neues SSL Zertifikat?
Ist es möglich das bereits bestehende gekaufe und geprüfte SSL Zertifikat zu nutzen, welches auch für die Firmenwebseite benutzt wird?
Oder benötigt man dann für den Mailserver ein eigenständiges neues SSL Zertifikat?
Spam und Virencheck kann zwar der HMailserver, aber ich hab ne gute Firewall (Checkpoint) und auf dem Exchange, sowie den Endpoints läuft McAfee. Bisher hat es da noch keiner durch geschafft.
Mit meiner alten Firewall (Cisco ASA) hatte ich noch das Greylisting auf dem HMailserver aktiviert. Das hilft gegen Spam mehr als die meisten Filter, aber verzögert halt die E-Mail zustellung. Ansonsten kann der HMailserver auch alles was ein aktueller Spamfilter können muss.
Ich nutze den HMailserver aus 2 Gründen.
1. Als Relay und Puffer für ein und ausgehende E-Mails um den Exchange auch mal während der Arbeitszeit neu starten, bzw. warten zu können.
2. Für alle Serviceaccounts, die E-Mail verwenden. Das spart Lizenzen auf dem Exchange.
Nach Aussen brauchst du nur den MX Eintrag auf deine öffentliche IP im öffentlichen DNS. Im internen DNS arbeite ich mit Aliasen.
mail-intern.domain.local für den Exchange im LAN und mail-extern.domain.local für den HMailserver in der DMZ.
Bei deinem SSL Zertifikat kommt es adrauf an, was für eines es ist. Hast du n Wildcardzertifikat mit *.mymaildomain.de und die öffentliche Ip ist die gleiche wie dein Webserver dann funktioniert es. Sonst brauchst du n zusätzliches Zertifikat.
An deinem Router/Firewall musst du natürlich den Port 25 auf den HMailserver forwarden und dem Exchange im LAN das SMTP bzw. POP3 in die DMZ erlauben.
Ich hoffe es hilft dir etwas weiter.
Mit meiner alten Firewall (Cisco ASA) hatte ich noch das Greylisting auf dem HMailserver aktiviert. Das hilft gegen Spam mehr als die meisten Filter, aber verzögert halt die E-Mail zustellung. Ansonsten kann der HMailserver auch alles was ein aktueller Spamfilter können muss.
Ich nutze den HMailserver aus 2 Gründen.
1. Als Relay und Puffer für ein und ausgehende E-Mails um den Exchange auch mal während der Arbeitszeit neu starten, bzw. warten zu können.
2. Für alle Serviceaccounts, die E-Mail verwenden. Das spart Lizenzen auf dem Exchange.
Nach Aussen brauchst du nur den MX Eintrag auf deine öffentliche IP im öffentlichen DNS. Im internen DNS arbeite ich mit Aliasen.
mail-intern.domain.local für den Exchange im LAN und mail-extern.domain.local für den HMailserver in der DMZ.
Bei deinem SSL Zertifikat kommt es adrauf an, was für eines es ist. Hast du n Wildcardzertifikat mit *.mymaildomain.de und die öffentliche Ip ist die gleiche wie dein Webserver dann funktioniert es. Sonst brauchst du n zusätzliches Zertifikat.
An deinem Router/Firewall musst du natürlich den Port 25 auf den HMailserver forwarden und dem Exchange im LAN das SMTP bzw. POP3 in die DMZ erlauben.
Ich hoffe es hilft dir etwas weiter.
Zitat von @Saftnase:
Ich nutze den HMailserver aus 2 Gründen.
1. Als Relay und Puffer für ein und ausgehende E-Mails um den Exchange auch mal während der Arbeitszeit neu starten, bzw. warten zu können.
Ich nutze den HMailserver aus 2 Gründen.
1. Als Relay und Puffer für ein und ausgehende E-Mails um den Exchange auch mal während der Arbeitszeit neu starten, bzw. warten zu können.
Ist eigentlich nicht notwendig. Wenn dein Exchange nicht verfügbar ist. dann wird einfach später eine erneute Zustellung versucht.
Das ist auch das Grundprinzip von Graylisting.
Mich würd das Konstrukt mit PopCon einfach stören. Einfach eine Schnittstelle die nicht sein muss und Probleme verursachen könnte.
Hallo,
Wen keine statische IP da ist einfach ein guten DDNS-Dienst (np-ip ist die schlechteste Wahl -.-) nutzen und den DDNS-Hostnamen als mx eintragen und gut ist.
Zum senden bräuchtest du dann alerdings immer noch ein smathost weil du sonst nur SPAM versendest (nun ja die anderen denken es währe SPAM weil im HELO des SMTP Servers ein Reverse-DNS tauglicher dns-name sein muss. Soll heißen das was beim reverse dns raus kommt muss mit den Helo im SMTP stimmen. Und das ändert sich bei jeden wechsel der IP) also ein Server (vserver sollten auch gehen) mieten der dann ein SMTP Dienst mit Relay offen hat.
So, nun kommts: Die SPAM Falle. Der SMTP darf NICHT OFFEN sein. Also Autentifizierung einschalten so dass jeder der mailen will (in deinen Fall nur der Exchange Server) benutzer und passwort eingeben muss.
Also auf deinem Exchange Server ein Send Connector erstellen / den bestehenden bearbeiten so dass die zuvor gewählten Credentials (Username und Passwort) mit dem auf den SMTP Server der als Smathost dienen soll übereinstimmen.
Und fertig ist der Exchange der es richtig macht und die mails selber bekommt.
Gruß an die IT-Welt,
J Herbrich
Wen keine statische IP da ist einfach ein guten DDNS-Dienst (np-ip ist die schlechteste Wahl -.-) nutzen und den DDNS-Hostnamen als mx eintragen und gut ist.
Zum senden bräuchtest du dann alerdings immer noch ein smathost weil du sonst nur SPAM versendest (nun ja die anderen denken es währe SPAM weil im HELO des SMTP Servers ein Reverse-DNS tauglicher dns-name sein muss. Soll heißen das was beim reverse dns raus kommt muss mit den Helo im SMTP stimmen. Und das ändert sich bei jeden wechsel der IP) also ein Server (vserver sollten auch gehen) mieten der dann ein SMTP Dienst mit Relay offen hat.
So, nun kommts: Die SPAM Falle. Der SMTP darf NICHT OFFEN sein. Also Autentifizierung einschalten so dass jeder der mailen will (in deinen Fall nur der Exchange Server) benutzer und passwort eingeben muss.
Also auf deinem Exchange Server ein Send Connector erstellen / den bestehenden bearbeiten so dass die zuvor gewählten Credentials (Username und Passwort) mit dem auf den SMTP Server der als Smathost dienen soll übereinstimmen.
Und fertig ist der Exchange der es richtig macht und die mails selber bekommt.
Gruß an die IT-Welt,
J Herbrich
Zitat von @Herbrich19:
Hallo,
Wen keine statische IP da ist einfach ein guten DDNS-Dienst (np-ip ist die schlechteste Wahl -.-) nutzen und den DDNS-Hostnamen als mx eintragen und gut ist.
Zum senden bräuchtest du dann alerdings immer noch ein smathost weil du sonst nur SPAM versendest (nun ja die anderen denken es währe SPAM weil im HELO des SMTP Servers ein Reverse-DNS tauglicher dns-name sein muss. Soll heißen das was beim reverse dns raus kommt muss mit den Helo im SMTP stimmen. Und das ändert sich bei jeden wechsel der IP) also ein Server (vserver sollten auch gehen) mieten der dann ein SMTP Dienst mit Relay offen hat.
So, nun kommts: Die SPAM Falle. Der SMTP darf NICHT OFFEN sein. Also Autentifizierung einschalten so dass jeder der mailen will (in deinen Fall nur der Exchange Server) benutzer und passwort eingeben muss.
Also auf deinem Exchange Server ein Send Connector erstellen / den bestehenden bearbeiten so dass die zuvor gewählten Credentials (Username und Passwort) mit dem auf den SMTP Server der als Smathost dienen soll übereinstimmen.
Und fertig ist der Exchange der es richtig macht und die mails selber bekommt.
Gruß an die IT-Welt,
J Herbrich
Hallo,
Wen keine statische IP da ist einfach ein guten DDNS-Dienst (np-ip ist die schlechteste Wahl -.-) nutzen und den DDNS-Hostnamen als mx eintragen und gut ist.
Zum senden bräuchtest du dann alerdings immer noch ein smathost weil du sonst nur SPAM versendest (nun ja die anderen denken es währe SPAM weil im HELO des SMTP Servers ein Reverse-DNS tauglicher dns-name sein muss. Soll heißen das was beim reverse dns raus kommt muss mit den Helo im SMTP stimmen. Und das ändert sich bei jeden wechsel der IP) also ein Server (vserver sollten auch gehen) mieten der dann ein SMTP Dienst mit Relay offen hat.
So, nun kommts: Die SPAM Falle. Der SMTP darf NICHT OFFEN sein. Also Autentifizierung einschalten so dass jeder der mailen will (in deinen Fall nur der Exchange Server) benutzer und passwort eingeben muss.
Also auf deinem Exchange Server ein Send Connector erstellen / den bestehenden bearbeiten so dass die zuvor gewählten Credentials (Username und Passwort) mit dem auf den SMTP Server der als Smathost dienen soll übereinstimmen.
Und fertig ist der Exchange der es richtig macht und die mails selber bekommt.
Gruß an die IT-Welt,
J Herbrich
Hallo,
danke für die Info., statisch IP ist vorhanden.
Also ich habe vor einen SMTP-Proxy vor den Exchange zu stellen. Dieser kann auch als Smarthost agieren laut Hersteller.
Dann sollte es ja kein Problem sein wenn ich bei meinem DNS Hoster einen DNS und Reverse DNS für den SMTP-Proxy einstelle oder?
Der SMTP Proxy ist von scrollout f1 und beeinhaltet soweit ich sehe eine Postfix Instanz. Eigentlich ist der Einsatzzweck dieser Software für reines SPAM und Virenscanning.
Gruss
Hallo.
Was du als SMTP Proxy einsetzt ist eig fast egal. Und ja eine Static-IP macht die Sache wesendlich leichter da du nichts weiter machen musst als DNS und den Reverse DNS PTR zu konfigurieren.
Gruß an die IT-Welt,
J Herbrich
Was du als SMTP Proxy einsetzt ist eig fast egal. Und ja eine Static-IP macht die Sache wesendlich leichter da du nichts weiter machen musst als DNS und den Reverse DNS PTR zu konfigurieren.
Gruß an die IT-Welt,
J Herbrich
