Jump to content
Shady17

EHLO FQDN Empfangsconnector

Recommended Posts

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!

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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

 

Habe nur DNS Roundrobin im Einsatz, mehr nicht.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Edited by NorbertFe

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Werbepartner:



×
×
  • Create New...