Ich verwende E-Mail-Adressen, die man vielleicht nicht jeden Tag sieht - Adressen nach dem Muster "<username>+<extension>@domain.example", also zum Beispiel "foobar+newsletter.anbieter@domain.example".
Solche Adressen sind vollkommen legitim, wurden in keinem Request for Comments (RFC) verboten und in den relevanten aktuellen explizit erlaubt. Das sie in Formularen von beispielsweise Versicherungen oft nicht akzeptiert werden, mag noch verkraftbar sein; insbesondere da Versicherungen oft genug immer noch nicht in der Welt des Internet angekommen sind. Wenn aber Dienstleister, die massiv auf das Internet setzen oder gar Dienstleister im E-Mail-Bereich solche Adressen nicht als Empfänger-Adressen akzeptieren oder gar in einer Fehlermeldung behaupten, dass sie keine zulässigen E-Mail-Adressen wären, dann ist das kläglich;
natürlich auch, weil es für den Verwender ärgerlich ist, seine Adresse nicht verwenden zu können, aber viel mehr, weil man bei der Implementierung entsprechender Prüfroutinen die relevanten RFCs, die Internet-Standards, ignoriert b.z.w. die Prüfroutinen in unnötiger Unkenntnis derselben implementiert hat.
Richtig ärgerlich wird es da, wo eine E-Mail-Adresse gleichzeitig der Login-Name für den entsprechenden Dienst ist und man abseits des Passworts eine wie oben geartete Adresse als Dienst-spezifischen Login-Namen verwenden möchte.
Ein RFC, dessen Nummer ich im Moment nicht ermitteln kann, empfiehlt, so präzise wie nötig bei dem zu sein, was man sendet und so tolerant wie möglich, bei dem, was man an empfangenen Protokoll-Informationen akzeptiert.
Dazu kommt ein weit verbreitetes Missverständnis: Entgegen der landläufigen Ansicht hat der "local-part" einer E-Mail-Adresse - der Teil vor dem Klammeraffen ("@") - keinerlei allgemein gültige Bedeutung; genauer: Er erhält einzig und alleine durch die Interpretation, die Verarbeitung durch den empfangenden Mail Tranfer Agent (MTA) und/oder den gegebenenfalls in den Maildrop einsortierenden Mail Delivery Agent (MDA) seine Bedeutung.
Das meint, dass Mails an die Adressen "Max.Mustermann@domain.example", an "max.mustermann@domain.example" und an "MaX.mUsTeRmAnN@domain.example" auf einem System alle im selben Maildrop landen mögen, auf einem anderen die ersten beiden im selben Maildrop landen mögen aber die dritte als nicht zustellbar abgelehnt wird und auf einem dritten System alle drei nur angenommen werden, wenn für die jeweilige Schreibweise ein Maildrop/User oder zumindest explizit ein entsprechender Mail-Alias definiert sind.
Wozu braucht man solche Adressen, respektive, wozu kann man sie verwenden? Auf meinem System werden alle Mails an "foobar+<irgendwas>@domain.example" in den Maildrop für "foobar" sortiert. Erweiterungen (s.o. "<extension>") führen gegebenenfalls zu spezieller Verarbeitung bis hin zum Weiterleiten auf meinen Smartphone-Account oder automatischen (Re-) Aktionen. Eine Mail an "foobar+newsletter.anbieter@domain.example" wird beispielsweise entweder in den Folder für Newsletter des entsprechenden Anbieters sortiert oder in den allgemein für Newsletter - wenn keine spezielle Behandlung für die Erweiterung "newsletter.anbieter" aber eine für "newsletter" definiert ist. Ein angenehmer Nebeneffekt ist, dass ich für den Fall, dass "foobar+newsletter.anbieter@domain.example" bespamt wird, weiß, beim wem die Adresse gegebenenfalls abgegriffen wurde und den Anbieter verständigen kann.
Um Missverständnissen vorzubeugen: Für solche Adressen müssen nicht jedesmal E-Mail-Adressen in der MTA-Konfiguration definiert werden, es müssen keine Alias-ähnlichen Namen eingetragen werden. Wie oben geschrieben, kommt einfach alles an "foobar+<irgendwas>@domain.example" bei "foobar" an. "Definieren" kann ich eine "extension" einfach dadurch, dass ich eine entsprechende E-Mail-Adresse im "From"-Header oder als Antwort-Adresse im "Reply-To"-Header eintrage.
tl; dr: E-Mail-Adressen der Art "<username>+<extension>@domain.example" sind RFC-konform. Dennoch werden sie oftmals in Formularen als vermeintlich unzulässige E-Mail-Adressen abgelehnt, was spätestens dann nervig wird, wenn E-Mail-Adressen als Login-Namen für Dienste verwendet werden und man - zum Beispiel aus Sicherheitsgründen abseits des Password - einen Dienst-spezifischen Login-Namen verwenden möchte.
PS: Ein Beispiel für E-Mail-Adressen als Login-Namen, bei denen "+"-Adressen nicht akzeptiert werden, ist die Shop-Software von "SIQUANDO" (Stand 06.2016).
Keine Kommentare:
Kommentar veröffentlichen