9
Exchange leitet interne Mails nach extern weiter
Hallo liebe Community,
nach 2 Tagen basteln, verzweifle ich am Mail Relayen mit Exchange 2010
Hallo,
ich versuche meinen Exchange Server einzurichten.
Ist Zustand:
Der Server hat eine dynamische IP, auf die jedoch eine feste IP geroutet wird (sollte aber für das Problem nicht wichtig sein)
Auf dem Server laufen:
eine Domain, die auch dort sein soll
ein GMX Konto
ein T-Online Konto
Alle Mails werden über einen Smarthost versendet, was ich durch einen einfachen SendConnector für alle SMTP Adresse über Smarthost gelöst habe. Dies funktioniert soweit auch gut.
Alle Konten können normal Mails versenden und empfangen außer untereinander. Ich weis nicht warum der Exchange eine Mail, die vom GMX Konto an diese interne Domain geht, trotzdem über den Smarthost nach extern relayed und dann natürlich wieder selbst zugestellt bekommt. Das wäre mir auch noch egal, wenn die Mail dann ankommen würde. Tut sie aber nicht, da der Exchange die Mail erneut über den Smarthost versendet, und nach 3 Versuchen natürlich einen Loop detectet.
Die Domain ist in "Accepted Domains" natürlich eingetragen.
Wer kann mir helfen, das Problem weiter zu debuggen? Oder überhaupt einen Lösungsansatz geben?
Vielen vielen Dank schon mal im Voraus
Terminatorthree
nach 2 Tagen basteln, verzweifle ich am Mail Relayen mit Exchange 2010
Hallo,
ich versuche meinen Exchange Server einzurichten.
Ist Zustand:
Der Server hat eine dynamische IP, auf die jedoch eine feste IP geroutet wird (sollte aber für das Problem nicht wichtig sein)
Auf dem Server laufen:
eine Domain, die auch dort sein soll
ein GMX Konto
ein T-Online Konto
Alle Mails werden über einen Smarthost versendet, was ich durch einen einfachen SendConnector für alle SMTP Adresse über Smarthost gelöst habe. Dies funktioniert soweit auch gut.
Alle Konten können normal Mails versenden und empfangen außer untereinander. Ich weis nicht warum der Exchange eine Mail, die vom GMX Konto an diese interne Domain geht, trotzdem über den Smarthost nach extern relayed und dann natürlich wieder selbst zugestellt bekommt. Das wäre mir auch noch egal, wenn die Mail dann ankommen würde. Tut sie aber nicht, da der Exchange die Mail erneut über den Smarthost versendet, und nach 3 Versuchen natürlich einen Loop detectet.
Die Domain ist in "Accepted Domains" natürlich eingetragen.
Wer kann mir helfen, das Problem weiter zu debuggen? Oder überhaupt einen Lösungsansatz geben?
Vielen vielen Dank schon mal im Voraus
Terminatorthree
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: 155381
Url: https://administrator.de/contentid/155381
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
wie sind denn die Einstellungen der "akzeptierten Domäne" ?
Autorisierend, internes relay oder externes relay?...
Gruß,
Ole
wie sind denn die Einstellungen der "akzeptierten Domäne" ?
Autorisierend, internes relay oder externes relay?...
Gruß,
Ole
Hallo,
ich arbeite mit Termi3 zusammen, antworte also einmal an seiner Stelle.
Die akzeptierte Domain steht auf Authoritative, ist also kein interners oder externes relay.
Viele Grüße,
Rev.
ich arbeite mit Termi3 zusammen, antworte also einmal an seiner Stelle.
Die akzeptierte Domain steht auf Authoritative, ist also kein interners oder externes relay.
Viele Grüße,
Rev.
Hallo revage,
ein Log aus dem MessageTracking
C:ProgrammeMicrosoftExchange ServerV14TransportRolesLogsMessageTracking<MSGTRKyyyymmdd.log
könnte zur Aufklärung helfen.
Wie ist denn der Nachrichtenfluss des Servers? Sprich, wie werden E-Mails an der Exchange Server zugestellt? Mittels SMTP direkt oder per 3rd Party tool (z.B. Popbeamer, popcon...)?
Ole
ein Log aus dem MessageTracking
C:ProgrammeMicrosoftExchange ServerV14TransportRolesLogsMessageTracking<MSGTRKyyyymmdd.log
könnte zur Aufklärung helfen.
Wie ist denn der Nachrichtenfluss des Servers? Sprich, wie werden E-Mails an der Exchange Server zugestellt? Mittels SMTP direkt oder per 3rd Party tool (z.B. Popbeamer, popcon...)?
Ole
Hi,
Logs werden nachher nachgeliefert, da ich momentan keinen Zugriff auf den Exchange habe.
Der Nachrichtenfluss sieht vereinfacht wie folgt aus:
Der Exchange ist über ein VPN mit einem externen Server verbunden, auf dem auch das Postfix Mail Gateway läuft. Dieser externe Server hat zwei öffentliche IPs. Eine zeigt direkt auf das Gateway, die andere wird über das VPN an den Exchange "durchgereicht".
Der MX-Record der auf dem Exchange gehosteten Domain zeigt direkt auf die durchgereichte IP. Sendet z.B. ein Gmx Konto von dem Exchange eine Mail an die gehostete Domain, wird diese an das Gateway weitergereicht. Dieses ermittelt anhand des MX-Records die durchgereichte IP des Exchange-Servers als Ziel.
Dort kommt sie auch an, nur mag der Exchange die Mail nicht behalten und stellt diese wieder an den Postfix zu, und so weiter.
Um deine Frage also zu beantworten, der Exchange bekommt die Mail direkt per SMTP zugestellt.
Theoretisch könnte der Postfix auch als aus- und eingehendes Gateway konfiguriert werden, so dass der Exchange die Mail nur an den Postfix sendet, und von diesem auch wieder zugestellt bekommt.
Ob dies das Problem allerdings löst wage ich allerdings zu bezweifeln
Viele Grüße,
Rev.
Logs werden nachher nachgeliefert, da ich momentan keinen Zugriff auf den Exchange habe.
Der Nachrichtenfluss sieht vereinfacht wie folgt aus:
Der Exchange ist über ein VPN mit einem externen Server verbunden, auf dem auch das Postfix Mail Gateway läuft. Dieser externe Server hat zwei öffentliche IPs. Eine zeigt direkt auf das Gateway, die andere wird über das VPN an den Exchange "durchgereicht".
Der MX-Record der auf dem Exchange gehosteten Domain zeigt direkt auf die durchgereichte IP. Sendet z.B. ein Gmx Konto von dem Exchange eine Mail an die gehostete Domain, wird diese an das Gateway weitergereicht. Dieses ermittelt anhand des MX-Records die durchgereichte IP des Exchange-Servers als Ziel.
Dort kommt sie auch an, nur mag der Exchange die Mail nicht behalten und stellt diese wieder an den Postfix zu, und so weiter.
Um deine Frage also zu beantworten, der Exchange bekommt die Mail direkt per SMTP zugestellt.
Theoretisch könnte der Postfix auch als aus- und eingehendes Gateway konfiguriert werden, so dass der Exchange die Mail nur an den Postfix sendet, und von diesem auch wieder zugestellt bekommt.
Ob dies das Problem allerdings löst wage ich allerdings zu bezweifeln
Viele Grüße,
Rev.
Hallo,
erstmal vielen Dank für die Antworten. Das Log werde ich heute abend nachliefern, wenn ich an den Server komme.
Die Mails für GMX und T-Online werden per POPCollector abgeholt und dann lokal per SMTP zugestellt. Die Domain empfängt ihre Mails direkt (Das geht ja auch wunderbar, nur eben untereinander nicht)
Ich freue mich auf alle weiteren Antworten.
Grüße
Terminatorthree
erstmal vielen Dank für die Antworten. Das Log werde ich heute abend nachliefern, wenn ich an den Server komme.
Die Mails für GMX und T-Online werden per POPCollector abgeholt und dann lokal per SMTP zugestellt. Die Domain empfängt ihre Mails direkt (Das geht ja auch wunderbar, nur eben untereinander nicht)
Ich freue mich auf alle weiteren Antworten.
Grüße
Terminatorthree
Hallo zusammen,
schön, so kann zunächst ausgeschlossen werden, dass der Nachrichtenfluss diesbezüglich gestört ist.
Folgendermaßen, um es einmal trivial auszudrücken ist der Soll-Zustand des Nachrichtenfluss intern:
1 Ein Anwender verschickt über Outlook seine Mail.
2 Client speichert die Mail im Postausgang.
3 Der Postfachserver erkennt die Mail, benachrichtigt Hub-Transport-Server am Standort
(In euerm Fall hat der Exchange Server alle Rollen inne)
4 Der Categorizer versucht den Empfänger im AD aufzulösen oder entscheidet auf der Basis,
ob es sich um einen internen/externen Empfänger handelt
(Euer Empfänger hat ein Benutzerobjekt im AD in der Organisation, euer Empfänger besitzt ein Postfach in der Organisation)
5 Deshalb löst der Categorizer den Empfänger intern auf
6 Es werden Transportregeln/Journalregeln angewandt, falls vorhanden
7 Mail wird in die Übermittlungswarteschlange gestellt
8 Hub-Transport-Server übermittelt die Mail per MAPI an Postfachserver des Empfängers
(In diesem Fall gleiche Exchange Server, da Server die Rollen inne hat)
Soweit so klar!?, soll heißen, das Problem liegt intern, genauer, auf eurem Exchange Server.
Logs wären nett, ansonsten gilt:
- Akzeptierte Domäne überprüfen
- Sendeconnectoren überprüfen
- Best-Practise-Analyzer verwenden
- Nachrichtenfluss mittels telnet per SMTP starten und mit Logs überprüfen
- Anwendungsprotokolle in Ereignisanzeige überprüfen
- Warteschlange überprüfen
schön, so kann zunächst ausgeschlossen werden, dass der Nachrichtenfluss diesbezüglich gestört ist.
Folgendermaßen, um es einmal trivial auszudrücken ist der Soll-Zustand des Nachrichtenfluss intern:
1 Ein Anwender verschickt über Outlook seine Mail.
2 Client speichert die Mail im Postausgang.
3 Der Postfachserver erkennt die Mail, benachrichtigt Hub-Transport-Server am Standort
(In euerm Fall hat der Exchange Server alle Rollen inne)
4 Der Categorizer versucht den Empfänger im AD aufzulösen oder entscheidet auf der Basis,
ob es sich um einen internen/externen Empfänger handelt
(Euer Empfänger hat ein Benutzerobjekt im AD in der Organisation, euer Empfänger besitzt ein Postfach in der Organisation)
5 Deshalb löst der Categorizer den Empfänger intern auf
6 Es werden Transportregeln/Journalregeln angewandt, falls vorhanden
7 Mail wird in die Übermittlungswarteschlange gestellt
8 Hub-Transport-Server übermittelt die Mail per MAPI an Postfachserver des Empfängers
(In diesem Fall gleiche Exchange Server, da Server die Rollen inne hat)
Soweit so klar!?, soll heißen, das Problem liegt intern, genauer, auf eurem Exchange Server.
Logs wären nett, ansonsten gilt:
- Akzeptierte Domäne überprüfen
- Sendeconnectoren überprüfen
- Best-Practise-Analyzer verwenden
- Nachrichtenfluss mittels telnet per SMTP starten und mit Logs überprüfen
- Anwendungsprotokolle in Ereignisanzeige überprüfen
- Warteschlange überprüfen
Hallo,
erstmal Danke für deinen ausführlichen Kommentar.
Ich stimme, was die Abarbeitung der Mail angeht, vollkommen mit dir überein.
Wenn ich die Liste jetzt mal Schritt für Schritt durchgehe:
1. Ist klar.
2. Auch
3. Auch
4. /5. Genau da bin ich mir nicht so sicher. Klar sollte er versuchen den Empfänger intern aufzulösen. Aber anscheinend erkennt er den Empfänger eben nicht als intern. Anders kann ich mir nicht erklären warum die Mail über extern relayed wird.
Könntest du etwas genauer beschreiben, wie meine SendConnectoren aussehen müssten und worauf ich achten sollte? Ich werde heute abend, wenn ich an den Server komme mal meine vorhandenen genau aufschreiben, denn ich denke, das hier schon der Fehler zu suchen ist.
Akzeptierte Domains hab ich geprüft
SendConnctoren werd ich nochmal genau anschauen und hier posten
Best-Practise-Analyzer kannte ich noch gar nicht, werde ich mir also auf jeden Fall angucken
Nachrichtenfluss per Telnet haben wir uns angeguckt, auch mit Hilfe der Postfix Logs, nur wir finden den Grund einfach nicht, warum der Exchange die Mail erneut raussendet.
Anwendungsprotokolle und Ereigenisanzeige sind definitiv auch heute abend dran
In der Warteschlange sehe ich, das auch die internet Mail immer wieder in der Smarthost-Warteschlage eintrifft und versendet wird.
Also nochmals vielen Dank für deine Hilfe, und heute abend kann ich hoffentlich auch mehr Input liefern.
Grüße
Terminatorthree
erstmal Danke für deinen ausführlichen Kommentar.
Ich stimme, was die Abarbeitung der Mail angeht, vollkommen mit dir überein.
Wenn ich die Liste jetzt mal Schritt für Schritt durchgehe:
1. Ist klar.
2. Auch
3. Auch
4. /5. Genau da bin ich mir nicht so sicher. Klar sollte er versuchen den Empfänger intern aufzulösen. Aber anscheinend erkennt er den Empfänger eben nicht als intern. Anders kann ich mir nicht erklären warum die Mail über extern relayed wird.
Könntest du etwas genauer beschreiben, wie meine SendConnectoren aussehen müssten und worauf ich achten sollte? Ich werde heute abend, wenn ich an den Server komme mal meine vorhandenen genau aufschreiben, denn ich denke, das hier schon der Fehler zu suchen ist.
Akzeptierte Domains hab ich geprüft
SendConnctoren werd ich nochmal genau anschauen und hier posten
Best-Practise-Analyzer kannte ich noch gar nicht, werde ich mir also auf jeden Fall angucken
Nachrichtenfluss per Telnet haben wir uns angeguckt, auch mit Hilfe der Postfix Logs, nur wir finden den Grund einfach nicht, warum der Exchange die Mail erneut raussendet.
Anwendungsprotokolle und Ereigenisanzeige sind definitiv auch heute abend dran
In der Warteschlange sehe ich, das auch die internet Mail immer wieder in der Smarthost-Warteschlage eintrifft und versendet wird.
Also nochmals vielen Dank für deine Hilfe, und heute abend kann ich hoffentlich auch mehr Input liefern.
Grüße
Terminatorthree
Hallo,
durch meine Erklärung des Nachrichtenflusses müsste dir aufgefallen sein,
dass in deinem Fall gar kein Relay gebraucht wird, bzw. beim Nachrichtenfluss
nicht auf den Sendeconnector zurückgegriffen wird, da die Übermittlung von Hub-Transport
zum Postfachserver per MAPI über eine RPC-Verbindung stattfindet.
Dabei kommen die oder der Sendeconnector der Organisation gar nicht zum Einsatz.
Du könntest in diesem Fall aus Testzwecken den Sendeconnector deaktivieren oder löschen,
da der Nachrichtenfluss nicht per SMTP, sondern per MAPI über RPC stattfinden soll/muss.
Deshalb kannst du von dieser Konfiguration die Finger lassen, da es sich wohl um ein Auflösungsproblem handelt, da der Categorizer den Benutzer mit entsprechender E-Mail im AD nicht richtig auflöst.
Ich bin auf den Log gespannt...
Datei: MSGTRK*yyyymmdd-1.LOG
durch meine Erklärung des Nachrichtenflusses müsste dir aufgefallen sein,
dass in deinem Fall gar kein Relay gebraucht wird, bzw. beim Nachrichtenfluss
nicht auf den Sendeconnector zurückgegriffen wird, da die Übermittlung von Hub-Transport
zum Postfachserver per MAPI über eine RPC-Verbindung stattfindet.
Dabei kommen die oder der Sendeconnector der Organisation gar nicht zum Einsatz.
Du könntest in diesem Fall aus Testzwecken den Sendeconnector deaktivieren oder löschen,
da der Nachrichtenfluss nicht per SMTP, sondern per MAPI über RPC stattfinden soll/muss.
Deshalb kannst du von dieser Konfiguration die Finger lassen, da es sich wohl um ein Auflösungsproblem handelt, da der Categorizer den Benutzer mit entsprechender E-Mail im AD nicht richtig auflöst.
Ich bin auf den Log gespannt...
Datei: MSGTRK*yyyymmdd-1.LOG
Eben genau das meine ich ja. Eigentlich dürfte der SendConnector gar nicht zum Einsatz kommen. Genau das tut er aber und ich weis einfach nicht warum.
Ich könnte dir an dieser Stelle jetzt ein Log posten aber ich glaube ich setze lieber den gelöst Haken, denn du bist mein Held des Tages.
In dem Log stand nämlich der Hinweis, dass ein uralter Transport Agend /Routing Agend (selbst geschrieben in C#) aktiv war. Der war schuld an allem. Einfach entfernt und schon gehts. Ich kann dir einfach nicht genug danken.
Ganz freudige Grüße
Terminatorthree
Ich könnte dir an dieser Stelle jetzt ein Log posten aber ich glaube ich setze lieber den gelöst Haken, denn du bist mein Held des Tages.
In dem Log stand nämlich der Hinweis, dass ein uralter Transport Agend /Routing Agend (selbst geschrieben in C#) aktiv war. Der war schuld an allem. Einfach entfernt und schon gehts. Ich kann dir einfach nicht genug danken.
Ganz freudige Grüße
Terminatorthree
