Bernds Blog

Heute stieß ich auf eine Merkwürdigkeit: Die Partition /var/log war zu über der Hälfte voll, mit du -hsc /var/log/* waren aber nur ein paar MB belegt. Die Ursache war uns klar, das Problem hatten wir schonmal: Ein Programm hat eine Datei noch geöffnet, die aber bereits gelöscht ist. So wird Speicherplatz belegt, man findet aber keine Datei dazu.

Als Lösung war mit bisher nur bekannt, das Programm mittels lsof /var/log/| grep deleted zu identifizieren und neu zu starten, damit es die Datei-Handles aufgibt und die gelöschten Dateien wirklich gelöscht sind. In diesem Fall war es aber der MySQL-Server und wir hatten grade einen leistungsintensiven Import am Laufen, so dass mir das Risiko zu hoch war, den MySQL-Server neu zu starten bzw. ein SIGHUP zu senden. Gleichzeitig war aber die Gefahr groß, dass die Platte vollläuft, bevor der Import abgeschlossen ist.

Als praktisch hat sich dann das Werkzeug truncate erwiesen. Das kürzt eine offene Datei auf eine feste Größe und schiebt den Dateizeiger ebenfalls auf diese Position. Damit kann man eine Datei leeren ohne dass der andere Prozess sein File-Handle schließen muss: truncate -s0 /proc/19580/fd/11

Die Tage kam bei schokokeks.org die Notwendigkeit nach einem zusätzlichen Server auf, der nichts anderes machen sollte als Backups von einigen bestehenden Maschinen entgegen zu nehmen. Der Server soll als virtuelles Gastsystem betrieben werden, da die erwartete Last minimal ausfällt. Da wir stets versuchen, IPv4-Adressen nicht zu vergeuden, wollte ich diesen Server als IPv6-only-System in Betrieb stellen.

Das hat grundsätzlich gut geklappt, es gab aber einige Stellen die (für mich unerwarteter Weise) Probleme bereitet haben.

1. OpenVPN kann nicht über IPv6. Mit der Version 2.3 soll das angeblich anders werden, die gibt es aber bisher noch nicht. Meine Lösung war, dass ich eine private IPv4-Adresse eingerichtet habe, die der physikalische Server auf einen anderen Server routet, der ebenfalls eine passende private IPv4-Adresse hat. Dadurch kann OpenVPN über diese IPv4-Verbindung kommunizieren.


2. Die normalen Gentoo-Mirror-Dienste beachten kein IPv6 und liefern im Round-Robin einfach irgendwas zurück, was ich dann nicht aufrufen kann. :( Die Lösung war, gezielt SYNC-Server und Distfiles-Mirror einzutragen die IPv6-Verbindung liefern. Die Listen gibt es hier (sync-Mirrors) und hier (Distfiles-Server). Jeweils die mit Sternchen sind IPv6-fähig.


3. Wir betreiben normalerweise lokale DNS-Resolver auf jedem Server. Für diesen speziellen Zweck ist das okay, aber man kann halt nur Namen auflösen, die auch über IPv6-fähige DNS-Server angeboten werden. IPv6-Paradebeispiel Heise online geht z.B. nicht, da deren DNS-Server keine IPv6-Adressen haben. Um etwas mehr Möglichkeiten zu haben, kann der Google-Public-DNS benutzt werden: 2001:4860:4860::8888.

Letztlich ist OpenVPN der einzige Grund, dass auf der Maschine überhaupt eine IPv4-Adresse eingerichtet ist. Und das soll sich ja angeblich mit dem nächsten Release, für das bereits ein RC angeboten wird, ändern. Ich bin jedenfalls gespannt.

Unsere normalen Serverdienste betreiben wir schon seit Jahren im Dualstack. Vor einigen Wochen wurde der Linux-Default-Resolver auch so geändert, dass er IPv6 bevorzugt, da hatten wir ein Localhost-Problem (Zugriffe auf localhost kamen dann von ::1 und nicht mehr von 127.0.0.1, da mussten einige Konfigurationen angepasst werden). Aber ansonsten bereitet uns der Dualstack-Betrieb keine Schwierigkeiten.

Ich musste neulich einen Rechner vollständig neu installieren und haben daher vorab neben einer Sicherung der Dateien ein HDD-Image erstellt um für den Fall der Fälle alles nochmal verfügbar zu haben.

Danach, wie es eben so ist, stellte ich Inkonsistenzen der kopierten Dateien fest und wollte auf dem gemachten Image nochmal nachschauen und die Dateien von dort nochmal kopieren. Leider war ich nicht schlau genug, einzelne Partitions-Images der stark partitionierten Festplatte zu machen sondern habe nur ein komplett-Image, das sich so natürlich nicht als Loopback mounten lässt.

Doch nach kurzer Recherche fand ich heraus, dass das gar kein Problem ist. Man muss nur mittels fdisk -l sda.img die Start-Sektor-Nummer der gewünschten Partition bestimmen, diese mit 512 multiplizieren und hat dann die Startposition der Partition in Bytes.

Mit dem Befehl
mount -o loop,offset=12345678 sda.img /mnt/image
lässt sich dann das Dateisystem dieser Partition direkt mounten.

Vermutlich ist das mal wieder eine meiner Wissenslücken, die man eigentlich nach so langer Erfahrung nicht mehr haben sollte, aber das hatte ich bis gerade eben wirklich nicht gewusst (weil nie gebraucht). :)

Bedingt durch das neueste Ubuntu-Release vor gut einer Woche musste ich in den letzten Tagen ein paar Rechner aktualisieren. Dazu empfiehlt sich natürlich vorher ein möglichst gutes Backup.

In einem Fall musste ich einen Rechner komplett sichern, den ich nachher 1:1 wieder herstellen möchte (auf ähnlicher aber anderer Hardware). Damit das Restore nachher möglichst schnell und einfach funktioniert, entschied ich mich dazu, dass ich /dev/sda als Komplettimage sichern möchte. Leider habe ich keinen Rechner, auf dem ausreichend Platz für das komplette Image ist. Die Festplatte ist aber nur zu einem kleinen Teil wirklich belegt. Die Erwartung war also, wenn ich das Image sofort komprimiert abspeichere, dann müsste es auf jeden Fall passen, denn leerer Platz sollte gut komprimierbar sein.

Der Transfer sollte über eine netcat-Pipe laufen (ssh-tunnel wäre auch möglich, hat aber mehr overhead).

Das Problem an der Sache war, dass ich keine Informationen über den laufenden Fortschritt der Aktion sehen konnte. Auf dem Quellrechner kann man nicht sehen, wie viel von dem Device schon ausgelesen ist und auf dem Zielhost habe ich keine Ahnung, wie groß die endgültige komprimierte Datei werden würde.

Ein kurzes Überlegen brachte mich zu der Idee, dass es eigentlich eine triviale Aufgabe sei, ein Programm zu erstellen, das einfach Daten auf stdin liest, nach stdout schreibt und dabei mitzählt und die Zahl regelmäßig ausgibt.

Bevor ich selbst Hand anlegte, suchte ich kurz im Netz und fand auch recht schnell eine Lösung: pv, steht für »pipe viewer« und macht exakt genau dieses. Das Tool kann entweder einfach mitzählen oder man gibt ihm per Parameter die erwartete Gesamtgröße der Daten, dann erhält man eine wget-ähnliche Ausgabe mit Restzeit und Prozentbalken.

Das Tool gefällt mir so gut, dass ich es sogleich für diverse andere Aktionen ebenfalls einsetze.
Dies kann dann etwa so aussehen (bei einer tar-Pipe über netcat):

$ nc -l 10.0.0.2 1111 |gunzip| pv -s 40053354750| tar x

14,6GB 0:53:34 [ 5,2MB/s] [=========>                    ] 39% ETA 1:22:55

In diesem Beispiel habe ich auch gleich das gunzip vor pv gesetzt, damit ich die wirklichen Daten zähle und nicht die komprimierten. Auf dem Quellhost arbeitet hier ein einfacheres tar xz . | nc ....

Ach ja, Fußnote: Für das eingangs genannte Szenario sollte man das gute alte gzip benutzen. Da ich möglichst gut komprimierte Daten wollte (schließlich hatte ich wenig Platz), entschied ich mich für xz als Kompressionsprogramm. Das ist aber so dermaßen langsam, dass es auch auf meinem DualCore-Rechner nur etwa 1 MB pro Sekunde komprimierten konnte und damit den ganzen Vorgang auf viele Stunden ausgedehnt hat. Leeren Platz komprimieren hätte aber auch gzip hin bekommen.

Schon seit einer Weile stört mich, dass ein handelsüblicher Desktop-PC mit etwa 80 Watt Stromverbrauch und einem Geräuschpegel Marke »Kopfschmerzen« so viel Leistung erzeugt, dass man damit prinzipiell alles machen kann was man nie machen wird.

Daher habe ich versucht, mich an diversen Quellen über die neuen Minimalrechner, genannt »NetTop«, zu informieren. Nachdem das mehrfach missglückt ist und keiner Erfahrungen dazu hatte, habe ich mir jetzt einfach mal eine ASUS eeeBox B202 gekauft um damit selbst zu experimentieren.

Vor dem Kauf fällt auf, dass es dieses Gerät (wohlgemerkt unter der selben Modellbezeichnung) entweder mit einer Ausstattung von 2 GB RAM und einem Linux-Betriebssystem oder mit 1 GB RAM und Windows XP Home verkauft wird.
Eine RAM-Erweiterung ist zwar (nach diversen Berichten) nur mit Schraubendreher und sanfter Gewalt beim Öffnen des Gehäuses möglich, aber es stehen zwei Slots zur Verfügung.
Um das 1-GB-Modell also auf 2 GB zu erweitern benötigt man kostenverursachenderweise nur einen 1-GB-SO-DIMM-Riegel, der im freien Markt momentan ca. 10-15 € kostet.

Wenn man jetzt also unterstellt, dass das Linux-System keine nenneswerten Lizenzkosten verursacht und der Aufwand, en ASUS zur Anpassung von Windows betreibt in etwa gleich ist wie der, den ASUS zur Anpassung ihres Linux-Systems treibt, dann ist zu erwarten, dass das Windows-Modell um die Windows-Lizenz minus 10-15 € teurer ist. Da man natürlich nicht weiß, was eine Windows-XP-Lizenz für einen Großabnehmer kostet, muss ich das empirisch herausfinden.

Da sich das Angebot bzgl. der Verfügbarkeit und der Preise momentan mehrmals täglich ändert, ist der Preisspiegel meiner Bestellung jetzt nicht mehr so extrem nachzuvollziehen:
Letzte Woche wurde die Linux-Variante mit 2 GB RAM um etwa 20 € teurer verkauft als die Windows-Variante.
Das macht einen Windows-Lizenzpreis von -5-10 € pro verkauftem Gerät.

Da bei mir noch nicht absehbar war, wo genau das Gerät später eingesetzt wird und ob dafür die Windows-Lizenz eine Relevanz hat, habe ich mich für diese entschieden, da es mich insgesamt einfach billiger kommt, selbst wenn ich das RAM-Upgrade noch machen möchte.

Schließlich ist es also so, dass sich keiner wundern braucht, dass sich die Windows-Version so viel besser verkauft, da die Linux-Version wirtschaftlich einfach keinen Sinn macht. Und auf einem Desktop-Rechner den man für die tägliche Arbeit einsetzen möchte, würde ich auch ungern das on ASUS vorgekaute Minimalsystem einsetzen sondern lieber ein aktuelleres, Community-gepflegtes System.

Heute bzw. gestern Abend kamen mal wieder ein paar Artikel zum geplanten E-Mail-Dienst des Innenministeriums namens »DE-Mail« in der Onlinepresse.

Kurz gefasst denke ich, dass dieses Projekt das Potenzial hat, sich in eine Reihe unrühmlicher Geldgräber einzugliedern.

Besonders gefallen hat mir der Heise-Artikel dazu. Ich möchte mal etwas pedantisch auf ein paar Abschnitten herumreiten:

Schallbruch teilte auch die Kritik aus dem Bereich der kommunalen Anwender des OSCI-Standards (Online Services Computer Interface) nicht, wonach auf dieser Basis bereits Möglichkeiten zum verschlüsselten E-Mail- und Dokumentenversand über gängige Mail-Adressen bestünden. Dafür bräuchte es bei allen Kommunikationspartnern komplizierte Verschlüsselungsarchitekturen. Beide Seiten müssten auf ihrem eigenen PC einen OSCI-Client installieren, wobei keiner für die Systemsicherheit bürgen könne.

Der neue Dient wird also »sicher«. Absolut sicher. Schließlich verbürgt sich da jemand dafür. Ich frage mich nur: Wer? Wenn ich den Dienst nutze und ein Sicherheits-Problem auftritt. Wer zahlt mir dann eine Entschädigung? Der Bund? Die beteiligten Firmen? Der Vorstandsvorsitzende der verantwortlichen Firma? Oder ist diese Art des Verbürgens vielleicht eher sowas wie: »Wenn es ein Problem gibt, werden wir aber ganz energisch mit dem Zeigefinger fuchteln bis jemand sagt, dass wir das in Zukunft besser machen«?

Zugleich verwies der IT-Direktor auf hohe Kostensenkungseffekte. Wenn allein acht Prozent des derzeitigen Postverkehrs über das neue Verfahren abgewickelt würden, könnten die Absender eine Milliarde Euro Porto sparen. Dieser Summe stünden Aufwendungen für den Aufbau der Kommunikationsinfrastrukturen gegenüber.

Okay, auch wenn wir mal annehmen, dass mit dieser vorsichtigen Formulierung nicht ausgeschlossen werden soll, dass die Milliarde sofort wieder in die Kommunikationsinfrastruktur gepumpt wird, dann verliert die Post also eine Milliarde (in einem nicht genannten Zeitraum, möglicherweise pro Jahr). Diese Milliarde wird dann also als Finanzhilfe wieder investiert weil es dem Konzern dann plötzlich schlecht geht wenn keiner mehr Briefe verschickt. Ergo: Milchmädchenrechnung.

Aber das sind ja Details. Richtig schlecht wird mir dann bei sowas:

Die ganzen Sicherheitsmechanismen sollten beim Provider im Hintergrund ablaufen, um die Nutzung so einfach wie möglich zu machen. So sei dort etwa eine Kontrolle auf Schadsoftware und eine Versandberechtigung, die Integritätssicherung über eine Prüfsumme, die Verschlüsselung über S/MIME und eine Ergänzung von Metadaten durchzuführen.

Bitte nochmal langsam lesen.
Ja, die begründen ihre Sicherheit wirklich damit, dass beim Provider die Daten verschlüsselt werden. Damit der seine Daten dort eintragen kann wird dann vermutlich eine normale end-to-end-Verschlüsellung nicht vorgesehen werden oder wie? Zudem: Schadsoftware? Hieß es nicht eben noch, der Dienst sei spamfrei? Ist er vielleicht nur ein bisschen spamfrei?

Hatte neulich bei einem Desktop-PC versehentlich die Tastatur in den Maus-PS/2-Port eingesteckt. Dank USB-Maus hab ich das Versehen nicht bemerkt.

Linux bootete auch ganz normal und es hat alles funktioniert.

Dann ist mir aufgefallen, dass das BIOS vor dem boot recht lange wartet und dann sagt "No keyboard found".

Linux hat die Tastatur aber trotzdem benutzen können. Als ob nichts wäre. Das find ich mal cool. :)

Hier mal kurz eine Erfahrung von heute, auf dass dies vielleicht andere finden, die sich in der selben Situation wiederfinden.

Gestern Abend teilten mir meine Eltern mit, dass ihr Rechner keinen Login mehr macht. Egal welcher Benutzer sich anmeldet, es bleibt immer sofort nach Verschwinden der Login-Maske alles stehen.

Nach einigem Debugging habe ich erstmal aufgegeben (es war spät) und heute früh weiter gemacht. Im Netz habe ich auch nicht wirklich was gefunden was passend war.

Der Lösung näher kam ich als ich ein simples xterm (mittels xinit bzw. .xinitrc) gestartet habe und dort dann "strace kwin" aufgerufen habe. Damit zeigte sich, dass der Prozess beim Locking auf die ~/.qt/.qtrc.lock stehen blieb. Da das NFS-Homedir schon manchmal beim Locking Probleme hatte, habe ich also getippt, es kann daran liegen. Laut rpcinfo -p war aber der nfslockd aktiv.

Über einiges trial und error und den entscheidenden Fund im Netz, dass das Locking Probleme macht, wenn der Server die IP-Adresse des Clients nicht auflösen kann, bin ich dann darauf gestoßen, dass der bind auf dem Server aus mir unerklärlichen Gründen sich nicht für die lokale reverse-Zone zuständig gefühlt hat. Ein einfaches Restart des bind hat genau das behoben, ab dann waren auch lokale reverse-lookups wieder möglich.

Der NFS-Server hat die Situation aber nicht verkraftet, einen restart-Versuch hat er immer mit einem Segmentation fault verweigert. Als ich dann aber den Server-Rechner neu gestartet habe, hat wieder alles wunderbar funktioniert. ohne das ich irgend etwas ändern musste.

Gestern habe ich vom neuen CAcert Assurer Test gelesen:

To meet the increased demands on quality assurance due to the CAcert Systems Audit, which is needed to be included in Mozilla’s browsers, CAcert has decided to initiate a Challenge for all for Assurers.
To be an Assurer, you will need to reach 100 assurance points, and you will have to pass the Assurer Challenge. The assurer challenge and training system called CATS is so now avaliable. Under http://wiki.cacert.org/wiki/AssurerChallenge you can find the infos how to join and participate.

Natürlich war ich gleich neugierig und habe den Test absolviert. Da ich schon mehrfach auf Fachmessen für das CAcert-Projekt am Stand tätig war, war der Test inhaltlich machbar. Zeitbedarf: deutlich unter 10 Minuten.

Das Problem an der Sache begann danach. Um das Zertifikat »Certified CAcert Assurer« als PDF ausgestellt zu bekommen, muss man eine möglichst verschlüsselte und zwingend mit seinem X.509-Client-Zertifikat signierte E-Mail an CAcert senden.
Und eben das ist mit KMail zur Zeit eine völlige Katastrophe. Zeitbedarf für mich: 1 Tag. ;-)

Der Reihe nach:
KMail benutzt gpgsm zur Verarbeitung von S/MIME. Das Frontend Kleopatra erlaubt das halbwegs komfortable Einfügen meines Zertifikats in gpgsm. Damit gpgsm überhaupt irgendwelche Zertifikate benutzt, will es eine CRL konsultieren:

gpgsm[12626]: can't connect server: `ERR 50331917 can't exec `/usr/bin/dirmngr': Datei oder Verzeichnis nicht gefunden'
gpgsm: can't connect to the dirmngr: IPC "connect" Aufruf fehlgeschlagen
gpgsm: certificate #04BD1F/1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: Die CRL konnte nicht geprüft werden: Kein Dirmngr
gpgsm: error creating signature: Kein Dirmngr <GPGSM>

CRLs sind eigentlich grundsätzlich sinnvoll, aber nicht bei gpgsm. Um nämlich bei gpgsm eine CRL zu benutzen, braucht man dirmngr. dirmngr braucht dazu aber auch OpenLDAP und man muss beide Kollegen manuell konfigurieren. Es gibt zumindest bei Gentoo keine dafür brauchbare Standard-Konfiguration.

Also will man bei gpgsm lieber auf eine CRL verzichten. Dazu muss man die Option disable-crl-checks in die Datei ~/.gnupg/gpgsm.conf eintragen.

Das nächste Problem sieht so aus:

gpgsm: Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: BEGIN Certificate `issuer':
gpgsm: DBG: serial: 00
gpgsm: DBG: notBefore: 2003-03-30 12:29:49
gpgsm: DBG: notAfter: 2033-03-29 12:29:49
gpgsm: DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.4
gpgsm: DBG: SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: Interaktives vertrauenswürdig-Markieren ist in gpg-agent ausgeschaltet
gpgsm: error creating signature: Nicht vertrauenswürdig <GPG Agent>

Der hervorgehobene Teil führt zum Ziel; man muss in der Datei ~/.gnupg/gpg-agent.conf die Zeile allow-mark-trusted eintragen.

Damit der gpg-agent das auch weiß, muss er neu gestartet werden. Überflüssig zu erwähnen, dass natürlich alle Programme, die den gpg-agent verwenden möchten auch neu gestartet werden sollten. Insbesondere gilt das bei KDE und KMail so, dass KDE neu gestartet werden muss.

Nach dieser Prozedur fragt gpg-agent bei Bedarf in kaputtem UTF-8 nach, ob das Zertifikat okay ist. Bestätigt man das, stürzt er erst einmal ab:

*** glibc detected *** gpg-agent: free(): invalid next size (fast): 0x000000000065d190 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ac27fb11b7d]
/lib/libc.so.6(cfree+0x76)[0x2ac27fb13896]
gpg-agent[0x415452]
gpg-agent[0x409649]
gpg-agent[0x428a38]
gpg-agent[0x40867c]
gpg-agent[0x407851]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ac27fac01f4]
gpg-agent(realloc+0x1e1)[0x4053c9]
======= Memory map: ========
[...]

Beim nächsten Versuch sollte aber alles soweit klappen.


Damit konnte ich dann eine X.509-signierte und -verschlüsselte E-Mail senden.

Am nächsten Morgen ...

Heute war dann die Antwort von CAcert da, eine E-Mail mit ~140 KB. KMail sagt dazu:

Verschlüsselte Nachricht (keine Entschlüsselung möglich)
Grund: Nicht unterstütztes Verfahren
smime.p7m
S/MIME Encrypted Message

Ende der verschlüsselten Nachricht

Um dieses Problem weiter einzugrenzen habe ich die Datei smime.p7m gespeichert und mit gpgsm auf der Konsole versucht, weitere Infos einzuholen:

$ gpgsm -v --decrypt smime.p7m
gpgsm: unsupported algorithm `1.2.840.113549.3.2'
gpgsm: (Dies ist der RC-2 Algorithmus)
gpgsm: message decryption failed: Nicht unterstütztes Verfahren <GPGSM>

Eine kleine Internet-Such-Aktion später war klar: gpgsm unterstützt den alten RC2-Algorthmus schlicht und einfach nicht mehr. Thunderbird meint aber leider viel zu oft, diesen benutzen zu müssen.

Einzige mir sinnvoll erscheinende Lösung: Ich habe Mozilla Thunderbird installiert, dort meinen IMAP-Zugang konfiguriert, mein X.509-Zertifikat importiert und mit diesem die E-Mail geöffnet und das angehängte PDF gespeichert.


Nach knapp 10 Minuten Assurer-Prüfung und etwa einem Tag Kampf mit S/MIME bin ich nun also offiziell Certified CAcert Assurer Nummer 78. ;-)

In den letzten Tagen gab es zwei interessante Vorkommnisse mit Mailinglisten unserer Fachschaft. Es sind jeweils Adressen auf der Mailingliste gelandet, die da nicht hin gehören.

1. Die -subscribe-Adresse befand sich plötzlich auf der Mailingliste

   
   Bei jeder Mail an die Mailingliste bekam der Absender eine »please confirm that you want to subscribe to ...«-Mail. Auslöser des Problems war eine Spam-Mail, die als Absender und als Empfänger die -subscribe-Adresse gesetzt hatte.



2. Ein unbedarfter Empfänger irgendwo in den USA war plötzlich auf unserer (deutschsprachigen) Mailingliste

   
   Auslöser war sein Autoresponder, der die Nachricht beantwortet hat. Der Request wurde von einer Spam-Mail provoziert und sein autoresponder hat ihn auf die Liste gesetzt.

Mir gefallen diese Vorkommnisse gar nicht. Eigentlich bin ich ein Freund von E-Mail-basierten Mailinglist-Managern (wie z.B. ezmlm oder der von uns benutzte couriermlm) da sie für den Benutzer einfach (ja, ich weiß, sichtweise) zu benutzen sind und vor allem kein Medienbruch stattfindet. Diese beiden Vorkommen sind aber der Beweis dafür, dass das mit dem double-opt-in so ganz trivial auch nicht über E-Mail machbar ist.

Ich seh schon den Kommentar im Voraus, dass couriermlm doch eigentlich bitte ein »YES« in der Betreffzeile haben möchte wenn man sich einträgt. Nur kann man diese Option auf einer überwiegend deutschsprachigen Mailingliste glatt mal vergessen. Schon alleine die Verwendung eines E-Mail-basierten Mailinglisten-Managers stellt einen gewissen Teil unserer Informatik-Studenten (!) vor ungeahnte Probleme. Das einfache Antworten auf die Mail konnten wir mit einer detaillierten, deutschsprachigen Anleitung hin bekommen, aber mit dem YES-eintragen, das hat nicht geklappt. ;-)
Aus diesen Gründen betreiben wir die Mailingliste mit ausgeschaltetem »YES«-Zwang, was uns jetzt vor das Problem stellt, dass Leute auf der Liste stehen, die das gar nicht wollen...