Jump to content

EHLO FQDN Empfangsconnector


Direkt zur Lösung Gelöst von NorbertFe,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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!

 

Link zu diesem Kommentar
  • Beste Lösung
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?

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
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 von NorbertFe
Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...