Im frisch erschienenen RFC 5550 wird eine ganze Reihe von IMAP-Erweiterungen beschrieben, welche hauptsächlich für mobile Geräte sinnvoll erscheinen.

Für Geräte mit wenig Bandbreite oder limitiertem Übertragungsvolumen, was auf jene die per Mobilfunk angebunden sind in den allermeisten Fällen zutrifft, sind sicherlich die Kernfunktionen "Forward without download" und "Message size declaration" besonders interessant. Letztere legt fest, dass der sendende Server bereits im MAIL FROM-Kommando die Größe der Nachricht angibt und der empfangende SMTP-Server anhand der Angabe dann entscheiden kann, ob er die Mail überhaupt annehmen möchte. Für Mailboxen, auf die ausschließlich von unterwegs zugegriffen wird, eine hervorragende Sache. "Forward without download" erlaubt einem IMAP-Client, Nachrichten direkt auf dem Server an eine andere Adresse weiterzuleiten, ohne diese vorher herunterladen und "neu verpacken" zu müssen. Diese Funktion bieten bisher nur propritäre Mail-/Groupware-Lösungen, wie z.B. der Blackberry Enterprise Server von RIM.

An die Sicherheit der zu übertragenden Informationen wurde ebenfalls gedacht. So setzt Lemonade von vornherein den Einsatz von SMTP-TLS voraus.

Die wohl wichtigste Änderung in Pidgin 2.6.1 ist der Fix einer Sicherheitslücke, die es einem Angreifer ermöglicht, mithilfe von manipulierten MSN-SLP-Paketen einen Buffer Overflow zu verursachen.

Darüberhinaus kann die libpurple, auf der Pidign basiert, jetzt Audio- und Videochats. Pidgin unterstützt zunächst Audio-Chats für das XMPP-Protokoll (Jabber), sowie Videoclips in Verbindung mit dem Googlemail-Webclient.

Ja, Jabber/XMPP-Kennungen sehen aus wie Mailadressen. Und um langwierigen Erklärungen vorzubeugen, habe ich vor einigen Tagen beschlossen, meine Jabber-Kennung meiner Mailadresse anzupassen. Zu diesem Zweck habe ich kurzerhand einen ejabberd installiert. Die grundsätzliche Installation dieses Daemon ist unkompliziert und daher an dieser Stelle nicht weiter erwähnenswert.

Wie es sich für einen standardkonformen XMPP-Server gehört, kennt der ejabberd natürlich auch Kryptographie. Allerdings wird bei der Installation standardmäßig ein eigenes SSL-Zertifikat generiert. Und eben dieses wollte ich durch ein bereits vorhandenes CAcert-Zertifikat ersetzen. Soweit die Idee…

ejabberd generiert nämlich exakt eine pem-Datei und nicht zwei (Privatekey-/Certificate-Paar). Wenn man hier nur das eigentliche Zertifikat von CAcert angibt, wird das natürlich nichts mit der Authentifizierung.

Nach ewiger und erfolgloser Suche nach der Lösung hatte ich dann doch noch die (denkbar simple) Idee: Nach einem Blick in das von ejabberd installierte Zertifikat war klar, dass sowohl Privatekey, wie auch das Serverzertifikat einfach nacheinander in einer Datei untergebracht werden müssen. Dann noch an die richtigen Dateirechte für die Zertifikatdatei denken (nicht vergessen, wie ich im ersten Versuch) und anschließend spielt der ejabberd auch mit CAcert.

Das gleiche funktioniert dann voraussichtlich auch mit anderen Anwendungen, wie beispielsweise znc. Das hoffe ich jedenfalls…