Skip to content

Winterputz: Newsletter

“Information overload” ist im Netz kein ganz neues Thema. Dazu gehört auch die Vielzahl von Newslettern und Mailinglisten, die regelmäßig die Inbox verstopft und selten bis nie gelesen wird. Wie schnell ist ein interessant klingender Newsletter abonniert, oder vielleicht ist das Abonnement auch mit der Anmeldung bei einem Dienst verknüpft, und man will dann erst einmal auf dem Laufenden bleiben - abmelden kann man sich ja immer noch. Und will man wirklich das Risiko eingehen, ein interessantes Angebot zu verpassen?

Bereits vor rund zwei Jahren, im Januar 2013, hatte ich mir aber einmal ein Herz gefasst und rund drei Dutzend (!) Newsletter abbestellt. Keinen habe ich seitdem wirklich vermisst, aber natürlich sind etliche geblieben und mittlerweile weitere dazugekommen.

Nun habe ich bereits viele Monate lang beobachtet, dass ich alle (!) eingehenden Newsletter nur noch automatisch oder manuell in den entsprechenden Ordner verschiebe und sie weder zeitnah noch überhaupt je lesen. Insofern erscheint mir der richtige Zeitpunkt gekommen, einmal das letzte Quartal in diesem Ordner durchzugehen und konsequent jeden Newsletter abzubestellen, bei dem ich mir nicht sicher bin, ob ich ihn im kommenden Vierteljahr lesen werde - dann was bringt es, interessante Informationen und Sonderangebote zu erhalten, wenn man ohnehin die ganze Masse nicht liest? Diesmal waren es knapp vier Dutzend (!) Newsletter, die ich ab sofort nicht mehr beziehen werde. Vielleicht erlaubt mir das dann ja, den verbleibenden Rest ab und zu auch einmal wirklich anzuschauen.

(Als nächstes steht dann ein kritischer Blick auf die abonnierten Mailinglisten an, denn auch dort gibt es mehrere, die ich seit Jahren (!) nur noch regelmäßig auf gelesen setze. Wobei in diesem Fall ja wenigstens noch das Argument greift, dass ein lokales Archiv von Supportmailinglisten u.ä. es erlaubt, im Falle eines auftretenden Problems schnell einen Überblick zu gewinnen, was dazu bereits von anderen geschrieben wurde, ein Mehrwert, den Newsletter nicht zu haben pflegen.)

Wordpress: Korrekte E-Mails generieren

Blogsysteme müssen regelmäßig E-Mails generieren, sei es an den Blogbetreiber, sei es an Kommentatoren: Informationen über neue Kommentare oder Beiträge, mögliche Updates usw. usf. Das erfordert natürlich das Vorhandensein einer (gültigen) E-Mail-Adresse, die als Absender solcher Mails eingesetzt werden kann.

Serendipity macht es sich einfach und überlässt dem Nutzer die Wahl: die “E-Mail-Adresse des Blogs”, blogMail, ist entsprechend in der Konfiguration zu setzen. Das erlaubt dem Nutzer die freie Wahl, erfordert aber umgekehrt natürlich, dass der Nutzer sich darüber Gedanken macht - andererseits: wie soll das anders gehen?

Die Antwort darauf liefert der Konkurrent WordPress, und sie überzeugt mich nicht: auch WordPress verlangt zwar die Angabe einer E-Mail-Adresse “zu administrativen Zwecke”, setzt standardmäßig als Absender aber die Adresse wordpress@example.com, wobei statt example.com die Domain des Blogs steht. Großartig, wenn eine solche Absenderadresse dann nicht existiert. Außerdem setzt WordPress offensichtlich standardmäßig keinen Envelope-Sender, so dass in der Regel der Benutzer, unter dem der Webserver-Prozess läuft, als solcher eingesetzt wird. Auch an diesen “Absender” in der Form www-data@yourhost.example.com kann man allerdings regelmäßig keine Mail schicken …

Abgesehen davon, dass daraus Probleme mit der Auslieferung der E-Mails entstehen können (Stichworte “Verifikation von Absenderadressen” und “Spamfilter”), ist das auch einfach technisch unschön. Wie also lässt sich das abstellen?

  1. Der Mailserver muss dem PHP-Prozess zunächst einmal erlauben, einen Envelope-From (bspw. via sendmail -f blog@example.com) zu setzen.
    Wenn man - wie ich - Exim einsetzt, muss der entsprechende Benutzer, unter dem der Webserver läuft, zu trusted_users hinzugefügt werden. Man kann sich dabei stundenlanges Debugging sparen, wenn man rechtzeitig daran denkt, dass man via mod_suphp (oder auf ähnliche Art und Weise) PHP-Scripts nicht unter der User-ID des Webservers, sondern unter derjenigen des Benutzers laufen lässt. Dieser Benutzer - und nicht www-data o.ä. - muss dann auch in trusted_users.

  2. Danach muss man WordPress davon überzeugen, den passenden From:-Header zu setzen.
    Das geht über manuelle Änderungen von Konfigurationsdateien oder - einfacher und m.E. auch besser - durch Installation eines passenden Plugins, von denen es eine ganze Reihe gibt. Ich nutze dazu WP JV Custom Email Settings, das mir leichtgewichtig genug erscheint. Stattdessen kann man natürlich auch WP Simple Mail Sender, Personal Email oder etwas ähnliches verwenden, im Extremfall etwas wie WP Mail Options, das den Zugriff auf alle Einstellungen von PHPMailer, dem verwendeten PHP-Modul, eröffnet und insbesondere auch Test-E-Mails generieren kann, was zum Testen ganz praktisch sein mag.

  3. Schließlich muss man in WordPress auch den Envelope-Sender korrekt setzen.
    Das kann, soweit ich sehe, nur das Plugin Set email sender.

Danach funktioniert dann auch in WordPress alles so, wie man sich das eigentlich von Anfang an gedacht hätte.

Mailstörung

Ich weiß, dass man sich keine Illusionen über die Zuverlässigkeit auch - gering - bezahlter Dienste machen soll, und ich weiß auch, dass Service oft ein Zuschussgeschäft ist. Ich bin auch nie davon ausgegangen, dass man bei bekannten Anbietern kostenloser E-Mail-Adressen einen verlässlichen Dienst erwarten kann; auch dann nicht, wenn man dort einen bezahlten Account hat, denn das ist ja im Zweifel dieselbe Technik mit denselbem Personal.

Dennoch hat es mich etwas überrascht, welche Schwierigkeiten ein Anbieter - übrigens ein solcher, der keine kostenlosen Accounts anbietet, sondern schon ein paar Euro pro Monat für ein E-Mail-Postfach verlangt - bei der Beseitigung einer Störung hat. Aufgefallen ist diese Stärung, die sich darin äußerte, dass ein Versuch des Mailabrufs über IMAP/POP3 wie über Webmail in Timeouts lief, mir am 21. Juni; gut, das war ein Wochenende. Da tat sich offenbar auch nicht viel mehr, als dass eine Mitteilung auf der Webseite geschaltet wurde. Danach hat man sich dann um die Fehlerbehebung bemüht; viel getan hat sich aber nicht. Ab und an konnte man mal einige E-Mails erhalten, aber ein richtiger Abruf war nicht möglich. Bis Donnerstag (immerhin der 6. Tag der Störung!); da hat man dann damit begonnen, die Mailboxen umzukopieren. Nachdem ich meinem Client (am Samstag …) beigebracht hatte, dass sich die UIDVALIDITY geändert hatte, funktionierte der Abruf dann immerhin. Tröpfelnd. Pro E-Mail vergingen mehrere Sekunden. Das dauerte. Und dauerte. Und dauerte auch weiter. Auch heute, am Sonntag, dem 29.06.2014 (9. Tag der Störung) war man immer noch an der Arbeit und mit dem Umkopieren von Daten beschäftigt.

Zwar läuft es bei mir, aber ich bin gespannt, wann man die endgültige Störungsbehebung vermelden kann.

Und ich bin nicht beeindruckt.

Nachtrag vom 05.07.2015: Auch am 02.07.2014 - so der letzte Stand - war man weiter mit dem Umkopieren verbleibender Mailboxen beschäftigt …

Vom Advisory zum Exploit binnen eines Tages

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

"Vom Advisory zum Exploit binnen eines Tages" vollständig lesen

checkmail 0.5 released

Nach einem guten Jahr habe ich mal wieder Zeit zu einer kleinen Änderung in checkmail gefunden, die ich dann sogleich als Version 0.5 released habe.

checkmail überprüft die ihm übergebenen E-Mail-Adressen nun zunächst auf syntaktische Richtigkeit (wobei allerdings auf der Domain-Seite keine in eckigen Klammern stehenden IP-Adressen akzeptiert werden), bevor er weitere Tests damit durchführt.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

RBLs, RBL-Checks und "sie wissen nicht, was sie tun"

RBLs (Realtime Blackhole Lists) sind mittlerweile über ein Jahrzehnt alt und eine weitverbreitete Methode der Filterung unerwünschter E-Mails. In diese Listen, die über das DNS propagiert werden, trägt der jeweilige Betreiber nach seinen Kriterien die IP-Adressen von Hosts ein, die gefiltert werden sollen. Manche dieser Listen sind sinnvoll, andere sind es nicht; manche zählen Spam-Quellen auf, offene Proxies und Relays, von Malware befallene Systeme, andere jedes System, dessen Betreibers Nase dem RBl-Provider nicht passt. Wer RBLs einsetzt, muß sich also informieren, welche Policy eine RBL verfolgt, und wie zuverlässig sie das tut.

Neben den RBLs gibt es auch Anbieter, die prüfen, ob bestimmte Systeme auf diesen RBLs landen; das sollte jeder Admin größerer Mailsysteme eigentlich selbst tun, um ggf. (das für die Listung ursächliche Problem zu beheben und dann) die Löschung von der jeweiligen RBL zu veranlassen, aber für diejenigen, die das nicht tun können oder möchten, sind solche Angebote sicher interessant. Nur sollten diese Anbieter von RBL-Checks auch wissen, was sie da eigentlich tun, was wohl nicht immer sichergestellt ist …

Ich bekam jedenfalls dieser Tage (mal wieder) einen Hinweis, eines meiner Systeme sei in der RBL hostkarma.junkemailfilter.com gelandet; wie der Name andeutet, versucht deren Betreiber Mailserver in gute, schlechte oder neutrale einzuteilen. Wie zuvor habe ich daraufhin mein System auf den Webseiten des RBL-Betreibers geprüft und bekam - wie immer - als Antwort, das System sei nicht gelistet. Diesmal bin ich der Sache nachgegangen und habe festgestellt, daß der RBL-Check-Anbieter grundsätzlich Recht hat: meine Maschine war tatsächlich in der RBL eingetragen! Aber warum bestreitet das der RBL-Provider dann? Nun, meinem System war dort der Wert "127.0.0.1" zugewiesen. Und der RBL-Provider meint zu diesem Wert folgendes:

127.0.0.1 - whilelist - trusted nonspam

Danke, keine weiteren Fragen mehr.

Format des Date:-Headers in E-Mails

Aufgrund einer bei mir eingegangenen Anfrage habe ich mich heute mal mit dem korrekten Format eines Date:-Headers in einer E-Mail befasst.

Ein Leser meiner Homepage schilderte mir das Problem, das automatisch generierte E-Mails aus seiner Webanwendung bei ihm im Posteingang von GMX (Webinterface) immer mit dem Datum "01.01.1970" angezeigt würden, in seinem Mailclient (Outlook) aber korrekt. Das Datum (die "Epoche") roch natürlich nach fehlendem oder nicht standardkonformen Date:-Header … Nach Überlassung eines Beispiels konnte ich sehen, daß die Anwendung den Header nach dem Muster Wed, 29 Sep 10 22:45:24 generiert. Meine erste Vermutung, daß das Jahr vierstellig angegeben werden müsse, erwies sich als falsch … aber die zweite, nämlich daßdie Angabe der Zeitzone fehlt, als goldrichtig.

Der letzte STD 10, RFC 822, sieht die Angabe einer Zeitzone nämlich ebenso wie seine Nachfolger, RFC 2822 und der momentan auf dem Standard Track befindliche RFC 5322 (der künftige Standard) als zwingend vor; eine Datumsangabe ohne diese ist somit nicht nur uneindeutig, sondern auch syntaktisch fehlerhaft. Test-E-Mails an GMX bestätigten dann auch, daß im Posteingang der Weboberfläche (nur) die Mails mit fehlender Zeitzone fälschlisch auf den 1.1.1970 datiert wurden. Interessanterweise wurde das Datum aber in der Einzelansicht der E-Mails - genau wie auch in meinem Mailclient - korrekt (in der - hier ja auch zutreffenden - lokalen Zeitzone) angezeigt.

Die Anwendung sollte dementsprechend nachgebessert werden, um undefinierte Ergebnisse zu vermeiden.

checkmail 0.4 released

Nach dem gestrigen Release der praktisch komplett neu geschriebenen Version 0.3 von checkmail kann ich heute die Version 0.4 von checkmail ankündigen, die die eigentlich geplanten Änderungen enthält.

checkmail erkennt temporäre Fehler - bspw. auch beim Greylisting - jetzt als solche, statt diese E-Mail-Adressen als nicht zustellbar zu definieren; außerdem werden in jedem Fall die Antworten des Mailservers standardmäßig ausgegeben.

Überdies kann checkmail jetzt selbst eine tatsächlich zufällige - und damit mit hoher Sicherheit nicht zustellbare - E-Mail-Adresse erzeugen, wenn geprüft werden soll, ob der betreffende Mailserver überhaupt schon im SMTP-Dialog die Zustellbarkeit überprüft (ansonsten sind positive Antworten keine Garantie für die Existenz der geprüften Adresse). Die übrigen Konfigurationsangaben (der zu verwendende Absender und die Angaben für HELO/EHLO) können nun nicht nur im Script definiert, sondern auch auf der Kommandozeile übergeben werden.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

checkmail 0.3 released

Nach rund 5 Jahren Pause habe ich nunmehr eine neue Version 0.3 von checkmail released, einem Kommandozeilen-Tool zur Überprüfung der Zustellbarkeit von E-Mail-Adressen.

Im Prinzip wurde das Script komplett neu geschrieben, modularisiert, neu strukturiert und in den Kommentaren vereinheitlicht. Außerdem habe ich die Ausgaben neu gefaßt und ausführlicher gemacht; MXe werden jetzt zuverlässig in der nach dem DNS vorgegebenen Reihenfolge ausprobiert, Multi-Line-Antworten ordnungsgemäß protokolliert und der Exit-Status bei der Batch-Verarbeitung von Adressen sinnvoll gesetzt (womit zugleich eine Veränderung der Bedeutung des Exit-Status verbunden war).

Außerdem wurde die Dokumentation im POD-Format in das Script integriert und ins Englische übersetzt und ein Changelog hinzugefügt.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Beharrlichkeit ist nicht alles

Meine Mailserver erwarten, daß derjenige, der eine E-Mail einliefern möchte, sich ordnungsgemäß "vorstellt" (also ein einigermaßen korrektes HELO bzw. EHLO überträgt, namentlich nicht den - respektive einen der - Namen meiner eigenen Maschinen und auch keine bloße IP-Adresse). Normalerweise fängt dieser vergleichsweise "weiche" Filter nicht viel Spam weg (und "härter" filtern, bspw. überprüfen, ob die Vorwärts-Rückwarts-Auflösung stimmt o.ä., möchte ich darauf nicht).

In den letzten Tagen hat sich allerdings namentlich eine Maschine aus Venezuela geradezu rührend bemüht, trotzdem E-Mail loszuwerden:

root@host:~# zgrep -c wonderl.com /var/log/exim/mainlog.*
/var/log/exim/mainlog.01:32569
/var/log/exim/mainlog.02.gz:133069
/var/log/exim/mainlog.03.gz:164318
/var/log/exim/mainlog.04.gz:161655
/var/log/exim/mainlog.05.gz:142325

Das sind gestern rund 32.500 Versuche, und die vier Tage zuvor, mithin über Ostern, jeweils deutlich über 100.000. Ich würde ja gerne wissen, ob das immer dieselbe E-Mail sein sollte (nachdem die Versuche in der Regel maximal im Sekundenabstand liegen, liegt das allerdings eher fern), oder ob mir da massiv Spam erspart geblieben ist … Jedenfalls eine durchaus bemerkenswerte Penetranz, die dort an den Tag gelegt wurde.

Manche sind lernfähig ...

… andere sind es weniger.

Ich hatte bereits im vergangenen Jahr berichtet, wie wenig zuverlässig E-Mail als Medium mittlerweile oft ist, dann aber positiv überrascht zur Kenntnis nehmen dürfen, wie vergleichsweise schnell auch ein großer Anbieter wie Ebay auf entsprechende Hinweise reagiert und die (gar nicht im Ernst erwarteten) notwendigen Änderungen an seinen Mailsystemen vornimmt. Nunmehr kann ich berichten, daß andere Anbieter zwar dasselbe Problem haben, aber die Reaktion leider nicht immer gleich kompetent ist. Vodafone versendet E-Mails nämlich gleichfalls mit nicht existenten Absendern; mein entsprechender Hinweis wurde schnell, aber leider nur so beantwortet:

Guten Tag Herr Hochstein,

Ihr Hinweis hilft uns, Fehler zu erkennen und uns zu verbessern. Vielen Dank dafür. Leider können wir in diesem Fall keinen weiteren Support leisten. Eine Änderung des Absenders bei automatischen Bestätigungen ist nicht angedacht.

Sicherlich werden Ihre User keine Problemne haben, wenn sie Ihnen Mails über ihr Vodafone-MobileMail Postfach versenden.

Den ersten Absatz verstehe ich, auch wenn er mir inhaltlich nicht gefällt, aber, ganz ehrlich: was der zweite Absatz mir sagen will, ist mir schleierhaft. kopfkratz Am Problem der mit ungültigem Absender versandten automatisierten Bestätigungen geht diese Antwort doch völlig vorbei.

Mailzustellung: Reaktion von Ebay

Es geschehen noch Zeichen und Wunder! Auf meine Anfang November an den Support gestellte Frage bzw. den Hinweis auf Probleme beim Mailversand durch Ebay bzw. der Zustellung solcher E-Mails kam - nach einem Zwischenbescheid - nunmehr eine Antwort in der Sache:

Sehr geehrter Herr Hochstein,

Sie hatten sich an eBay gewandt, da Ihre Nutzer nicht alle E-Mail von uns erhalten haben.

Durch Sie und andere E-Mail-Provider sind wir auf eine Änderung in der Kopfzeile unserer Benachrichtigungen hingewiesen worden. Dies könnte der Auslöser für das geschilderte Problem gewesen sein. Um diese  Fehlerquelle auszuschliessen, haben diese Änderung jetzt korrigiert.

Herr Hochstein, bitte informieren Sie uns, ob Ihre Nutzer ab dem 16.12.2009 noch Benachrichtigungen vermissen.

Ich danke Ihnen für Ihre Mühe und wünsche Ihnen eine angenehme Woche.

Und die Überprüfung hat tatsächlich eine Behebung des Problems ergeben: die im Envelope-From bzw. Return-Path (dem "technischen" Absender der E-Mail) verwendeten Adressen existieren jetzt wieder bzw. nehmen E-Mail entgegen.

Erfreulich, daß man sich bei Ebay solcher Probleme tatsächlich annimmt und sie behebt. Das motiviert dazu, auch in anderen Fällen entsprechend tätig zu werden. :-)

Umabonnieren von Mailinglisten

Nachdem ich im letzten Monat meine Verwaltung personalisierter E-Mail-Adressen auf eine bequeme Weboberfläche umgestellt hatte, habe ich dieses Konzept nun auch auf meine abonnierten Mailinglisten erweitert.

Bislang habe ich alle Mailinglisten mit derselben E-Mail-Adresse abonniert, die ich dann per UUCP abgerufen habe. Das hatte den protokollbedingten Vorteil, daß die E-Mails komprimiert wurden, aber den Nachteil, daß ich keine Kontrolle über die Konfiguration des MX hatte, also auch keine Spamfilterung implementieren konnte, und daß bei einem Wechsel des Providers auch diese E-Mail-Adresse verlorengeht, dann also plötzlich alle bezogenen Mailinglisten unter anderer Adresse neu abonniert werden müssen. Und schließlich kamen über diese Adresse geradezu ungeheure Mengen an Spam an, geschuldet den Webarchiven der meisten Mailinglisten. Also habe ich mich nun entschieden, auch für den Bezug von Mailinglisten jeweils individualisierte Mailadressen unter einer (anderen) Subdomain einzusetzen; das erleichtert es überdies, bei Problemen mit der Abbestellung einer Liste einfach die entsprechende Bezugsadresse stillzulegen.

Das Hauptproblem bei einer solchen Umstellung ist es, die bisherige Bezugsadresse aus jeder einzelnen Liste aus- und die neue Bezugsadresse dann wiederum in jede Liste neu einzutragen (von der Reihenfolge her natürlich andersherum, damit keine Mailverluste auftreten). Und man glaubt gar nicht, wie schnell man dabei Low-Traffic-Listen (Ankündigungen o.ä.) vergißt …

Schon seit langer Zeit (tatsächlich wiederum Jahren) habe ich daher Scripts laufen, die versuchen, aus den über die Zustellung an meine Mailnglistenadresse geschriebenen Logs möglichst alle betroffenen Mailinglisten zu isolieren. Und ausgerüstet mit diesen Listen, einer Liste der Mailinglisten, an deren Bezug ich mich bewußt erinnere ;-) und einer Liste meiner Mail2News-Gateways habe ich nunmehr die Herkules-Aufgabe begonnen, alle Mailinglisten umzustellen (und manche dabei direkt abzubestellen). Ich bin gespannt, welche Listen ich vergessen werde …

Dazu waren ergänzende Umstellungen "drumherum" erforderlich: bspw. bei der lokalen Auslieferung der Mailinglistenmails, die Filter und Mail2News-Gateways berücksichtigen muß, oder auch bei der Konfiguration der richtigen Absenderadresse für jede Mailingliste in Mailclient oder Newsreader, damit eventuelle Antworten auf die Listen dann auch auf diesen landen und nicht abgewiesen werden, weil sie von einer Adresse kommen, die dem Mailinglistensystem unbekannt ist. Und das Logging wollte angepaßt werden, und … und … und …

Ich bin gespannt, wie sich diese Umstellung bewähren wird.

Mailinglisten umgezogen

Angeregt durch den ohnehin erforderlichen Umzug des Mailinglistenservers Mailman auf eine neue Maschine habe ich jetzt endlich auch die - historisch gewachsene - Konfiguration der meisten Mailinglisten geändert und bei der Gelegenheit auch eine Vielzahl bereits seit Jahren "toter" Mailinglisten - ggf. nach Rücksprache mit dem jeweiligen Betreiber - entsorgt. Die Konfigurationsänderung besteht in erster Linie in einer Änderung des per Default genutzten Hostnamens bzw. der Domain von "list.th-h.de" (Singular, da es anfangs eine Parallelinstallation "lists.th-h.de" gab …) zu "lists.szaf.org", weil es schließlich weniger um ein nur von mir genutztes Angebot geht als vielmehr um einen Dienst, der auch anderen zur Verfügung stehen soll. Selbstverständlich bleiben die bisher genutzten Namen für die bestehenden Listen verfüg- und nutzbar.

Praktisch finde ich, daß sich Mailman so konfigurieren läßt, daß - je nach dem Hostname, unter dem das Webinterface aufgerufen wird - jeweils nur die Mailinglisten angezeigt werden, die unter der entsprechenden Domain angelegt sind. Ein Aufruf von list.th-h.de bringt also ein anderes Ergebnis als ein Aufruf von lists.szaf.org (natürlich nur soweit die Mailinglisten überhaupt öffentlich angezeigt werden).

Zuverlässigkeit von E-Mail als Medium

Man sagt, E-Mail sei in früheren Zeiten technisch bedingt ein eher unzuverlässiges Medium gewesen: schmale Anbindungen, schwachbrüstige oder unter Leistungsgesichtspunkten knapp kalkulierte Server, Auslieferung über viele verschiedene Zwischenstationen (Hops), teilweise über Systeme, die nicht permanent ans Internet angebunden sind (store-and-forward), teilweise auch unzuverlässige Software, zumindest bei einem hinreichend breit gefaßten Begriff von E-Mail auch viele verschiedene, zueinander inkompatible Formate (Internet-E-Mail, X.400, Mail über UUCP, private Nachrichten in Mailboxnetzen, …), die untereinander umgesetzt werden mußten, teilweise über Netzgrenzen hinweg.

Das ist heute Vergangenheit. E-Mail wird in der Regel nur noch als "Internet-E-Mail" ausgetauscht, die betreffenden Server sind per ausreichend dimensionierter Standleitung ans Netz angebunden und entsprechend leistungsmäßig - wenn sich natürlich auch jede Infrastruktur durch genügend E-Mails, meistens im Rahmen der Versendung von Spam oder Malware, in die Knie zwingen läßt -, die Protokolle sind verfeinert und erweitert und man muß nicht mehr damit rechnen, daß irgendwelche Konvertierungen zu Informationsverlusten führen oder sich zwingend auf den ASCII-Zeichensatzvorrat (ohne Umlaute o.ä. oder gar "Anhänge") beschränken.

Dieser Zugewinn an technischer Sicherheit wird m.E. aber leider oft durch administrative Maßnahmen mehr als aufgewogen: technisch mag es zwar trivial sein, E-Mail auszuliefern, aber administrativ führen Abwehrmaßnahmen gegen tatsächliche oder vermeintliche Bedrohungen (Blacklists, Filterung jenseits technisch zwingender Notwendigkeit, Greylisting, Sender-Verification-Callouts, SPF und Co., BATV, DKIM und Co., Spam-, Viren- und andere Contentfilter etc. pp.) und nicht selten auch bloße Inkompetenz derjenigen, die "mal eben" einen Mailserver aufsetzen, dazu, daß die Mailzustellung faktisch langsamer und schwieriger wird und teilweise für den Absender noch nicht einmal erkenbbar wird, daß seine E-Mail den Adressaten nicht erreicht hat). Das gilt insbesondere, wenn verschiedene Filtertechniken oder Konfigurationen auf Absender- und Empfängerseite miteinander interagieren, was zu unerwarteten Folgen führen kann.

"Zuverlässigkeit von E-Mail als Medium" vollständig lesen
tweetbackcheck