Was ist denn das für eine komische Mailadresse?

mh+irgendwas@zugschlus.de ist eine so genannte geplusste Mailadresse. Dieser Mechanismus war schon vor zwanzig Jahren praktisch und ist dann im Zuge der verDAUung des Internets irgendwie in Vergessenheit geraten.

Das ganze funktioniert so: EIne normale Mailadresse a@example.com zerfällt in zwei Teile, den so genannten Localpart und die Domain. Ein System, das eine Mail eingeliefert bekommt und sie zustellen möchte, entscheidet zuerst anhand der Domain, ob es eine Mail ist, für die es selbst zuständig ist (“lokale Mailadresse”) oder nicht.

Wenn es nicht für die Mail zuständig ist, weil die Mail an eine fremde Domain adressiert ist, sucht es sich im allgemeinen Normalfall aus dem DNS den Mail Exchanger (“MX”) für die Domain heraus und liefert die Mail dort ab. Im Nichtnormalfall hat es irgendwelche internen Policies darüber, was mit einer nichtlokalen Mail anzufangen ist. Gängig ist hier zum Beispiel die Auslieferung aller nichtlokalen Mails an einen anderen Rechner, der sich dann genauer um die Auslieferung kümmert (“Smarthost”). Dies ist die Methode, mit der Endsysteme ihre Mail üblicherweise ausliefern. Wichtig ist, dass sich das System bisher nur für den Domainpart, also das, was in der Empfängeradresse hinter dem Klammeraffen steht, interessiert hat.

Interessanter ist der Fall, in dem das System zum Schluss kommt, selbst für die Mail zuständig zu sein: Erst dann wird der Local Part (im obigen Beispiel das “a” links vom Klammeraffen) interessant. Anhand mehr oder weniger komplexer Regeln identifiziert das System nun einen Ort, wo die neue Mail abzulegen ist. Im einfachsten Fall in der Unix-Welt wird die Mail einfach an die entsprechende Mailboxdatei in /var/spool/username angehängt; gängig ist aber auch die Auslieferung in ein sogenanntes Maildir unter dem Homedirectory des entsprechenden Systembenutzers. Besonders auf Systemen, von denen die Mail schließlich mit einem anderen Verfahren (z.B. UUCP, IMAP oder POP3) abgeholt wird, kann die Mail auch irgendwo anders landen, wo der Speicherort nicht mit einem Systemaccount verknüpft sein muss. Auch die Zustellung in eine Datenbank ist denkbar (und in der Windowswelt ungleich üblicher als auf unixoiden Systemen). Bei der lokalen Zustellung wird oft nur der Localpart berücksichtitg, so dass abc@example.com und abc@example.org jeweils auf dieselbe Mailbox zeigen. Das ist aber ein Relikt aus vergangenen Tagen, so dass man heute im allgemeinen davon ausgehen kann, dass die komplette Mailadresse, bestehend aus Local Part und Domain, für die Ermittlung des Ablageorts berücksichtigt wird. Auf unixoiden Systemen ist das aber immer noch nicht der Standardfall, so dass hier ohne manuellen Eingriff des Administrators beim Aufsetzen des Systems oft überraschende Dinge entstehen.

Nun zum eigentlichen Punkt dieses Artikels: Sendmail hat die Option (die IIRC sogar im Default eingeschaltet ist), den Local Part nochmal in zwei Teile zu unterteilen, die durch ein Pluszeichen voneinander getrennt werden. Eine solche Mailadresse könnte zum Beispiel local+suffix@example.com lauten. Bei der Zustellung berücksichtigt Sendmail ausschließlich den “local”-Teil und ignoriert den Rest. So landet Mail an local+suffix1@example.com und local+suffix2@example.com ohne weitere Konfiguration in derselben Mailbox.

Nun wird es interessant: Einem Filter, den der Empfänger in seinem Account betreibt, steht jedoch die komplette Mailadresse zur Verfügung. Der Empfänger kann also selbst konfigurieren, ob Mails an local+suffix1@example.com und local+suffix2@example.com gleich oder unterschiedlich behandelt werden können - und das ganz ohne dass der Administrator des Mailservers dafür besondere Maßnahmen ergreifen muss: Das Feature ist einfach im Default aktiv und stört im Normalbetrieb kaum einen.

Ich habe diese Funktion schon seit vielen Jahren auf meinem Exim-basierenden Mailserver nachgebildet (die dazu notwendige Option kann man als local_part_suffix in der Dokumentation nachschlagen und auf allen relevanten Routern setzen) und verwende sie zum Management eingehender Mails. Dabei ist mein System so eingestellt, dass im Standardfail Mail an mh+suffixx@zugschlus.de im Order suffixx landet, wenn es diesen Ordner schon gibt. Das ist der Normalfall, beispielsweise für Mailinglisten. Gibt es den Ordner suffixx nicht, greift ein schärferer Spamfilter und die Mail landet, wenn sie den Filter passiert, auf der obersten Ebene der Mailbox.

Natürlich gibt es auch Möglichkeiten, mit Hilfe der leistungsfähigen Exim-Filter-Sprache Sonderbehandlungen einzelner Suffixe zu definieren. So kann ich zum Beispiel die Mailadresse mh+xzy@zugschlus.de, die ich nur gegenüber Firma xzy genannt habe und die von xzy in einen Spamverteiler gekippt oder gar offensichtlich weiterverkauft wurde, gezielt durch Konfiguration auf User-Ebene so abschalten, dass der Absender der Mail eine individuelle Fehlermeldung des Stils “go take a hike, spammer” erhält.

Das ganze funktioniert so gut, dass ich keine ungeplusste Mailadresse mehr verwende und für die ungeplusste Version meiner Mailadresse ein noch schärferer Spamfilter greift. Wenn ich nicht speziell eingreife, verwendet mein Mailclient eine Absenderadresse des Stils mh+0608mail@zugschlus.de, wobei die Zahlenfolge eigenlich Kalenderwoche und Jahr darstellen soll. Die Inkrementierung dieser Nummer habe ich aber noch nicht implementiert, so dass ich sie derzeit nur ändere wenn ich bemerke dass die Adresse irgendwo rausgeleaked ist. Wenn ich daran denke, setze ich die Absenderadresse aber auf eine empfängerindividuelle Adresse, so dass Erika Mustermann eigentlich nur Mail von mh+erikamustermann@zugschlus.de erhalten sollte.

Jedes Ding hat zwei Seiten, natürlich. So ist es leider so, dass die Entwickler vieler Webapplikationen ihr Handwerk _soooo_ schlecht verstehen, dass sie sich zwar anmaßen, Programmcode zur “Verifikation” von Mailadressen abzusondern, aber nicht hinreichend mit dem E-Mail-Standard (also mithin der technischen Grundlage ihrer Arbeit) vertraut sind dass sie nicht wissen, dass ein Pluszeichen im Localpart einer Mailadresse zwar nicht alltäglich, aber dennoch erlaubt ist. Der RFC für E-Mail erlaubt nämlich verdammt viele Sonderzeichen in Mailadressen, was in vielen Punkten ziemlich unangenehm sein kann. Die im Domainpart möglichen Zeichen sind durch den DNS eingeschränkt, der einen deutlich eingeschränkteren Zeichensatz erlaubt. So kommt es leider sehr häufig vor, dass die Webseite von Firma XZY meine Mailadresse mh+xzy@zugschlus.de als “ungültig” ablehnt. Manche Webapplikationen werden an solcher Stelle sogar richtiggehend psychotisch und versagen auf subtile und nicht immer bemerkbare Art und Weise. Das ist wenig schön, und ich sollte mir endlich mal einen Standardtext schreiben, den man an solche Firmen schicken kann.

Aber da - ich erwähnte es schon - jedes Ding zwei Seiten hat, hat auch dieser Nachteil eine positive Seite: Viele Spammer wissen auch nicht, dass das Pluszeichen in einer Mailadresse erlaubt ist und kratzen die Mailadressen falsch von den zahllosen Webseiten, auf denen meine Adressen veröffentlicht sind. Da wird aus mh+debian-packages@zugschlus.de in neun von zehn Fällen debian-packages@zugschlus.de, was eine zwar gültige, aber nicht existierende Mailadresse darstellt: 550 no such user und weg ist der Spam, ganz ohne Filter. Derzeit lehnt mein MX etwa um eine bis zwei Größenordnungen mehr Spam ab, weil er an kaputt“reparierte” Mailadressen gerichtet ist als der Spamfilter aufgrund inhaltlicher Kriterien frisst.

Geplusste Mailadressen sind ein prima Mechanismus um zu kontrollieren, wer mit wem Mailadressen austauscht und um “herausgesickerte” Mailadressen unterschiedlich zu behandeln, unterschiedliche Spamfilter zu verwenden oder um im allgemeinen der Mailflut in der Mailbox Herr zu werden. Und nebenbei sind sie noch eine prima Maßnahme, um die Anzahl von Spams in der Mailbox zu reduzieren und wenigstens etwas das Gefühl zu haben, dass eher die Absender als die Empfänger an ihrem Spam ersticken.