RSS-Feed abonnieren

Passwort vergessen?

v Anmelden

14. Jan 2008

Mailflut mit NonDeliveryReports

Verfasst von

In den letzten Tagen erhalten einzelne Nutzer lawinenartig mehrere Hunderte … Tausend E-Mails mit fuer sie unbekannter Herkunft.
In den E-Mails wird informiert, dass eine Nachricht mit der Mailadresse des Nutzers als Absenderdresse nicht zugestellt werden konnte.
Es ist also ein sog.
NonDeliveryReport = NichtZustellungsNachricht.
als eine Form von „DeliveryStatusNotifications“ DNS.

Was ist geschehen:

  • Irgend ein infizierter Rechner (oder mehrere) draussen im Internet verschickt Werbe-/SPAM- oder andere Muell-Email mit gefaelschter Absenderadresse. Als Absender-Adresse wird eine Adresse „xxxxxx@zzzzzzz.uni-halle.de“ verwendet.
  • Diese Mail wird an Hunderte/Tausende existierende oder nichtexistierende Mailadressen weltweit verschickt.
  • Die Empfangssysteme dieser Maildomains weisen diese gefaelschten Emails zurueck: „recipient address illegal“, „SPAM ….“, ……., ………
  • Als Folge daran geht die unzustellbare Mail an den vorgeblichen Absender zurueck (NonDeliveryReport). Dieser „Absender“ ist aber die gefaelschte Uni-Adresse „xxxxxx@zzzzzzz.uni-halle.de“.
  • Damit erhaelt die Mailbox von „xxxxxx@zzzzzzz.uni-halle.de“ jede dieser Benachrichungen: Hunderte …. Tausend:
    • Alle enthalten inhaltlich etwa das Gleiche: „Ihre Mail konnte nicht zugestellt werden, weil ……..“
  • Wir haben in Einzelfaellen verifiziert, dass der Ursprungshost der Originalmail kein Rechner des Uni-LAN ist, also die Mail nicht ueber uns rausgegangen ist.

Wie kann das verhindert werden

  • Gar nicht.
  • Auch bei der „Gelben Post“ (Deutsche Post) kann jedermann irgendwo auf der Welt in den dortigen Briefkasten einen (frankierten) Brief mit einer beliebigen gefaelschten/ausgedachten) Absender-Adresse einwerfen. (Bei E-Mail muss nur leider kein Porto bezahlt werden ….). Alle diese Briefe werden transportiert. Und wenn der Empfaenger nicht aufgefunden werden kann, geht der Brief zurueck an den Absender …..
  • NonDeliveryReports und andere DeliveryStatusNotifications sind auch bei gutartigem Mailverkehr unverzichtbar:
    • Empfaenger unbekannt (z.B. eigener(!) Tipp-Fehler bei der Adresse)
    • Mailbox voll (Quota)
    • Rechner nicht erreichbar (Leitung down oder Rechner in Wartung)
    • Vacation-Message: „Ich bin in Urlaub“
    • angeforderte Empfangsbestaetigung
    • Deshalb koennen NonDeliveryReports (wenn ueberhaupt als solche identifizierbar) nicht generell unterbunden werden. Eine zentrale Massnahme, die fuer 27000 Mailboxen passt, ist nicht anwendbar.

    • In der Regel ebbt die Mailflut nach einigen Tagen ab …… und der naechste Nutzer ist dran …..

    Was kann der einzelne Nutzer tun

    • Auf eigene Verantwortung und eigenes Risiko kann der Nutzer versuchen, durch evtl. Filterregeln im PC-Mailprogramm (PegasusMail, Thunderbird, …) solche NonDeliveryReports zu erkennen und diese dann sofort beim Abholen der Mail auszusortieren und ggfls. zu loeschen.
    • Aber Achtung: Sehr gefaehrlich:
      • Es werden dann auch gutartige DeliveryStatusNotifications („Mailbox voll“ ff., siehe oben) geloescht.
      • Bei fehlerhaftem Filter verschwinden sogar „echte“ Mails.
      • ……….
    • Auswahlkriterien fuer DSN:
      a) „Envelope-From“ bzw. „Return-Path“ sind leer und enthalten keine Adressangabe.
      b) Das neue Zentrale Mailsystem MSERV-2 („mail.uni-halle.de“ in Betrieb ab Mai 2008) fuegt bei DSNs dem Betreff-Header (Subject) die Zeichenkette „[BOUNCED]“ hinzu, die dann fuer eine nutzereigenen Filtertest verwendet werden kann.
      c) Im alten Mailsystem MSERV-1 („studmail.uni-halle.de“ in Betrieb seit 2002) gibt es fuer NDRs spezifische Filterregeln M1, M2, M3 und M4.

    Leonhard Knauff

    Über Kristina

Kommentieren


Letzte Kommentare