EHLO FQDN Empfangsconnector

[Shady17 0]

Hey Ho

 

Ich betreibe 2 Exchange 2016 CU11 in einer DAG.

 

Die Exchange-Server senden beide direkt (ohne Smarthost) ins Internet und empfangen auch direkt (ohne POP3-Connector) per SMTP. Beide Server haben eine feste IP über NAT.

 

Leider antworten beide Server per EHLO mit dem internen Hostnamen. Sie sollen aber mit dem externen Namen antworten. Im Sendeconnector war das ändern kein Problem aber beim Empfangsconnector für Port 25 funktioniert es nicht. Ich weiß, dass es an der Authentifizierung von Exchange Server liegt und ich den Haken entfernen muss um den FQDN zu ändern. Da ich aber zwei Server habe, kann ich diesen Haken nicht einfach entfernen.

 

Wie kann ich das Problem lösen, was ist die Best Practice?

 

Zweite Frage:

 

Habe im öffentlichen DNS derzeit zwei MX-Records. Jeder Server hat sozusagen einen MX-Eintrag. Ist es besser, wenn ich nur einen MX-Eintrag erstelle, aber beide IPs von den Exchange-Servern hinterlege? Was ist der unterschied zwischen:

 

MX.domain.de -- IP1 + IP2, Prio 50

Oder

MX1.domain.de -- IP1, Prio 50

MX2.domain.de -- IP2, Prio 50

 

Danke euch!

 

[NorbertFe 2.035]

vor 2 Minuten schrieb Shady17:

Wie kann ich das Problem lösen, was ist die Best Practice?

Default Frontendconnector bearbeiten und in die IPv4 Remote Adressen _nur_ die eigenen internen IP Bereiche eintragen. Danach eigenen Receiveconnector (FrontEnd) anlegen (Internet). Nur Anonyme ANmeldungen zulassen. Logging aktivieren, EHLO anpassen. Fertig.

Bye

Norbert

Hast du nur zwei Server ohne Loadbalancer?

[Shady17 0]

Danke für die schnelle Antwort.

 

Leider funktioniert das nicht. Beim erstellen des neuen Connectors mahnt er die Portbindung auf Port 25 an, da dies schon im Default Connector eingestellt ist. Somit kann ich keinen neuen erstellen (Netzwerkadapterbindung)

[NorbertFe 2.035]

Man könnte ja auch einfach mal lesen, was als Antwort und in welcher Reihenfolge geschrieben wurde.

[Shady17 0]

Sry. Hat jetzt funktioniert. Vielen Dank!

 

Hast du noch einen Tipp bezgl meiner MX-Frage?

[NorbertFe 2.035]

Du beantwortest meine ja auch nicht. ;) Also hast du einen Loadbalancer? Dann würde sich deine Frage nämlich gar nicht erst ergeben. Ansonsten zeigt ein mx immer auf einen A-Record, ich würde also der "Übersichtlichkeit" wegen zwei MX mit der selben Prio anlegen. Ausnahme du hast einen Loadbalancer. :)

[Shady17 0]

Die Frage mit dem Loadbalancer hast du aber nachträglich hinzugefügt oder? :-D

 

Habe nur DNS Roundrobin im Einsatz, mehr nicht.

[NorbertFe 2.035]

Ja ca. 2 sekunden nachdem ich meine ursprüngliche Antwort geschrieben habe. Antwort auf deine Frage hast du ja. Round Robin und DAG ist alles ausser empfohlen. :) Ich würd mir mal eine der verschiedenen LB Lösungen anschauen, wenn das nicht nur ein Testfeld ist über das du hier schreibst.

[Shady17 0]

Nein ist kein Testfeld. Bin damit über mehrere Jahre sehr gut gefahren (auch wenn ein Server ausgefallen ist, bzw. waren auch beide immer gleichmäßig ausgelastet). Oder was meinst du genau? Aber klar, ich schau mir die LB-Lösungen gerne Mal an.

[NorbertFe 2.035]

Round Robin ist ne rein clientseitige Entscheidung und die kann man in größeren Umgebungen schlecht steuern. Nur über TTL ist das eben auch nur bedingt sinnvoll. Da es für jede Preisklasse auch Loadbalancer gibt, würde ich freiwillig nie auf die Idee für Round Robin kommen. :)

 

Viel Erfolg

Norbert

[magheinz 110]

Roundrobin für MXe ist nicht zu empfehlen.

Einfach alle mit gleicher Priorität im DNS anlegen und ein Absender der mehrere E-Mails einliefern will kann direkt selber loadbalancen. Außerdem ist dann der Ausfall eines Server z.B. wegen updates, kein Problem da ja der anderen noch erreichbar ist.

Bei RR kann man theoretisch Pech haben und immer auf dem gerade nicht funktionierenden landen.

 

Loadbalancer machen für SMTP nur unter einigen bestimmten Umständen überhaupt Sinn.

[NorbertFe 2.035]

vor 3 Minuten schrieb magheinz:

Loadbalancer machen für SMTP nur unter einigen bestimmten Umständen überhaupt Sinn.

Und die wären? Man hat mehr relays als man mx anlegen will? ;)

das obige bzgl. Loadbalancer bezieht sich eigentlich auf die Verwendung einer dag, die direkt die Mails annehmen soll. Und da wäre meiner Meinung nach ein loadbalancer auch für smtp sinnvoll. Hat man vorgeschaltete relays (bspw. Edge) dann natürlich mehrere mx.

bearbeitet 10. Februar 2019 von NorbertFe

[magheinz 110]

Z.B. wenn es um Geo-Loadbalaning geht oder ein Filter vor dem Exchange hängt der nicht den MX abfragt oder man LB- Algorithmen nutzen möchte, welche über die Priorisierung hinausgehen, welche auch immer.

Auch bei einer DAG habe ich ja zwei unabhängig funktionierende SMTP-Server. Die DAG-Funktionalität ist ja nur für die Postfachdatenbank zuständig. Wieso hier also ein LB?

[NorbertFe 2.035]

Wieso nicht? Üblicherweise stehen die exchangeserver hinter einem loadbalancer und können/sollen nicht separat adressiert werden.

[magheinz 110]

LB macht ja auch für IMAP, POP3, HTTPS etc Sinn.

Für SMTP, vor allem für die MXe, aber eben im Regelfall nicht. Hier kann man das Loadbalancen direkt dem Absender überlassen.

• Durch die Priorisierung im DNS kann man schon Ausfallsicherheit und Lastverteilung abdecken.
• Man benötig LBs die nicht nur stumpf verteilen sondern z.B. auch SMTP-Fehler auswerten.  Ein einliefernder SMTP-Server z.B. kann mit einem Fehler wie 452, 450 etc etwas anfangen. Die meisten LBs werten das nicht aus und verbinden fleissig weiter an diesen SMTP-Server. Und selbst wenn der LB das kann? Wozu sollte man das Geld ausgeben wenn das Protokoll schon alles notwendige abdeckt?
• Gerade wer viele E-Mails empfängt wird merken, dass die meisten Absender schon auf die MXe verteilen.

 

LBs für alle anderen E-Mailprotokolle sind dagegen sinnvoll da man die Priorisierung leider im DNS für alle anderen Records vergessen hat.

Üblicherweise stehen die Echangeserver ja nicht nur hinter einem LB, sondern auch hinter einem Filter, Firewall etc.