none
Mails an bestimmte Domänen werden nicht zugestellt RRS feed

  • Frage

  • Hallo Zusammen,

    ich habe bei einem Kunden das Problem, das E-Mails an bestimmte Domänen nicht zugestellt werden.

    Folgende Konfiguration: Windows Server 2012 R2, Exchange 2013 CU 12 (Build 15.0.1178.4), alle aktuellen Patches installiert. Ausgehende Mails werden nicht gescannt, weder durch den Virenscanner auf dem Server noch von der vorgeschalteten Appliance.

    In der Warteschlage wird der folgende Fehler angezeigt: 451 4.4.0 SMTPSEND.SuspiciousRemoteServerError; remote server disconnected abruptly; retry will be delayed

    Leider hat der folgende TechNet-Artikel https://support.microsoft.com/de-de/kb/3038746 das Problem nicht behoben. Allen Domänen bei denen es Problem mit der Mailzustellung gibt, ist gemeinsam, dass sie TLS nicht unterstützen.

    Für eine ausgewählte Domäne habe ich - wie in dem Artikel beschrieben - einen Sendeconnector eingerichtet, der direkt auf die die IP-Adresse des empfangenden Mailservers zeigt und den Connector so konfiguriert, dass er kein TLS verwendet (-IgnoreSTARTTLS $true).

    Versuche ich per Telnet ein Mail an die ausgewählte Domäne zu verschicken, so kann die Verbindung problemlos aufgebaut werden. Beende ich den Versand der Mail mit "." (Punkt), dann wird die Mail nicht in die Warteschlange eingereiht, sondern ich erhalte den Hinweis "Verbindung zum Host verloren."

    Ich bin für jeden Hinweis dankbar.

    Mit freundlichen Grüße

    Christine Trzaska



    • Bearbeitet ChristineT1 Dienstag, 13. September 2016 16:28
    Dienstag, 13. September 2016 16:17

Antworten

  • Schön, noch mehr Details :-) Das könnte helfen. Analysieren wir's mal.

    Der Admin kann in seinen Protokollen erkennen, dass der Mailserver meines Kunden die Verbindung beendet (disconnect), was ja auch mit der Telnetmeldung "Verbindung zum Host verloren" übereinstimmt.

    Nun, nicht ganz - laut Originalpost kam die Disconnect-Meldung ja vom empfangenden Server? Das ist ein wichtiger Hinweis, dass beide das sehen.

    Für mich stellt sich die Frage, unter welchen Bedingungen kommt auf Seiten des sendenden Exchange der Fehler 451 4.4.0 (was auf einen DNS-Fehler hinweist) und auf Seiten des Empfängers ein vom sendenden Exchange initiierter Disconnect (was bedeutet, dass die DNS-Auflösung funktioniert hat, denn sonst wäre die Verbindung ja nicht zustande gekommen)?

    Genau, das hat damit zu tun, dass nicht alle DSNs eineindeutig einem Fehlerbild zugeordnet sind, so auch die 4.4.0. Und wie der Text im oben zitierten Fehlercode schon sagt, hat der Server auf der Gegenseite einfach unvermittelt aufgelegt - was ja auch das Telnet-Experiment bestätigt!

    Daher würde ich auch Exchange des Kunden schon mal ganz außer Acht lassen und mich darauf konzentrieren, dass ich eine Nachricht per Telnet durchkriege - was aus einem anderen Netzwerk ja nachweislich geht.

    In der Signalkette sind:

    • die Firewall des Kunden (ggfls. mehrere Schichten mit Transfernetzen dazwischen)
    • die Firewall der Behörde (ggfls. mehrere Schichten mit Transfernetzen dazwischen)
    • die Mail-Filtering-Appliance der Behörde
    • Mailserver der Behörde, wobei man diesen eigentlich auch ausschließen kann, denn die SMTP-Verbindung terminiert ja in aller Regel an der Appliance, und diese leitet die Mail dann als weiterer SMTP-Hop an den Mailserver weiter, nimmt sie aber erst mal vollständig an.

    Und jetzt betrachten wir noch den Sachverhalt, dass offenbar BEIDE Seiten einen Verbindungsabriss, augenscheinlich durch die Gegenseite, sehen. Das könnte darauf hin deuten, dass eine der beiden Firewalls für den Abriss verantwortlich ist. Und ich würde nach einer suchen, wo irgendeine "Absicherung" des SMTP-Protokolls eingeschaltet ist. Bei Cisco nennt sich das "SMTP Fixup", andere Hersteller haben für diesen Dreck andere Namen. Vermutlich - aber nicht gesichert - ist so etwas auf der Seite des Kunden zu suchen, denn daheim hat solche Schweinereien selten jemand, und von dort funktioniert's ja.

    Viel Spaß bei der Suche! Netzwerker sind immer zuvorkommend und stets bereit, Fehler in ihren Konfigurationen zuzugeben, das sollte also ein Klacks werden ;-)


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 20:19

Alle Antworten

  • Moin,

    erst mal ganz doof gefragt: Ist es eine gesicherte Erkenntnis, dass jene Domänen überhaupt Mail von außen kriegen?

    Falls ja: Wie sieht Dein SPF-Record aus? Ich meine, für it-service-ruhr.de sieht der Record z.B. so aus, dass nur Microsoft senden darf (http://mxtoolbox.com/SuperTool.aspx?action=spf%3ait-service-ruhr.de&run=toolpage) . Wenn Du also eine direkte Verbindung aufbaust und mit der Absenderadresse aus dieser Domain sendest, ist es ja auch verständlich, dass es abgewisen wird...


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 16:56
  • Hallo Evgenij Smirnov,

    vielen Dank für Deine Antwort. Doofe Fragen gibt es nicht, nur doofe Antworten.

    Ja, die Domäne kann problemlos E-Mails empfangen (große öffentliche Verwaltung). Die Absenderdomäne ist die Domäne meines Kunden und nicht meine eigene. Der SPF-Record ist für den Kunden nicht gesetzt und wird auch von der empfangenden Domäne nicht ausgewertet.

    Ich kann von meinem privaten Rechner per Telnet an dem Admin der empfangenden Domäne (admin@behoerde.de) mit der Absenderadresse des Admins meines Kunden (admin@kunde.de) E-Mails schicken. Von den Rechnern (weder vom Exchange noch von einem beliebigen Client) aus dem Netzwerk meines Kunden funktioniert es nicht - jede Filterung des ausgehenden Mailverkehrs habe ich schon deaktiviert.

    Dienstag, 13. September 2016 18:46
  • Moin,

    keinen SPF Record zu haben ist grundsätzlich nicht gut, auch wenn es in dem vorliegenden Fall offenbar wirklich keine Rolle spielt.

    So wie es aussieht, scheint die Behörde ja offenbar die IP-Adresse des Kunden nicht zu mögen. Wenn es eine Behörde ist, spricht man ja von extern sicher nicht mit Exchange, sondern mit irgendeiner vorgeschalteten Appliance. Mit dem Verwalter derselben muss man dann wohl sprechen. Vielleicht ist die IP-Adresse auf irgendeiner obskuren RBL gelandet (http://www.anti-abuse.org/multi-rbl-check/ , aber leider sind es nicht alle)...

    Hat der Kunde evtl. eine andere IP, mit der man es probieren könnte?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 19:09
  • Hallo Evgenij Smirnov,

    habe bereits mehrfach mit dem Mailadmin des Empfängers telefoniert. Mein Kunde steht auf keiner RBL, die dort benutzt wird. Der Admin kann in seinen Protokollen erkennen, dass der Mailserver meines Kunden die Verbindung beendet (disconnect), was ja auch mit der Telnetmeldung "Verbindung zum Host verloren" übereinstimmt.

    Für mich stellt sich die Frage, unter welchen Bedingungen kommt auf Seiten des sendenden Exchange der Fehler 451 4.4.0 (was auf einen DNS-Fehler hinweist) und auf Seiten des Empfängers ein vom sendenden Exchange initiierter Disconnect (was bedeutet, dass die DNS-Auflösung funktioniert hat, denn sonst wäre die Verbindung ja nicht zustande gekommen)?

    Dienstag, 13. September 2016 19:43
  • Schön, noch mehr Details :-) Das könnte helfen. Analysieren wir's mal.

    Der Admin kann in seinen Protokollen erkennen, dass der Mailserver meines Kunden die Verbindung beendet (disconnect), was ja auch mit der Telnetmeldung "Verbindung zum Host verloren" übereinstimmt.

    Nun, nicht ganz - laut Originalpost kam die Disconnect-Meldung ja vom empfangenden Server? Das ist ein wichtiger Hinweis, dass beide das sehen.

    Für mich stellt sich die Frage, unter welchen Bedingungen kommt auf Seiten des sendenden Exchange der Fehler 451 4.4.0 (was auf einen DNS-Fehler hinweist) und auf Seiten des Empfängers ein vom sendenden Exchange initiierter Disconnect (was bedeutet, dass die DNS-Auflösung funktioniert hat, denn sonst wäre die Verbindung ja nicht zustande gekommen)?

    Genau, das hat damit zu tun, dass nicht alle DSNs eineindeutig einem Fehlerbild zugeordnet sind, so auch die 4.4.0. Und wie der Text im oben zitierten Fehlercode schon sagt, hat der Server auf der Gegenseite einfach unvermittelt aufgelegt - was ja auch das Telnet-Experiment bestätigt!

    Daher würde ich auch Exchange des Kunden schon mal ganz außer Acht lassen und mich darauf konzentrieren, dass ich eine Nachricht per Telnet durchkriege - was aus einem anderen Netzwerk ja nachweislich geht.

    In der Signalkette sind:

    • die Firewall des Kunden (ggfls. mehrere Schichten mit Transfernetzen dazwischen)
    • die Firewall der Behörde (ggfls. mehrere Schichten mit Transfernetzen dazwischen)
    • die Mail-Filtering-Appliance der Behörde
    • Mailserver der Behörde, wobei man diesen eigentlich auch ausschließen kann, denn die SMTP-Verbindung terminiert ja in aller Regel an der Appliance, und diese leitet die Mail dann als weiterer SMTP-Hop an den Mailserver weiter, nimmt sie aber erst mal vollständig an.

    Und jetzt betrachten wir noch den Sachverhalt, dass offenbar BEIDE Seiten einen Verbindungsabriss, augenscheinlich durch die Gegenseite, sehen. Das könnte darauf hin deuten, dass eine der beiden Firewalls für den Abriss verantwortlich ist. Und ich würde nach einer suchen, wo irgendeine "Absicherung" des SMTP-Protokolls eingeschaltet ist. Bei Cisco nennt sich das "SMTP Fixup", andere Hersteller haben für diesen Dreck andere Namen. Vermutlich - aber nicht gesichert - ist so etwas auf der Seite des Kunden zu suchen, denn daheim hat solche Schweinereien selten jemand, und von dort funktioniert's ja.

    Viel Spaß bei der Suche! Netzwerker sind immer zuvorkommend und stets bereit, Fehler in ihren Konfigurationen zuzugeben, das sollte also ein Klacks werden ;-)


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 20:19