© MorzKer, Photocase.com

IMAP und Co sind prima Protokolle für zuhause. Unterwegs auf Kleingeräten verwendet, fallen geringe Bandbreiten, knappe Prozessorleistungen und unterbrochene Verbindungen plötzlich ins Gewicht. Die Lemonade-Arbeitsgruppe steuert mit einem eigenen RFC gegen .

Blackberrys und I-Phones sind die Vorboten der mobilen Komponente des Kommunikationszeitalters. Bald zählt “Ich war gerade nicht am Arbeitsplatz” nicht mehr als Entschuldigung, eine wichtige E-Mail nicht gelesen zu haben. Im technischen Begleitgeschwader dieses Umbruchs fliegt seit August diesen Jahres Lemonade mit, “The Internet Email to Support Diverse Service Environments” (Internet-E-Mail zur Unterstützung verschiedener Dienst-Umgebungen).

Dieser Artikel stellt Lemonade so vor, wie RFC 5550 [1] das Protokoll-Bündel beschreibt, und untersucht seine Eignung für mobile E-Mail. Der Standard ist ein Produkt der Lemonade-Arbeitsgruppe [2] innerhalb der Internet Engineering Task Force (IETF). Im Kern fußt Lemonade auf SMTP [3], IMAP [4] und der Sieve Mail Filtering Language [5],[6], was eine gute Basis für E-Mail auf mobilen Endgeräten wie PDAs, Handys und Laptops bildet. Lemonade erweitert diese Protokolle so, dass es die Performance und Funktionalität der mobilen Endgeräte optimiert (Abbildung 1).

Abbildung 1: RFC 5550 ist ein Produkt der Lemonade-Arbeitsgruppe und fußt auf SMTP, IMAP und Sieve.

Lemonade serviert

Standard-IMAP speichert Mails auf dem Server und versetzt den Client in die Lage, Nachrichten selektiv herunterzuladen – wichtig für Geräte, die eine begrenzte Arbeits- und Speicherkapazität aufweisen. Lemonade nimmt sich der Themen an, die sich aus der oft niedrigen Bandbreite und hohe Latenz der Mobilverbindungen ergeben:

• Es erweitert SMTP und IMAP so, dass es den Overhead bei der
  Base-64-Kodierung binärer Daten in der E-Mail vermeidet
  (»8BITMIME« [7], »BINARYMIME« [8],
  »BINARY« [9]).
• Es verringert Traffic (TLS-Komprimierung in SMTP und IMAP [10],
  »COMPRESS=DEFLATE« [11] in IMAP).
• Schnelle Neusynchronisierung der Mailbox [12],[13].
• Verbesserte serverseitige Such- und Sortierfähigkeiten
  [14], [15], [16].
• Die Funktion “Weiterleiten ohne Download” [17],
  [18], [19], [20], die den Austausch zwischen dem Lemonade-Client
  und -Server beschreibt, um das Einliefern von neuen
  E-Mail-Nachrichten zu ermöglichen, die Content aus anderen auf
  dem Server gespeicherten Nachrichten einschließt.
• Lemonade konvertiert Anhänge [21].
• Unterstützen von Benachrichtigungen aus Mailstores [22],
  [23].
• E-Mail-Verarbeitung beim Zustellen [24], [25], [26].
• Verbesserte Fehlermeldungen, Benachrichtigung beim Zustellen
  von Nachrichten und so weiter.

Obwohl RFC 5550 ein relativ neues Dokument ist, gibt es bereits Implementierungen, die viele Features umsetzen.

8-Bit-Clean-Transport

Bei Standard-SMTP und -IMAP müssen die Clients binäre Anhänge Base-64-kodieren und -dekodieren, weil beide Protokolle keine 8-Bit-Daten zulassen. Das (De-)Kodieren verbraucht zusätzliche CPU-Leistung, was bei manch kleinen Gerät wie einem Handy zu Problemen führt. Da Base 64 die Anhänge um ein Drittel anschwellen lässt, steigt das Übertragungsvolumen, was unter Umständen dem Benutzer Kosten beschert.

Mit der »BINARY IMAP«-Erweiterung kann der Client Anhänge im rohen, binären Format down- und uploaden. Dank der »8BITMIME«- und »BINARYMIME«-SMTP-Erweiterungen übertragen Clients die Nachrichten selbst als Binaries. Steht »IMAP BINARY« oder »8BITMIME«/»BINARYMIME« nicht bereit, muss der Client entweder eine Kopie der Nachricht über SMTP Base-64-kodiert senden und uploaden. Alternativ überträgt er zwei Versionen der Nachricht: Eine mit binären Anhängen und eine mit Base-64-kodierten. Die meisten SMTP-Server, darunter Postfix, Sendmail oder MS Exchange unterstützen »8BITMIME«, viele Clients ebenfalls und manche verlangen es gar.

Komprimierung spart

Der 8-Bit-Transport allein komprimiert bereits. Lemonade geht jedoch weiter und verlangt, dass RFC-5550-konforme IMAP- und SMTP-Server als Teil des TLS-Supports ihre Daten mit der Zlib packen. IMAP darf die Komprimierung auch durch die »COMPRESS=DEFLATE«-Erweiterung realisieren, was clientseitig beispielsweise Thunderbird 3 unterstützen wird (siehe Artikel in der Sysadmin-Rubrik ab Seite 78).

Die Extention entstand, weil TLS oft zum System gehört und sich schwer erweitern lässt. Zlib spart oft Volumen: So verkleinerte ein IMAP-Server bei Tests mit dem E-Mail-Client Polymer ([27], Abbildung 2) mit aktiviertem »COMPRESS=DEFLATE« den Datenstrom auf 35 bis 40 Prozent der ursprünglichen Größe.

Abbildung 2: E-Mail-Client Polymer behrrscht als IMAP-Spezialist »COMPRESS=DEFLATE«.

Flottes Neusynchronisieren

Das Neu-Synchronisieren in einer IMAP-Sitzung verursacht Overhead und macht mobile Netzwerke für Verbindungsabbrüche anfälliger. Aus diesem Grunde beschreibt RFC 5550 eine Familie von Erweiterungen, die den Overhead reduzieren: Die IMAP-Extentions »CONDSTORE« [12] und »QRESYNC« [13] gestatten dem Client jede Mailbox schneller zu synchronisieren. Da erreicht er, indem er den Server bittet, nur Flag-Änderungen und Nachrichtenlöschungen zu liefern, die sich seit dem letzten Speichern ereignet haben. Klassisch sendet der die IMAP-Flags aller Nachrichten. Das reicht, um Änderungen mitzubekommen, die ein anderer Client in derselben Mailbox verursacht, beispielsweise das Handy. Auch ist die Verbindung nach einem TCP-Session-Abbruch schneller wieder intakt.

Tendenziell steigt der Nutzen der »CONDSTORE«-»QRESYNC«-Erweiterungen mit der Mailbox-Größe. Ohne die Erweiterungen lud der Client bei einer Test-Mailbox mit 3000 Nachrichten etwa 140 KByte Status-Daten zusätzlich herunter. Mit »CONDSTORE« rangiert der Traffic meist nahe null.

In extremen, aber seltenen Fällen, in denen sich seit der letzten Synchronisation mindestens ein Flag bei fast allen Nachricht geändert hat, verkehrt sich der Größenvorteil ins Gegenteil. Als Worst-Case-Test simulierte das Linux-Magazin eine »CONDSTORE«-Synchronisierung aller 3000 Nachrichten und erzeugte dabei 190 KByte an Status-Traffic.

Viele Open-Source- und proprietäre Server supporten bereits »CONDSTORE« und »QRESYNC«, so Cyrus, Dovecot, Zimbra, Isode M-Box und Sun. Clientseitig kommen Thunderbird 3 und Nokia Modest mit »CONDSTORE« klar.

Operationen auf dem Server

Bereits Standard-IMAP vermag serverseitig zu sortieren. RFC 5550 erweitert diese Funktionalität auf zweierlei Weise:

• Mit der »IMAP ESEARCH«-Erweiterung [15] fordert der
  Client die Ergebnisse einer Suche auf mehrere Arten an: Erstens die
  erste und letzte passende Nachricht, zweitens die Nachrichtenzahl
  oder drittens die passenden Nachrichten in kompakter Darstellung.
  Mit der Anzahl aktualisieren Clients ihre Zähler. Die
  Kompaktdarstellung minimiert Traffic: Bei einem Testlauf mit 28536
  Nachrichten, davon 8771 Spam, lieferte die Standardsuche
  »SEARCH KEYWORD Junk« eine Zeichenkette einer
  Länge von 52 KByte zurück. Die gleiche Suche mit
  »SEARCH RETURN (COUNT ALL) KEYWORD Junk« erbrachte ein
  Ergebnis von nur 21 KByte Länge.
• Die »IMAP CONTEXT=SEARCH«-Erweiterung [14] erzeugt
  virtuelle Ansichten von Mailboxen, beispielsweise um Nachrichten
  ohne Spam zu verarbeiten, die ab einem Datum eingegangen sind.
  Diese Technik beherrschen viele Desktops clientseitig. Sie
  unterstützt auf diese Weise schwachbrüstige Geräte,
  das Volumen der Nachrichten und deren Benachrichtigungsdaten zu
  minimieren. Die Funktion lässt sich auch auf sortierte
  Ansichten anwenden.

“Sie haben neue Mail!”

Alle gängigen Desktop-Mailprogramme bauen auf Initiative des Benutzers eine Verbindung zum Server auf, um nach neuen Nachrichten zu schauen. Parallel dazu schauen viele Clients selbsttätig in Intervallen nach neuer Mail, damit der Benutzer deren Eintreffen möglichst bald registriert. Auf mobilen Clients birgt dieses Polling allerdings zwei Probleme:

• Kurze Polling-Intervalle belasten das (eventuell
  kostenpflichtige) Netzwerk, das Mobilgerät sowie die
  Serverressourcen über die Gebühr. Bei Handys und
  ähnlichen mobilen Endgeräten saugt Polling zudem den Akku
  leer, weil es den Sleepmodus torpediert.
• Der Client benachrichtigt die Benutzer nur so oft, wie er neue
  Mail abruft und nicht in Echtzeit, wie es anspruchsvolle Benutzer
  erwarten.

Polling erweist daher als schlechte Lösung für die meisten Mobiles. Zum Glück gibt es Push-Mail. Blackberry-Geräte, der Funambol-Server und einige andere haben diese Technik populär gemacht.

In-Band-Push

Viele Server können Clients über eintreffende E-Mails benachrichtigen, sobald der Client einen beliebigen IMAP-Befehl absetzt. Dieser Ansatz ist ziemlich effizient. Allerdings empfangen die meisten Benutzer nicht genügend Nachrichten, um ihren Client für diese Technik aktiv genug zu halten. Die »IMAP IDLE«-Erweiterung [22] vermeidet das Polling des IMAP-Servers. Clients wie Thunderbird oder Outlook implementieren genauso wie Server bereits häufig diese Erweiterung [28].

Die Extension führt einen neuen IMAP-»IDLE«-Befehl ein, der den Server darüber in Kenntnis setzt, dass der Client eine Information über etwaige Änderungen der aktuellen Mailbox erwartet (siehe IMAP-Ablauf in Tabelle 1). Kommt die Benachrichtigung, storniert der Client den »IDLE«-Befehl und reagiert auf sie, indem er beispielsweise eine eingetroffene Mail abruft.

Allerdings hat die Idle einige Schwächen, die zur Entwicklung von RFC 5465 für »IMAP NOTIFY« führten [23]. So kann »IDLE« weder die vom Server zu generierenden Ereignisse steuern, noch wie der Client darüber zu benachrichtigen ist.

Out-of-Band

Als Alternative zum »IMAP IDLE«-Ansatz bietet sich ein Mechanismus an, mit dem der Server etwas an den Client sendet, wenn für diesen eine Nachricht eintrifft, ohne eine offene TCP-Verbindung zwischen beiden vorauszusetzen. Dieser Out-of-Band-Mechanismus ist besonders nützlich, wenn der Benutzer eher selten dringende Nachrichten bekommt. Dann kann der Client die IMAP-Verbindung zum Mailstore lange herunterfahren und schont den Akku.

Zugleich umgeht Out-of-Band eine weitere IMAP-Eigenheit: Aufgrund des Inaktivitäts-Autologout-Features müssen die Kommunikationspartner die IDLE-Verbindung spätestens alle 30 Minuten erneuern – sind NAT-Boxen im Spiel in der Praxis sogar noch häufiger. Dieser Wiederaufbau erzeugt Netzwerkverkehr, nicht viel, aber zum Client-Aufwecken reicht es.

Listing 1 demonstriert wie eine Out-of-Band-Benachrichtigung in der Praxis aussieht. Es benutzt die E-Mail-Skriptsprache Sieve [5],[24]. Der Sieve-Support ist übrigens Pflicht für jeden Lemonade-fähigen Mail Delivery Agent (MDA). Das Skript sendet die Benachrichtigung an einen XMPP/Jabber-Instant-Messaging-Account (IM), sofern das »enotify« des Server-Sieve »xmpp://« kennt und der betreffende IM-User online ist.

01 require ["enotify"];
02 
03 # Out-of-Band-Benachrichtigung über Meldungen vom Chef
04 if header :contains "from" "chef@example.org" {
05    #Mit XMPP über neue Nachricht informieren
06    if notify_method_capability
07       "xmpp:tim@example.com?message;subject=SIEVE"
08       "Online"
09       "yes" {
10          notify :importance "1" :message "Sie haben eine E-Mail vom Chef"
11       "xmpp:tim@example.com?message;subject=SIEVE";
12    }
13 }

Das Sieve-Skript in Listing 2 erzeugt Out-of-Band-SMS-Nachrichten, und zwar nur dann, wenn der Client nicht über IMAP mit dem Mailstore verbunden ist. Im Beispiel ist »+15105550101« die Zieltelefonnummer, »myaccount« der IMAP-Username des Skript-Besitzers auf dem »example.com«-Server. Die »notify_method_capability«-Bedingungen stellen fest, ob der angegebene Benutzer online ist.

01 require ["enotify"];
02 
03 #Out-of-Band-Benachrichtigung über Meldungen vom Chef
04 if header :contains "from" "chef@example.org" {
05    if not notify_method_capability
06       "imap://myaccount@example.com"
07       "Online"
08       "yes" {
09          notify :importance "1" :message "Sie haben Mail"
10       "sms:+15105550101";
11    }
12 }

Zwischen den Stühlen

Unterstützt die eigene Sieve-Engine die »sms:«-Benachrichtigungsmethode nicht, kann der Admin vielfach stattdessen auf die »mailto:«-Benachrichtigung zurückgreifen, sofern er ein E-Mail-an-SMS-Gateway zur Hand hat. Überhaupt hantieren die einzelnen Sieve-Engines mit unterschiedlichen Benachrichtigungsmethoden: So unterstützen Dovecot und Isode M-Box »mailto:«-Benachrichtigungen. Um die Portabilität der Sieve-Skripte zu verbessern, können diese die verfügbaren Benachrichtigungsmethoden mit einer »valid_notify_method«-Bedingungen abfragen – die Einzelheiten weiß [24].

Auch zu bedenken gilt, dass Sieve-gestützte Nachrichten eine ausführliche Konfiguration ihrer Engine voraussetzen. Beispielsweise erwarten SMS-Benachrichtigungen ein eingerichtetes SMS-Gateway, »mailto:« will einen konfigurierten SMTP-Server.

User, die eine SMS-Benachrichtigung über ein SMS-to-E-Mail-Gateway empfangen wollen, wegen ihrer Sieve-Engine aber keine »notify«-Aktion vorfinden, nutzen stattdessen die »redirect«-Aktion. Der Ansatz überlässt freilich die Einzelheiten der Konvertierung in SMS dem Gateway. Dabei bleibt unklar, wie das Gateway Anhänge handhaben wird, also ob es sie entfernt, konvertiert oder ob es die Nachricht komplett ablehnt.

Filtern bei der Zustellung

Sieve erlaubt E-Mails ziemlich flexibel zu verarbeiten. Neben dem bekannten E-Mail-Handling – beispielsweise dem Filtern und Einsortieren von Nachrichten für verschiedene Mailboxen – unterstützt sie automatische E-Mail-Benachrichtigungen für den Absender. Dazu eignet sich die Sieve »vacation«-Aktion [26]. Und: Trotz ihres Namens beschränkt diese Aktion nicht auf die Urlaubs-Auto-Replys, wie Listing 3 beweist.

01 require ["enotify", "vacation"];
02 
03 # Feststellen, ob der Absender der Team-Leader ist
04 if allof (envelope "from" "team-lead@example.net",
05           not notify_method_capability
06               "xmpp:myjid@example.com"
07               "Online"
08               "yes") {
09 
10 vacation :mime text:
11 Content-Type: multipart/mixed; boundary=foo
12 
13 --foo
14 Content-Type: text/plain; charset=us-ascii
15 
16 Ich bin momentan nicht greifbar.
17 Sie können mich diese Woche wie folgt erreichen.
18 
19 --foo
20 Content-Type: text/calendar; charset=UTF-8; method=PUBLISH
21 Content-Transfer-Encoding: 7bit
22 
23 BEGIN:VCALENDAR
24 VERSION:2.0
25 CALSCALE:GREGORIAN
26 METHOD:PUBLISH
27 BEGIN:VFREEBUSY
28 UID:901T095957Z-76A912@example.com
29 ORGANIZER:mailto:john_doe@example.com
30 DTSTAMP:20091012T083000Z
31 DTSTART:20091012T090000Z
32 DTEND:20091016T200000Z
33 FREEBUSY:20091012T090000Z/20091012T190000Z
34 FREEBUSY:20091013T090000Z/20091013T190000Z
35 FREEBUSY:20091016T090000Z/20091016T190000Z
36 COMMENT:Meine besetzten Zeiten für diese Woche
37 END:VFREEBUSY
38 END:VCALENDAR
39 --foo--
40     .
41 }

Ein genauso interessante Anwendung ist E-Mail-Nachrichten beim Zustellen zu markieren – am besten mit Sieves »imap4flags«-Erweiterung [25]. Zum Beispiel:

require ["fileinto", "imap4flags"];
if address :is "From" "myfriend@example.org" {
   addflag ["\Flagged", "NonJunk"];
   keep;
   stop;
}

Das Skript kennzeichnet Nachrichten mit »From: myfriend@example.org« im Header als wichtig (»Flagged«) und legitim. RFC 5550 bündelt viele E-Mail-Features, die für mobile Enduser nützlich sind. Setzen die angekündigten Voll-Implementierungen alle Eigenschaften um, dürfen sich Anwender freuen. (jk)