olc 18 Geschrieben 7. Juni 2007 Melden Teilen Geschrieben 7. Juni 2007 Hallo Leute, Exchange 2003 SP2 schmeißt mir bei diversen MXern bzw. Relays von externen Empfängern folgende Fehlermeldung: DCOM konnte mit dem Computer "MX-DNS-Name.de" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Scheinbar nutzen diese Empfänger Greylisting, um SPAM abzuwähren - zumindest scheint das bei allen "problematischen" Empfängern so zu sein, bei denen ich nachgefragt habe. Bei den Empfängern kommen unterschiedliche (Linux-) Mailserver zum Einsatz - es scheint also nicht an einem bestimmten Produkt zu hängen. Wenn ich mich per telnet auf die Relays der Empfänger verbinde, bekomme ich beim Kommando "RCPT TO:vorname.nachname@domain.de" zum Beispiel die Fehlermeldung "553 Bad command format". Ab und an auch eine Meldung, daß die spitzen Klammern <> fehlen. OK - das ist ja auch RFC-Konform... Wie sendet Exchange E-Mails per SMTP: Setzt Exchange die spitzen Klammern <> oder setzt Exchange diese standardmäßig nicht? Unter Umständen liegt es daran? Beim googeln und der Boardsuche konnte ich keine vernünftige Erklärung für das Problem finden - die DCOM Komponenten sind auf dem Server mit ziemlicher Sicherheit in Ordnung, denn 95% aller Mails können korrekt ausgeliefert werden. Des weiteren kommen die Mails durch, wenn die Empfänger das Greylisting für unsere MX-IP abschalten. Hat jemand von Euch eine Idee? Vielen Dank und viele Grüße olc Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 7. Juni 2007 Melden Teilen Geschrieben 7. Juni 2007 Hi. Wenn der Fehler wirklich durch Greylisting ausgelöst wird, dann wirst du denn kaum wegbringen. Die Meldung kommt wahrscheinlich zustande, weil Exchange eine korrekte SMTP Sitzung aufbaut, das Gegenüber dann feststellt dass das Triplet neu ist, und dann je nach Art des Greylisting die Antwort gibt, "Sorry ich habe eine temoräres Verbindungsproblem" oder einfach die Verbindung abbricht. Im ersteren Fall dürft dann der Fehler beim Exchange entstehen. Ein einfachsten überprüfst du das im LOG des virtuellen SMTP. Da der Exchange nach 10 Minuten (wenn daran nicht gedreht wurde) wieder versucht das Mail zu versenden, solltest du in den Log Files dann einen korrekten Verbindungsaufbau haben. Beim 2. Verbindungsaubau kennt ja das Greylisting Filter bereits das Triplet und nimmt die Mail korrekt an. LG Günther Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 7. Juni 2007 Autor Melden Teilen Geschrieben 7. Juni 2007 Hallo Günther, vielen Dank für Deine Antwort. Es ist richtig, was Du schreibst. Leider läuft jedoch der letzte Teil dann scheinbar nicht korrekt ab: Das Greylisting hat genau den von Dir beschriebenen Effekt, jedoch versucht der Exchange Server scheinbar nicht noch einmal, die Mail zuzustellen. Ich habe die Standardeinstellung des erneuten Zustellungsversuchs erst auf 10 Minuten gelassen, später dann testweise auf 15 Minuten gesetzt. Ohne Erfolg. Verwunderlich ist auch, daß überhaupt kein NDR erzeugt wird. D.h. der Absender bei uns bekommt keinen Unzustellbarkeitsbericht. Die Mail ist dann einfach "weg". Es findet sich lediglich der Eintrag im Ereignisprotokoll des Exchange Servers. So langsam fehlt mir der Plan, was ich machen soll. Man kann ja nicht alle Empfänger anrufen und sie bitten, das Greylisting abzustellen. :shock: Danke und Gruß olc Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 7. Juni 2007 Melden Teilen Geschrieben 7. Juni 2007 Hi. Dann dürfte dieser Artikel genau für dich passen - Exchange --> Greylisting - microsoft.public.exchange.admin | Google Groups LG Günther Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 7. Juni 2007 Melden Teilen Geschrieben 7. Juni 2007 Hi. Und das habe ich auch noch gefunden - Greylisting.org - problem MTAs LG Günther Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 7. Juni 2007 Autor Melden Teilen Geschrieben 7. Juni 2007 Hallo Günther, diesen Thread habe ich bisher nicht gefunden, aber er beschreibt exakt das, was hier der Fall ist. Bei einem Restart des SMTP-Dienstes oder des Information Stores bekommen die Benutzer die NDRs. Den SMTP Dienst täglich neu zu starten (wie dort beschrieben) löst das Problem ja nicht wirklich, sondern stellt "nur" die NDRs zu. Aber das ist ja schon ein Schritt vorwärts. :) Ich versuche jetzt den Tipp mit dem Registry Key: In HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing, create"GlitchRetrySeconds" as a dword and try a value of 60 or 120. Then restart the SMTP service. Ich hoffe, daß das den gewünschten Effekt hat. Tausend Dank noch einmal für Deine Unterstützung. Gruß olc Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 8. Juni 2007 Autor Melden Teilen Geschrieben 8. Juni 2007 Hallo, es scheint nun, nach dem Setzen des Registry Keys, problemlos zu laufen. Wenn man dann erst einmal weiß, wonach man im Netz suchen muß, findet man auch die entsprechenden Beiträge zum Thema. Vielleicht hilft es einem von Euch ja mal weiter: - MSXFAQ.DE - Greylisting - You Had Me At EHLO... : Explaining the Mysterious SMTP Advanced Queuing Engine Danke noch einmal an Günther für die schnelle Hilfe und den Treffer ins Schwarze. :) Gruß olc Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.