Möglicher Fehler einer E-Mail Blacklist auf On-Premises Exchange?

MailKurzer Nachtrag zu einem Thema, welches im Juli 2024 von einem Leser per Mail an mich herangetragen wurde. Ein Leser arbeitet in einem Systemhaus und musste feststellen, dass E-Mails vom Unternehmen in Exchange plötzlich massenhaft abgelehnt wurden. Die Deaktivierung der Blacklist hat dieses Problem behoben.

Thomas schrieb mir in seiner Mail, dass er einen Fehler in einer Blacklist vermutet. Im IT-Systemhaus wird ein Exchange Server On-Premises eingesetzt. Seit der zweiten Juli-Hälfte 2024 beobachtet die IT, dass urplötzlich jede 2. E-Mail von dem Unternehmen abgelehnt wird. Es kommt folgende Fehlermeldung:

This message was created automatically by the SMTP relay on xxx.xxx.xxx.

A message that you sent could not be delivered to all of its recipients.

The following address(es) failed:

xxx@xxx.xxx

    host xxx.de [xxx.xxx.xxx.xxx]

    SMTP error from remote mail server after RCPT TO:<xxx@xxx.de>:

    550 xxx.xxx.xxx.xxx. blacklisted at bl.score.senderscore.com

Thomas vermutet einen Fehler einer Blacklist, denn eine Deaktivierung dieser Blacklist hat das Problem behoben. Gibt es unter der Leserschaft ähnliche Beobachtungen?

Dieser Beitrag wurde unter Mail abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Möglicher Fehler einer E-Mail Blacklist auf On-Premises Exchange?

  1. Tomas Jakobs sagt:

    100% ist es das Systemhaus selbst, dass offensichtlich NULL Ahnung im Betrieb von Mailservern hat. Stichwort hier: UCE Protect und generelles Problem mit RBL Blacklisten.

    Du hast übrigens selbst mal dazu was geschireben:
    https://www.borncity.com/blog/2023/04/22/uceprotect-spam-protection-als-problembr/

    Gruß aus Dem Maschinenraum

  2. Tom sagt:

    Naja, die ‚Fehlermeldung‘ meldet ja keinen Fehler, sondern die Tatsache, dass die dort angegebene IP Adresse auf bl.score.senderscore.com blacklisted ist. Entweder man lässt sie dort entfernen, oder man macht eine Allow-Rule für die relevanten IPs des/der SMTP Relays.

  3. Blacky Forest sagt:

    Ich erinnere mich, dass senderscore.com vor etwa 4 oder 5 Jahren ein Problem mit der Erreichbarkeit hatte. Der Service war zeitweise nicht erreichbar und dadurch haben einige Filter praktisch alles geblockt, immer wenn eine Prüfung nicht erfolgen konnte.

    • Pau1 sagt:

      Das eine Zeitlang alles geblockt wird ist ein übliches Vorgehen von RBL Betreibern, wenn sie ihren Dienst einstellen (müssen).
      Vorher gab’s entsprechende Hinweise und man merkt (hoffentlich) sehr schnell, wenn alle E-Mails abgelehnt werden.
      (Das Spam aufkommen ist Null).

  4. Pau1 sagt:

    Achso, jede 2. Email?
    Die werden doch nicht unsinnigerweise 2 Mail Server MX einsetzen, und haben nur den einen gefixt?
    2 MX ist soooo 90th..

    • Ralph D. Kärner sagt:

      Echt? Wie löst man denn heutzutage das Redundanzproblem, weil ja „auf keinen Fall eine Mail verloren“ gehen darf?
      Die Frage ist übrigens ernst gemeint. Ich habe noch nie mehr als einen Mailserver benötigt und außerdem noch nie „Redundanz“ in dem Bereich benötigt.

      • Bernd B. sagt:

        Das ist im SMTP Protokoll (IIRC ab RFC 2821) bereits gefixt: Der sendende MTA muss bei Zustellfehler (no connect oder 4xx Status) das Mail zurück in die Queue stellen und den Versuch später wiederholen.
        Nur bei 5xx-Stati oder nach n Versuchen soll/darf er einen NDR erstellen und das Mail aus der Queue nehmen.

    • oli sagt:

      Also Google hat für gmail.com gleich 5 MX Einträge hinterlegt…

  5. Pau1 sagt:

    ja. es ist m.E. auf jeden Fall besser, wenn die E-Mail gar nicht erst angenommen wird, anstatt auf einem redundanten Mail Server zu versauern. So kann der Absender das sofort merken und ein Fax schicken oder anrufen…und bekommt nicht in 5 Tagen den Bounce…
    Das mit den 2 MX stammt wohl aus der Zeit, als man sichi mit Modem einwählte und jeder wusste das Email kein Echtzeit medium ist.

  6. Daniel sagt:

    Genannte DNSBL ist schon lange raus.

    Lieber auf Spamhaus und Abusix setzen, deckte meiste gut ab.

    Dazu kann man umstrittene UCE 1 verwenden, aber nur in Kombi wenn andere Listen auch anschlagen.

  7. Daniel sagt:

    2. MX kann man machen bei sehr großen Umgebungen wo man wirklich Last verteilen möchte. Dieser muss aber gleich konfiguriert sein was Blacklisten usw. angeht.

    Man kann auch noch einen 3. MX einsetzen der ausschließlich Aufgabe hat alles ohne Ausnahme temporär abzulehnen. Spammer nutzen wohl gern andere MX da diese öfters ggf. schlechter konfiguriert sind und ggf. als Backup MX fast alles annehmen und dann so Spamfilter und co auf primären MX umgehen.

    I.d.R. braucht man also keine weiteren MX, der Absender wirds normal öfters probieren noch für 1-2 Tage.

    • Anonymous sagt:

      Also sowas habe ich noch nie gehört. Gerade das mit dem 3. MX macht doch gar keinen Sinn, wenn der ohnehin alles ablehnt, dann kann ich mir den auch sparen.

      Ich kenne es so, dass man mind. 2 MX Einträge und damit auch mind. zwei Mail-Server haben sollte, die vollkommen gleichwertig installiert und konfiguriert sind.

      • Daniel sagt:

        Kann schon Sinn machen, wenn spammer halt andere MX fokussieren in Hoffnung sei schlechter konfiguriert und somit garnicht erst produktive System kontaktiert.

        Ist aber nicht unbedingt gängige Praxis, meistens reicht auch ein MX aus.

        • Anonymous sagt:

          Tut mir leid, aber ich kann denn Sinn dahinter noch immer nicht verstehen. Wieso sollte ich ein „schlechter“ konfigurierten MX betrieben? Wenn ich schon mehrere MX betreibe, dann alle gleich sicher. Was auf gar keinen Fall passieren sollte ist, dass eine Mail über MX1 abgelehnt wird, aber über MX2 durch geht.

          • Bernd B. sagt:

            Der 2. oder 3. MX (lowest prio) lehnt nicht mit 5xx (permanent error) ab, sondern mit 4xx (temp error), jeder RFC-compliant MTA versucht es dann später erneut (und zwar beim MX mit der höchsten Prio).
            SPAMer versuchen es aber oft eh nur einmalig (deswegen helfen Graywalls in einigen Fällen) oder benutzen oft noncompliant MTAs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert