(Der englischsprachigen Zielgruppe wegen auf Englisch verfaßt.)
Recently I came across a severe bug which may cause random truncation of e-mails being sent through Lavabit’s custom SMTP-Server using Balsa, a mail client which users Libesmtp. At this point it is not completely clear if Balsa, Libesmtp or Lavabit is to blame, but after some testing and discussion on the Balsa mailing list, the developers deem the latter more probable.
The bug somehow evolves around paragraphs ending in a dot. Under certain circumstances, this dot may be sent to/intepreted by Lavabit’s SMTP server as a single dot on a line, which is the SMTP signal for “end of message”―or something like that, I do not have a great understanding of these matters. Anyway, the result is you having a perfectly normal copy of your outgoing mail in your outbox, while the recipients copy may be cut off after any paragraph.
(Update: To be clear, it is about single dots on lines. You can trigger the bug manually with a message body like this:
This line will get through.
.
This one won’t.
No one will probably ever do this intentionally, though. The danger comes from something behind the scenes causing trailing dots to be sent (or interpreted as if) on separate lines.)
Unfortunately, Lavabit has disabled their contact form for the time being:
“The friendly engineer whose [sic] been answering your questions has moved onto a more profitable endeavor; and were afraid that doesn't leave anybody available to monitor the suggestion box. The rest of our team is hard at work finishing a new version of our mail platform. So while we push towards a launch date and search for the right person to take over as spokesperson, we'll just have to disable this contact form.”
Does anyone reading this article have a means to pass a message about this bug to the Lavabit developers, or can do so him-/herself? While they are working on a new version of there software anyway, there should be a good opportunity to fix it.
If you were able to contact the Lavabit team, please let me know, so that I can update this article and they will not get spammed.
Other users of Balsa and Lavabit might try this clumsy workaround: Put a tab character (whitespace does not work) at the end of every paragraph ending in a dot. I have not tested it thoroughly, but on the first glance it seems to do the trick.
Angeregt von unseren intensiven Erfahrungen mit der Tatütheata-Produktion von Sartres Tote ohne Begräbnis haben zwei Freunde und ich vor ein paar Wochen das Experiment unternommen, den Text einer Folterszene durch Abschnitte aus Wittgensteins Philosophischen Untersuchungen zu ersetzen und jene isoliert aufzuführen. Zu sehen war das am 14. Juni auf der Offenen Bühne im Karlstortheater.
Für den Fall, daß jemand an unserer Textgrundlage interessiert ist und vielleicht sogar damit arbeiten will (würde mich freuen, davon zu hören!), hier ist sie:
- PDF-Dokument
- Lyx-Quelldatei
- Latex-Quelldatei (Lyx-Export)
Als ich vor einiger Zeit einmal die C++-Bibliothek JsonRpc-Cpp verwenden wollte, die – Überraschung – JSON-RPC implementiert, hat mich die ziemlich dürftige Dokumentation einige Zeit und Mühe gekostet. Am Ende hatte ich immerhin ein beispielhaftes Wart-Klient- (Server-Client-) Paar fertiggestellt, das vielleicht auch anderen Leuten als Anschauungsmaterial hilfreich ist. Hier sind die Quelltexte:
Kompilieren lassen sie sich, bei mir jedenfalls (Arch Linux, GCC), mit:
g++ -I/usr/include/jsonrpc/ -ljsonrpc server.cpp -o server
g++ -I/usr/include/jsonrpc/ -ljsonrpc client.cpp -o client
Danach einfach beide Programme jeweils von der Kommandozeile aufrufen und im Klienten nach Belieben Botschaften eingeben, welche der Wart brav widerhallen läßt.
Unklar sind mir Sinn und Zweck der Zeile „server.WaitMessage(1000);“ in server.cpp. Nach meinen Versuchen zu urteilen ist es völlig egal, welche Zahl dort eingesetzt wird. Die „1000“ und der Kommentar „/* select() time is 1 second */“ stammen aus der Original-Dokumentation.
Und noch ein Wort für die englischsprachigen Suchmaschinen unter unseren Lesern: JsonRpc-Cpp minimal example, JsonRpc-CPP server client example.
Wie gehabt schreitet die Technik dieses Netzstands geschwinder voran als sein Inhalt: Nun läuft, d. h. steht lemtank.de mit Ikiwiki. Insbesondere wird das alte, mit Nanoblogger erstellte „Grinseblog“ nun hier fortgeführt. Alle alten Artikel sollten erreichbar bleiben, werden aber bis auf Weiteres nicht ins neue System übernommen.
Warum Ikiwiki, warum nicht mehr Nanoblogger? Weil Nanoblogger, bei all seinen Vorzügen, unbequem langsam läuft, und weil Ikiwiki vielseitiger ist — ein Wiki halt, nicht nur ein Blog. Siehe auch Bastians Ankündigung seines Nanoblogger-Ikiwiki-Wechsels.
Die Grinsekatze wohnt nun nicht mehr im Namen des Blogs, sondern als Bild in der Seitenleiste. Vielen Dank an Martin für die Bildbearbeitung!
Mit der neuen, noch immer weiß-schwarz-grüne Aufmachung bin ich persönlich recht zufrieden, habe aber nach stundenlangem CSS-Ärger wohl keinen neutralen Blick mehr dafür – Anmerkungen und Kritik sind willkommen.
Genau, Anmerkungen: Kraft des externen Dienstes IntenseDebate können alle Artikel dieses Blogs kommentiert werden, wozu es allerdings brauserseitig Javascript braucht. Die Ikiwiki-Einbindung ist momentan weder elegant noch für mich komfortabel – hat jemand Erfahrung mit IntenseDebate und Ikiwiki? –, und ich habe bis jetzt nicht herausgefunden, wie ich die Schriftart des Kommentar-Eingabefeldes per CSS verändern kann – weiß das jemand? –, deswegen betrachte ich diese Sache noch als experimentell.