Was ist eine Mailadresse, und was nicht?
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
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"" / "{" /
"|" / "}" /
"~"
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.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Bernd 'Aard' Wachter on :
Es gibt genug Webseiten die keine vierstelligen TLDs zulassen; prominentes Beispiel war Nokia die das nach einem Hinweis vor einiger Zeit behoben haben.
Felix on :
1) Ein zu einem bestimmten Zeitpunkt punktuell nicht verfügbarer Mailserver ist kein verlässliches Indiz, daß die Domäne grundsätzlich keine Mails annimmt. 2) Grundsätzlich zu Deinem Thema hast Du sicher schon http://www.remote.org/jochen/mail/info/ angeschaut? Da steht auch was zu Spaces in Localparts. 3) Leider unterscheiden die wenigsten Mailer Groß-/Kleinschreibung, auch das ein RFC-Verstoß (und bei zustellenden Systemen tatsächlich ärgerlich, weil man so u. U. Mail bekommt, die eigentlich an jemand anders adressiert ist). 5) Zum Thema WEB.DE bin ich nach wie vor der Ansicht, daß nirgends verlangt wird, daß jedes an E-Mail-Kommunikation teilnehmende System die Adressierung beliebiger Absender oder Ziele zulassen muß (zugegebenermaßen ist die Reaktion des Webfrontends irreführend. Da sollte so in der Art stehen "folgende Zeichen bitte nicht verwenden:...").
Marc 'Zugschlus' Haber on :
Mit 1, 2 und 3 hast Du recht. 4 fehlt, und zu 5 sind wir unterschiedlicher Meinung.
Vielleicht probiert man mal aus, wieviele Kunden noch übrig bleiben, wenn man statt mit "xfacher Testsieger" mal mit dem genauso zutreffenden "über unsere Systeme könnt Ihr nur die Leute erreichen, deren Mailadressen uns diese Woche genehm sind" Reklame macht.
Der Ärger bleibt bei den Empfängern, weil das, was web.de macht, muss ja richtig sein: Schließlich ist man ja xfacher Testsieger.
Martin on :
Das gemeine bei web.de ist ja, dass man bei dem Webfrontend dann nicht jeden erreichen kann.
Das web.de bei der Anmeldung eine beliebig definierte Teilmenge zulässt ist legitim. Aber bei der Zieladresse Einschränkungen zu machen ist nicht ok. Insbesondere, wenn es eine Syntax betrifft, die tatsächlich häufiger genutzt wird.
Jens Kutilek on :
Besonders interessant bei Web.de ist, daß sie andererseits ungültige Adressen zulassen. Ein Bekannter hatte dort eine Adresse nach dem Muster .xyz@... Das ist aber schon einige Zeit her, ich weiß nicht, ob Web.de das immernoch zuläßt.
Ulli on :
Es gibt doch einen Grund, eine Adresse wie name+suffix@domain.example abzulehnen - example ist keine gültige TLD, jedenfalls nicht laut http://data.iana.org/TLD/tlds-alpha-by-domain.txt
Ungültige Zeichen kommentarlos ändern in was anderes ist natürlich auch ein Knaller. Wer sich das hat einfallen lassen, gehört $fieseMaßnahme
Marc 'Zugschlus' Haber on :
Ich habe die Mailadressen natürlich hier mit .example anonymisiert. Im realen Mailverkehr benutze ich selbstverständlich gültige und funktionierende Adressen.
Ulli on :
Schon klar soweit - .example ist halt leider nicht gültig, und die Aussage damit (genau genommen) falsch. Für solche Zwecke wäre, dachte ich, example.org da. Kann mich an dunkle Vorzeit erinnern, etwas dementsprechendes gelesen zu haben. Oder wurde es mir gar eingetrichtert? Keine Ahnung, ist mir aber mittlerweile in Fleisch und Blut übergegangen.
Also, um beim Beispiel zu bleiben: name+suffix@example.org
Marc 'Zugschlus' Haber on :
Ist nicht example.org semantisch genauso wie .example?
Ulli on :
Ja. Und gültig