Nein, es soll heute nicht um Fahrtrichtungsanzeiger, vulgo Blinker, gehen, sondern um einen großen deutschen Freemailanbieter, der sog. "Fun-Domains" anbietet, d.h. die Registrierung von E-Mail-Adressen nicht nur unter der Hauptadresse des Dienstes ("example@freemailer.example"), sondern auch unter weiteren Domains anbietet ("example@cooler-hase.example").
Dieser Anbieter hat offenbar derzeit Probleme mit der Synchronisation der Benutzerdaten zwischen seinen Mailservern, was mir deshalb auffiel, weil eine E-Mail an eine bestimmte Adresse nicht zustellbar war, bei einer Überprüfung der Adresse diese aber gültig erschien. Nachdem dennoch eine weitere Mail als unzustellbar zurückging, habe ich das Phänomen gestern dann etwas systematischer - unter Zuhilfenahme eines entsprechenden Scripts - untersucht, mit überraschendem Ergebnis.
"Geht, geht nicht, geht, ..." vollständig lesen
Die Domain eines "Kunden" 
war dieser Tage von einem Spam-Run in der schon üblichen Weise betroffen, daß der Bösewicht erfundene Absenderadressen aus der Kundendomain verwendet hat. Unzustellbarer Spam geht dann als Bounce an den vermeintlichen Absender, also den Kunden. So weit, so gut, kennen wir alle.
Dumm nur, daß der Kunde einen Catch-All-Account verwendet, also alle E-Mails an beliebige Adressen der Domain annimmt; noch dümmer, daß er für diesen Catch-All-Account eine Weiterleitung definiert hat, bei der der Zielprovider die Bounces als Spam ausfiltert und die Annahme ablehnt. Einerseits ist das potentiell geeignet, den hiesigen Server in eine Blacklist zu befördern, andererseits bleiben diese Bounces dann als "double bounces" in der Mailqueue liegen. Das Ergebnis kann man an der Graphik ablesen …
Ich hatte bereits geschildert, daß das Munin-Plugin für BIND nicht mit dem Format der Statistikdatei von BIND 9.5.x umgehen kann, und auch eine Lösung vorgeschlagen, die bei mir dafür gesorgt hatte, daß die Lücke in den Munin-Daten für BIND sehr schmal blieb. Leider mußte ich jetzt - nachdem ich, bedingt durch Zeitmangel, erst nach längerer Zeit wieder einmal einen Blick auf diese spezielle Grafik werfen konnte - feststellen, daß sich ein neues, bald zwei Wochen messendes Loch aufgetan hat. 
Der Grund ist einfach: BIND 9.5.1 schreibt die Statistikdatei nicht immer wieder neu, sondern hängt die neuen Informationen am Ende an. So wird die Datei immer länger; hier waren es jetzt > 33 MB. Und da das Munin-Plugin die Datei schlicht zeilenweise liest und dabei auf das (letzte) Auftreten bestimmter Schlüsselbegriffe achtet, um die entsprechende Zeile dann auszuwerten, dauert das ab einer gewissen Dateigröße einfach so lange, daß dabei ein Timeout des entsprechenden Plugins entsteht. 
Weiß jemand zufällig, ob man BIND 9.5.1 beibringen kann, die Statistiken wie früher immer neu zu dumpen, statt sie an die alte Datei anzuhängen? Sonst wird sich wohl ein Cronjob der Sache annehmen müssen, der die Datei rotiert - oder regelmäßig löscht.
Da trudelte doch am gestrigen Freitag eine Anfrage über das Kontaktformular auf meiner Homepage mit der Bitte um Hilfe bei einer bestimmten Fragestellung (im Zusammenhang mit Newsgroups und einer schulischen Aufgabe) ein. Man weiß ja nie, wie sehr es dabei eilt, also nutze ich heute die anstehende Zugfahrt und stelle eine ausführliche Antwort - der Mailclient zählt rund 170 Zeilen, inkl. Quotes - mit Links zu weiterführenden Texten zusammen, die ich von unterwegs noch absende (immerhin habe ich jetzt ja eine funktionierende UMTS-Karte ).
Und was ist das Ergebnis? Die angegebene E-Mail-Adresse des Fragestellers (bei einem großen deutschen Freemailanbieter mit drei Großbuchstaben) ist nicht existent. Supersache.
(Vielleicht sollte ich nächstes Mal einfach gar nicht erst antworten. Spart Zeit, die ich eigentlich nicht habe …)
