Exchange Server sendet nicht an 2. MX Record

1. offizieller Beitrag

    Hallo Leute,


    ich bin einwenig am verzweifeln...


    Wir haben einen exchange 2003 auf SBS Basis.


    Dieser funktioniert soweit auch wunderbar.


    Nun zum Problem:


    Wenn ich an eine bestimmte Firma eine E-Mail versende kommt diese leider nie an, da dort das IT Team Greylisting gegen Spam im Einsatz hat. Genauer gesagt wird jeder Mailzustellungsversuch beim ersten Sende Versuch bei denen geblockt und erst der 2. Angenommen. (Halt abwehr gegen Spam)


    Nun ist es aber so das, mein Mailserver das erste mal Sendet und natürlich abgeblockt wird. (So soll es ja auch sein) Nun versucht der Server es erneut, aber nicht wie es normal ist das er versucht an einen alternativen MX Record zu senden sondern wieder den ersten.... Und Somit wieder abgeblockt wird. Die Firma hat 3 MX Record einträge mit je unterschiedlicher Priorität 50,100,150... Bei ersten mit der Höchsten wird halt immer abgeblockt und er der 2. lässt die nachricht praktisch durch. Der 3. schein Backup Lösung zu sein...


    Nun ja kann ich dem Exchange irgendwie beibringen das er beim wiederholen vom senden den 2. MX benutzen soll??


    Wäre cool wenn jemand eine Lösung hätte!!


    Schönen gruß Suntzus

    Hallo,


    mir wäre nicht bekannt, dass Exchange mit alternativen MX-Einträgen Probleme hat.
    Aber ich möchte deine Frage erweitern, und hoffe, jemand anderes kann kompetente Auskunft geben:


    Wann macht Exchange ein "fallback" auf einen anderen MX?
    - Wenn der ursprünglich gewählte Netztechnisch nicht erreichbar ist
    - Wenn ein temporärer Fehler erzeugt wird (Soft-Bounce, SMTP 4xx)
    - Wenn ein endgültiger Fehler erzeugt wird (Hard-Bounce, SMTP 5xx)


    Bei der englischen Wikipedia gibt es eine interessante Abhandlung darüber, die drauf hinausläuft, dass die RFCs hier nicht eindeutig sind (http://en.wikipedia.org/wiki/MX_record). Wie also ist die "Exchange-Interpretation" dieses Themas?


    Gruß


    Filipp

    • Offizieller Beitrag

    Auch wenn die Frage von filippg interessant ist, für das Problem ist sie vollkommen irrelevant.


    Greylisting beim Empfänger ist fehlerhaft konfiguriert - Punkt.


    Da Greylisting nirgendwo klar definiert ist (RFC), kann doch nicht von Dir erwartet werden, dass Du Deinen Exchange-Server auf das Fehlverhalten des anderen einstellst. Nirgendwo steht eine Pflicht, den zweiten MX zu nehmen, wenn der erste Greylisted.


    Wenn der Empfänger mehrere Mailserver betreibt, dann muss er dafür sorgen, dass die Greylisting-Datenbank untereinander synchronisiert wird.


    Ich würde die andere Firma mal dezent daraufhinweisen, dass sie vermutlich nicht nur Eure Mails blocken, sondern die false-positive-Rate ziemlich hoch sein sollte.


    Eure Fragen zeigen in Punkt Greylisting vor allem mal wieder eines: Das es meistens mehr Probleme macht, als es Nutzen bringt (vorallem wenn es nicht gepflegt wird) - zumal sich Spammer mittlerweile darauf eingestellt haben.

    • Offizieller Beitrag
    Zitat


    Greylisting beim Empfänger ist fehlerhaft konfiguriert - Punkt.


    Was veranlaßt dich zu dieser Aussage?


    Zitat

    Da Greylisting nirgendwo klar definiert ist (RFC), kann doch nicht von Dir erwartet werden, dass Du Deinen Exchange-Server auf das Fehlverhalten des anderen einstellst. Nirgendwo steht eine Pflicht, den zweiten MX zu nehmen, wenn der erste Greylisted.


    Bei einem Tempfail wäre das zumindest meiner Meinung nach auch ein Fehlverhalten.


    Zitat

    Wenn der Empfänger mehrere Mailserver betreibt, dann muss er dafür sorgen, dass die Greylisting-Datenbank untereinander synchronisiert wird.


    Ja, aber das würde bei Tempfails trotzdem maximal eine zusätzliche Verzögerung und kein "Nichtzustellen" verursachen, wenn die DB nicht in sync ist.


    Zitat

    Ich würde die andere Firma mal dezent daraufhinweisen, dass sie vermutlich nicht nur Eure Mails blocken, sondern die false-positive-Rate ziemlich hoch sein sollte.


    Korrekt.


    Zitat

    Eure Fragen zeigen in Punkt Greylisting vor allem mal wieder eines: Das es meistens mehr Probleme macht, als es Nutzen bringt (vorallem wenn es nicht gepflegt wird) - zumal sich Spammer mittlerweile darauf eingestellt haben.


    Die Aussagen kann ich nicht bestätigen. Weder macht es Probleme, noch kann ich feststellen, dass neuerdings Spammer mehrfache Versuche unternehmen. JEdenfalls nicht die Masse. Liegt eventuell wie immer daran, dass man etwas nicht einfach installieren/einschalten sollte, wenn mans nicht versteht. ;) Denn die Verwendung von 3 mx records ist eigentlich schon selten sinnvoll.


    Schönes WE noch
    Norbert

    • Offizieller Beitrag
    Zitat


    NorbertFe schrieb:


    Was veranlaßt dich zu dieser Aussage?


    Du schreibst es doch selbst:


    Zitat

    Bei einem Tempfail wäre das zumindest meiner Meinung nach auch ein Fehlverhalten.


    und:


    Zitat

    Ja, aber das würde bei Tempfails trotzdem maximal eine zusätzliche Verzögerung und kein "Nichtzustellen" verursachen, wenn die DB nicht in sync ist.


    Genau.


    Aus dem OP lese ich aber heraus, dass der Empfänger erwartet, dass der zweite Sendeversuch auf dem alternativen MX ankommt. Wenn das nicht passiert, geht die Mail nicht durch.


    Für mich ein Fehlverhalten.


    Zitat

    Die Aussagen kann ich nicht bestätigen. Weder macht es Probleme, noch kann ich feststellen, dass neuerdings Spammer mehrfache Versuche unternehmen. JEdenfalls nicht die Masse. Liegt eventuell wie immer daran, dass man etwas nicht einfach installieren/einschalten sollte, wenn mans nicht versteht. ;) Denn die Verwendung von 3 mx records ist eigentlich schon selten sinnvoll.


    Korrekt.


    Wie ich schon schrieb: "wenn es nicht gepflegt wird".


    Frank beschreibt hier schön die Problem mit Greylisting: Klick - ergänzend hierzu auch der Artikel in Wikipedia.


    Diese Problem habe ich alle schon erlebt.


    Noch mal deutlich: Bei richtig eingesetztem und gut gepflegten White-Lists halte ich Greylisting durchaus als Anti-Spam-Maßnahme geeignet.


    Mein persönlich Erfahrung ist leider, dass Admins das einschalten und dann sich nicht weiter darum kümmern und damit mehr schaden als nutzen.

    • Offizieller Beitrag


    Hmm ok, kann man natürlich auch so lesen. ;)


    Zitat


    Noch mal deutlich: Bei richtig eingesetztem und gut gepflegten White-Lists halte ich Greylisting durchaus als Anti-Spam-Maßnahme geeignet.


    Greylisting erfordert normalerweise aber keine Whitelist, da ein Tempfail eben eine erneute Zustellung veranlassen sollte. Blöderweise gibt es aber google und arcor, die bei einem Tempfail einen rollover zu einem neuen Send-Host. Mein greylisting läßt im übrigen korrekte SPF Records ohne Verzögerung durch. Vielleicht bewegt sowas ja die Leute dazu mal SPF langsam zu nutzen. ;)


    Bye
    Norbert

    Hallo Leute


    vielen dank für eure Antwort.


    Tut mir leid hatte einige wichtige details vergessen! der Exchange Server sendet die Nachrichten an unseren SMTP Relay Server (Hexamail) und dieser wiederum schickt dann die Nachrichten raus. Nachdem Hexmail die 48 versuche durch hat die Mail zuzustellen kommt dann auch eine Unzustellbarkeitsnachrricht an. In den Logs kann man sehen das der Hexamail-Server immer versucht auf den selben Server zu schicken den mit der höchsten Priorität halt. Das scheint ja auch normal zu sein oder?! Der Server ist ja erreichbar also scheint es mir nur logisch das der Server wieder den mit der höchsten Priorität ansteuert. Nun ist die Frage warum die Mail trotzdem nicht durchkommt.


    Hier einen ausszug von dem Admin der Firma, die mich halt darauf gebracht hat das es Geylisting ist:


    Die Ursache des Fehlers ist demnach
    eindeutig und wie folgt: Ihr Server sendet Mail, wie zunächst jeder Server,
    beim ersten Versuch unter Verwendung des sog. MX-Records unseres
    DNS-Eintrags bzw. mit Prüfung des ersten von jeweils 3 Schlüsselpaaren. Das
    erste Schlüsselpaar ist jedoch auf unserer Seite immer ungültig. Das ist so
    gewollt, weil dies ein extrem effektiver Schutz vor Spam ist. Ein nach
    Standard konfigurierter sendender Server hat damit aber kein Problem, denn
    er versucht dann sofort, das Mail erneut zu senden und nimmt dabei den
    zweiten der jeweils drei Schlüssel. Das funktioniert auch bei uns immer
    problemlos. Ihr Server ist aber offensichtlich so eingestellt, dass er den
    zweiten Sendeversuch gar nicht durchführt und stattdessen sofort einen
    Fehler meldet.


    Wäre echt Super wenn ihr mir da weiterhelfen könnt!!


    Der Hexmail Server sendet aber definitiv die E-Mail neu raus 48 mal das ganze. Hab auch die Zeit von 10 min auf 2 minuten runtergeschraubt. Leider ohne Erfolg...



    Mfg Suntzus

    Hallo,


    > für das Problem ist sie vollkommen irrelevant.
    ist das nicht eigentlich der Zentrale Punkt? Exchange verwendet den alternativen MX nicht, sollte aber?


    > Nirgendwo steht eine Pflicht, den zweiten MX zu nehmen,
    > wenn der erste Greylisted.
    Jein. Die RFCs besagen zumindest, dass der MTA in der Lage sein muss, alle MX-Records durchzuprobieren, wenn es beim ersten nicht "funktioniert"


    > Wenn der Empfänger mehrere Mailserver betreibt,
    > dann muss er dafür sorgen, dass die Greylisting-Datenbank
    > untereinander synchronisiert wird.
    Den Eröffnungspost habe ich so verstanden, dass der Empfänger das auch einwandfrei tut. Und zwar dahingehend, dass der 1. MX gar keine Mails annimmt, und der zweite genau dann, wenn schon ein Versuch beim 1. gemacht wurde.


    > Tut mir leid hatte einige wichtige details vergessen!
    Das waren allerdings wirklich wichtige Details. Dem zufolge hat das ganze mit Exchange überhaupt nichts zu tun, sondern nur mit dem "Hexmail"
    > In den Logs kann man sehen das der Hexamail-Server immer
    > versucht auf den selben Server zu schicken den mit der
    > höchsten Priorität halt. Das scheint ja auch normal zu
    > sein oder?!
    Nee, wie gerade schon geschrieben sollten alle MXe probiert werden. Wende dich an den Hersteller.


    Gruß


    Filipp

    • Offizieller Beitrag


    Also ich weiß nicht, was die dort verwenden, aber Greylisting funktioniert ohne Schlüsselpaare. ;) Frag doch mal, was genau die dort einsetzen.
    Bei Greylisting müssen nur 3 Sachen übereinstimmen:
    Sende IP
    Absenderadresse
    Empfängeradresse.


    Zitat

    Der Hexmail Server sendet aber definitiv die E-Mail neu raus 48 mal das ganze. Hab auch die Zeit von 10 min auf 2 minuten runtergeschraubt. Leider ohne Erfolg...


    Das sollte der Admin der Gegenseite dann ja auch im Log sehen. Frag ihn.


    Bye
    Norbert

    • Offizieller Beitrag

    Offesichtlich handelt sich sich gar nicht um echtes Greylisting beim empfangenden Server.


    So wie es scheint, hat der einfach drei MX-Einträge, aber nur beim mittleren hört auch wirklich ein Mail-Server. Ich habe schon öfter mal von einer solchen Technik gehört.


    Kannst Du den Admin mal fragen, was er unter "Schlüssel" und "Schlüsselpaar" versteht?


    Außerdem wäre es schön, mal den kompletten NDR zu sehen. Was passiert denn, wenn Du per Telnet eine Verbindung zum ersten MX aufbaust?