Zugschlusbeobachtungen (Entries tagged as mail)

Scan eingehender Mail auf Malware

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 07 Nov 2008 18:30:43 +0100

Dadurch, dass mein Mailsystem in seiner Eigenschaft als Nichtwindows nicht besonders anfällig gegen Malware ist und ich auch nicht blind auf jeden Anhang klicke, leiste ich mir seit einigen Jahren den Luxus, dass der Clamav auf meinem Mailserver nur die Malware ablehnt, die ich explizit konfiguriert habe. So werde ich die lästigsten Störer automatisch los und habe trotzdem einen Überblick darüber, was im Moment so an Malware unterwegs ist, weil der Clamav natürlich auch Malware, die nicht auf der Reject-Liste steht, markiert.

Es gab zwischendrin eine Zeit, da kam ungefähr gar nichts. So wenig jedenfalls, dass ich ernsthaft darüber nachgedacht habe, die CPU-Zyklen für den Scan eingehender Mail auf Malware einzusparen und den Mailvirenscanner abzuschalten.

Gut, dass ich das nicht gemacht habe, denn in den letzten zwei bis drei Wochen kommt durchaus wieder Malware per Mail in signifikanter Menge (also mehr als zwanzig pro Tag). So hat der Clamav wieder ein wenig mehr zu tun, und ich werde in Zukunft nicht mehr so schnell darüber nachdenken, einen nicht störenden Sicherheitsmechanismus wegen “irrelevant, braucht man heutzutage nicht mehr” abzuschalten.

Was ist denn das für eine komische Mailadresse?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 12 Jun 2008 07:51:21 +0200

Diese Frage hat man mir alleine gestern dreimal gestellt. Grund genug, endlich mal einen Standardtext für die Erklärung zu verfassen.

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.

Geplusste und gedreifachtminuste Mailadressen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 23 Apr 2008 21:28:51 +0200

Wie schon vor fast einem Jahr geschrieben, verwende ich normalerweise konsequent geplusste Mailadressen, um die Möglichkeit zu haben, der Wanderung meiner Mailadressen durch die verschiedenen Datenbanken nachvollziehen zu können. Dies birgt einige Fallstricke, die sich hauptsächlich daraus ergeben, dass sich manche Webentwickler ihre Arbeit verhältnismäßig einfach machen und diese weitgehend unbeeinflusst von den technischen Standards verrichten.

Heute ist mir aber ein Punkt über den Weg gelaufen, bei dem Pluszeichen im Localpart einer Mailadresse wirklich nicht erlaubt sind: Das zweite Feld im SOA-Record einer DNS-Zone soll laut RFC1035 einen Domainnamen enthalten, der die Mailbox der für die Zone verantwortlichen Person spezifiziert. Und im Wort “Domainnamen” steht der Schlüssel: Denn ein Domainname darf weder Klammeraffe noch Plus enthalten: Es sind nur Punkte, Buchstaben, Ziffern und Bindstriche erlaubt (und die nichtmal in beliebiger Reihenfolge). Das ist auch der Grund dafür, warum man den Klammeraffen im SOA-Record durch einen Punkt ersetzen und alle davor vorkommenden Punkte Backslash-Escapen muss.

Damit ich nicht jede SOA-Mailadresse einzeln manuell anlegen muss, nimmt mein Mailserver seit heute nicht nur mh+blog-zugschlus-de@zugschlus.de, sondern auch mh---blog-zugschlus-de@zugschlus.de an. Das sind zwei getrennte Suffixe, die in Filtern unterschiedlich behandelt werden können. In Exim ist das einfach zu konfigurieren: Man schreibt einfach local_part_suffix = “+* : ---*” in die Konfiguration, wo zuvor nur “+*” stand.

Damit dürfte ich mich in Zukunft auch etwas weniger über hirntote Webprogrammierer ärgern müssen, weil der Weg zur nicht mehr geplussten Mailadresse jetzt nicht mehr so weit ist.

Schöne kleine Mailbox

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 24 Mar 2008 11:30:23 +0100

Meine INBOX ist groß. So groß, dass sie eigentlich nur noch mit einer schnellen, textbasierten, direkt auf dem Filesystem operierenden Software verwendbar ist: Mit mutt. Und sie hat in den letzten Wochen die 150.000-Mails-Grenze überschritten, das ist zu viel.

Das Script, das die Mailinglistenmails und die automatischen Mails der verschiedenen Systeme nachträglich aus der Mailbox in verschiedene Untermailboxen verteilt, hat eine Linderung auf knapp 60.000 Mails gebracht. Das ist immer noch zu viel, so dass ich eine Radikalkur verordnete: Alle Mails von 2006 und früher werden in eine Ablagemailbox verschoben.

Jetzt sind es noch knapp 20.000 Mails in der Inbox ab Januar 2007. Das sind knapp über 40 Mails pro Tag und gar nicht mehr so viel wie es auf den ersten Blick erscheint - denn da sind auch noch alle Mails dabei, die hier rausgegangen sind.

Wer in Beantwortung einer Mail von vor 2007 noch auf eine Reaktion von mir wartet: Bitte nicht den Atem anhalten, da wird wohl nix mehr kommen. Sorry.

mein.name@zugangsprovider.example

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 07 Nov 2007 12:00:10 +0100

Bei vielen Firmen, besonders im Handwerk, findet man die Kombination aus “Web: http://www.firmenname.example/”, aber eine Mailadresse @t-online.de oder unterhalb der Domain eines anderen Internet-Zugangs-Providers (ob das nun AOL, Freenet, T-Online, Arcor, Alice, Debitel oder noch andere sind).

Oft frage ich mich, wie sowas entsteht. Wissen diese Leute (oder ihre Berater) es einfach nicht besser, wird da fleissig vom ISP gesponsort oder ziert man sich nur, die Mailadresse zu ändern? Ich meine, dank Forwards und Mail-Pickup-Diensten ist eine über mehrere Jahre hergezogene Migration von einer Mailadresse auf eine andere doch prima möglich.

Ich meine, gerade der Mailservice bei T-Online hat doch eigentlich nur Nachteile: Man kann sie ohne Zusatzkosten in Form eines komischen E-Mail-Pakets nur über den T-Online-Zugang abfragen (was zum Beispiel die mobile Nutzung drastisch erschwert), und man ist langfristig an den Anbieter gebunden, weil mit Kündigung des Zugangsvertrags nicht nur dieser, sondern auch gleich die Mailadresse mit weg ist. Und da es bei T-Online keinen kostenlosen Account mehr gibt, fängt man sich auf diese Weise auch noch Grundgebühren beim Wechsel ein.

Liebe Kleinunternehmer: Wenn Ihr eine eigene Domain habt, habt ihr mit sehr großer Wahrscheinlichkeit auch bereits Mailadressen unterhalb dieser Domain, von Eurem Webspaceanbieter. Es spricht gar nichts dagegen, diese Mailadressen auch zu nutzen. Das gibt Euch Flexibilität im Einkauf, und weniger unprofessionell sieht es ganz nebenbei auch noch aus.

Aktives Vorgehen gegen geplusste Mailadressen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 06 Jun 2007 16:11:20 +0200

Wie viele meiner Leser wissen, benutze ich konsequent geplusste Mailadressen und falle damit regelmäßig auf die Nase, weil so genannte “Webentwickler” die technischen Grundlagen ihres Kerngeschäfts bestenfalls mal gestreift, nie aber in der Tiefe gelesen haben. So sind viele Webanwendungen der Meinung, dass das Pluszeichen in Mailadressen nicht auftauchen darf.

“So ein Unsinn!” denke ich dann oft und schreibe, wenn ich zu viel Zeit habe, eine nette Mail und weise darauf hin, dass zum Beispiel mh+vxrn@zugschlus.de eine gültige und funktionierende Mailadresse ist, die ich gerne für die Kommunikaton mit dem Unternehmen vxrn verwenden möchte.

Manchmal antworten die Firmen sogar, weisen mich auf RFC822 oder wahlweise RFC2822 hin und behaupten, dass dort drin stünde, dass keine Pluszeichen in Localparts vorkommen dürfen. Auf meine Antwort, die den betreffenden RFC dahingehend interpretiert, dass das eben doch erlaubt ist, kommt dann typischerweise nichts mehr.

Aber das, was mir mit VXRN passiert ist, ist dann doch einen Blogeintrag wert.

Die Webseite von VXRN ist derzeit grundsätzlich brauchbar. Sogar uggc://jjj.vxrn.qr/vine funktioniert. Aber natürlich wird bei der Anmeldung und auch beim Stellen von Anfragen eine geplusste Mailadresse nicht angenommen. Ich werfe also meinen Textbaustein und bitte um Behebung des Fehlers in der Webanwendung.

Zurück kommt ein Beispiel für ein “korrekt ausgefülltes Registrierungsformular” als PDF. “Bitte beachten Sie, dass der Benutzername auf jeden Fall einen Punkt und ein @-Zeichen enthalten muss.” Auf meine eigentliche Anfrage wird - Textbausteine eben - mit keinem Wort eingegangen. Immerhin erhalte ich das Angebot, meine Bestellung per E-Mail einzureichen. Nur, dass ich gar nichts bestellen wollte.

Nun geht es aber los. Man habe festgestellt, dass ich eine E-Mailadresse (sic!) angegeben habe, die den Bestandteil “VXRN” enthält. Durch die umfangreiche Medienpräsenz sei mir bewusst, dass die Marke und der Firmenname ein besonders wichtiger Bestandteil des Unternehmens sei. Man weist nach einem weiteren Absatz über Markenschutz etc darauf hin, dass die Verwendung dieser Mailadresse unter Umständen einen Verstoß gegen die Markenrechte darstellen könnte. Am liebsten wäre es, wenn ich meine normale E-Mailadresse (sic!) verwenden würde. Denn auf deren Datenschutzversprechen könnte ich mich immer verlassen.

Also irgendwie frag ich mich: Hallo, geht’s noch???

Ich hätte letzte Woche ein Merkbefreiungsformular an der Warenausgabe abgeben sollen. Der Firnmenname VXRN ist auf Wunsch des betroffenen Unternehmens anonymisiert.

Spass mit geplussten Mailadressen. Die nächste Stufe.

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 25 Apr 2007 00:36:38 +0200

Mailadressen mit Plus im Local Part sind ein immer währender Quell der Freude. Sie helfen dem lokalen Mailserver bei der Sortierung eingehender Mail, und sind ein ausgezeichneter Spamfilter - Spammer wissen nicht wirklich, dass Pluszeichen in Local Parts von Mailadressen erlaubt sind, und schneiden die von der Webseite gefischte Mailadresse per Skript kaputt.

Dass auch die meisten Entwickler von dynamischen Webseiten nicht wissen, dass Pluszeichen in Local Parts von Mailadressen erlaubt sind, ist bedauerlicher Nebeneffekt. So kann man sich bei gut der Hälfte aller Webapplikationen mit einer solchen Mailadresse nicht anmelden.

Die neueste Masche der Snowboarder ist allerdings noch etwas perverser: Man akzeptiert die Mailadresse für die Anmeldung. Dann setzt man den Kunden ungefragt auf einen Newsletterverteiler (was man ja, da Kunde, ungestraft tun darf). Und dann lässt man die Abmeldung vom Newsletter nur dann durchgehen, wenn die Mailadresse kein Plus enthält. Wunderbar.

Diesen Scherz haben sich alleine in den letzten sieben Tagen sowohl Tchibo als auch Netgear erlaubt. Wie schön, dass ich geplusste Mailadressen dafür einsetze, dass ich Mailadressen nur einmal verwende. Somit haben sich jetzt sowohl Tchibo als auch Netgear ein 550 mit passendem Kommentar im Ablehnungstext eingehandelt. Schade, dass das niemals jemand lesen wird. Denn Bounces auswerten tut ja auch kein professioneller Newsletterversender.

Was ist eine Mailadresse, und was nicht?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 02 Oct 2006 14:43:00 +0200

Viele Webapplikationen haben recht eigenwillige Vorstellungen davon, wie eine Mailadresse aussehen darf. Wenn man als Kunde nun etwas ausgefallenere Features des Mediums E-Mail verwendet, fällt man oftmals in die Falle, dass eine Webapplikation eine völlig korrekte Mailadresse nicht akzeptieren mag.

Eine Anwendung, die mit potenziell misstrauenswürdigen externen Stellen (so zum Beispiel mit Anwendern) kommuniziert, ist gut beraten, die von draußen hineinkommenden Daten auf Plausibilität zu prüfen. Ohne korrekt ausgeführtes Input Sanitizing ist man anfällig gegen Codeeinschleusung und andere böse Dinge.

Weniger schön ist es allerdings, wenn der Code zum Input Sanitizing über sein Ziel hinausschießt, und gültige Eingaben deswegen abgelehnt werden. Besonders häufig erlebe ich dies in Eingabefeldern, die eine Mailadresse aufnehmen sollen.

Leider ist es außerordentlich schwer, in einem Programm festzustellen, ob eine Mailadresse gültig ist oder nicht. Hier zur Auffrischung des sicher vorhandenen Grundlagenwissens die aus RFC2822 entnommene Definition der Syntax einer Mailadresse:

addr-spec       =       local-part “@” domain
local-part      =       dot-atom / quoted-string / obs-local-part
domain          =       dot-atom / domain-literal / obs-domain
dot-atom        =       [CFWS] dot-atom-text [CFWS]
dot-atom-text   =       1*atext *(“.” 1*atext)
atext           =       ALPHA / DIGIT / ; Any character except controls,
                        “!” / “#” /     ;  SP, and specials.
                        “$” / “%” /     ;  Used for atoms
                        “&” / “’” /
                        “*” / “+” /
                        “-” / “/” /
                        “=” / “?” /
                        “^” / “_” /
                        “” / “{” /
                        “|” / “}” /
                        “~”

Das ganze ist stark gekürzt aus den Abschnitten 3.4.1 und 3.2.4 übernommen.

Besonders interessant ist die Definition von “atext”, steht da doch drin, welche Zeichen in Mailadressen gültig sind. Das sind deutlich mehr, als man üblicherweise in Eingabedaten einer Webanwendung haben möchte.

So kommt es dazu, dass viele Webanwendungen zwar Mailadressen nach dem 0815-Muster vorname.nachname@domain.example akzeptieren, aber schon bei so “ungewöhnlichen” Dingen wie mh+blog-zugschlus-de@zugschlus.de oder mh---komischefirma@zugschlus.de die rote Karte “Bitte geben Sie eine gültige Mailadresse ein” zeigen.

Wie oben schön erwähnt: Dollarzeichen, Anführungszeichen jeder Art, Ausrufungszeichen, Sterne, Tilden, Doppelkreuz und Schrägstrich will man eigentlich nicht in einer Webanwendung von außen annehmen, denn man kann streng genommen nie wissen, wie schlecht die Scripts, die außerhalb der eigenen Anwendung zum Einsatz kommen, gemacht sind. Sprich: Selbst wenn man selbst alle Eventualitäten abdeckt, weiß man nie, ob man nicht weiter “hinten” im System trotzdem Ärger zulässt.

Aber: Pluszeichen werden in Mailadressen seit 20 Jahren als Zustellhinweis verwendet. Bei einer Mailadresse im Format name+suffix@domain.example wird die Mail zugestellt, als wäre sie an name@domain.example adressiert. Der Teil zwischen dem Pluszeichen und dem Klammeraffen steht aber lokalen Filtern zur Verfügung. Ich verwende dies, um eingehende Mail gleich vorzusortieren. Andere Leute nutzen diese Eigenschaft als Spamfilter, denn viele Spammer schneiden die Adresse am Pluszeichen ab und versuchen, ihren Spam an suffix@domain.example abzusenden. Existiert diese Mailadresse nicht, misslingt dies.

Leider nehmen viele Webanwendungen keine geplussten Mailadressen an, weil sie das Pluszeichen für ungültig halten. Noch schlimmer ist es, wenn das vermeintlich ungültige Zeichen stillschweigend in ein anderes Zeichen - zum Beispiel ein zu einer wirklich ungültigen Mailadresse führendes Leerzeichen - umgesetzt wird.

Da solche Webanwendungen eine erschreckend hohe Verbreitung haben, habe ich mein Mailsystem so umgebaut, dass ich die Zeichenkette “---” wie ein Pluszeichen verwenden kann. So wird bei mir name---suffix@domain.example genauso wie name+suffix@domain.example behandelt. Ich bin sehr erstaunt darüber, dass es auch Webanwendungen gibt, die “---” in Mailadressen nicht sehen wollen. Dafür gibt es nun wirklich überhaupt keine technische Grundlage mehr.

So, nun zur eigentlichen Frage: Wie unterscheidet man eine gültige Mailadresse von einer ungültigen. Leider ist dieses Problem schon in der ersten Stufe, der syntaktischen Prüfung, kaum lösbar. Will man wirklich eine syntaktische Prüfung machen, kann man sich im Perl Cookbook angucken, wie Tom Christiansen sich - erfolglos - daran versucht. Die einzige IMO gangbare Möglichkeit ist zu prüfen, ob ein Klammeraffe existiert und ob vor und hinter dem Klammeraffen nur “gültige” Zeichen auftauchen. Von sauberer Programmierung entbindet das freilich nicht, denn man muss auch “böse” Zeichen wie die oben aufgelisteten durchlassen.

Das wirklich interessante, die semantische Prüfung, kriegt man auch nicht ordentlich hin. Man kann zwar gucken, ob die angegebene Domain existiert und laut DNS am Mailverkehr teilnimmt. Man kann auch prüfen, ob ein Mailserver auf den angegebenen IP-Adressen läuft. Zuletzt kann man auch versuchen, eine Mail an die passende Mailadresse zu senden. Das hat allerdings den Nachteil, dass sie bei einem wirklich existierenden Empfänger auch wirklich ankommt. Das will man eventuell nicht. Außerdem gibt es Mailserver, die auch Mails für nicht existierende Adressen annehmen und dann - eine beliebige Zeitspanne später - einen Bounce ausstellen. Somit muss die Antwort auf den Wunsch, eine Mailadresse auf semantische Korrektheit zu prüfen, spontan “Vergiss es” lauten.

Die einzige wirklich sichere Verifikation einer Mailadresse ist, eine Mail hinzusenden, und den Menschen hinter der Adresse zu bitten, den Empfang der Testmail - zum Beispiel durch Klick auf einen enthaltenen Link oder Antwort auf die Testmail - zu bestätigen. Dieses als Confirmed Opt-In bekannte Verfahren ist aber für viele Anwendungen totaler Overkill.

Da ich selbst in meinem E-Mail-Verkehr massiv auf geplusste Mailadressen setze, habe ich in meinem Wiki eine Hall of Shame angelegt, in der ich die Betreiber nicht konformer Webanwendungen wohlwollend erwähne. Und ja, dort findet man durchaus auch die “großen” der Branche.

Fazit: Die Erkennung korrekter Mailadressen ist nichttrivial, aber machbar. Es gibt genau keinen Grund, gültige Mailadressen wie name+suffix@domain.example oder name---suffix@domain.example abzulehnen. Wenn man damit anfängt, kann man auch gleich Mailadressen mit mehr als drei Zeichen in der Top Level Domain oder einem Punkt im Local Part ablehnen. Ich kann - ganz persönlich - den Kollegen Webentwicklern nur zurufen: Leute, macht Eure Hausaufgaben und lernt die technischen Grundlagen Eures Kerngeschäfts.