Zugschlus' DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Die Hall of Shame von Webanwendungen, die RFC-konforme Mailadressen nicht akzeptieren ======

===== Vorgeschichte =====

Mindestens seit den frühen 1990er Jahren schon unterstützt sendmail Mailadressen im Format %%name+suffix@domain.example%%, wobei der Abschnitt "+suffix" der Mailadresse bei der Zustellung ignoriert wird. Eine Mail an diese Adresse wird also bei name@domain.example zugestellt, wobei der String "+suffix" dem Endbenutzer zur Filterung zur Verfügung steht.

Diese Methode des Mailmanagements ist in den letzten zehn Jahren weitgehend in Vergessenheit geraten. So weit in Vergessenheit, dass die jungen Wilden, die mit ihrer Kreativität hinter vielen heutigen Webanwendungen stecken, sie nicht mehr kennen. Und da Manuals lesen bei Snowboardern ja auch völlig out ist und man es nicht mehr nötig hat, die [[ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt|technischen Grundlagen]][[ftp://ftp.rfc-editor.org/in-notes/rfc822.txt|des eigenen Kerngeschäfts]] zu kennen, werden Pluszeichen in Mailadressen sehr gerne und sehr häufig einer kontraproduktiven Sonderbehandlung unterzogen.

Dabei sind geplusste Mailadressen zum Beispiel bei der Spambekämpfung sehr praktisch, weil die allermeisten Spammer die Mailadresse am Pluszeichen abschneiden und ihren Spam dann an die nicht existierende Adresse "suffix@domain.example" abzukippen versuchen.

Weniger praktisch ist das, wenn eine Webanwendung einfach nur mit einer korrekten Mailadresse funktionieren soll. Dass diese Selbstverständlichkeit auch bei einer geplussten Mailadresse zutrifft, erlebt man erschreckend selten. Auch die von mir inzwischen verwendete Fallback-Notation %%name---suffix@domain.example%% fällt immer öfter durch die Schranken einer zu strengen Eingabevalidierung.

Auf dieser Wikiseite führe ich eine Hall of Shame derjenigen, die Mailadressen verarbeiten, ohne zu wissen, wie eine Mailadresse aussehen darf und sich deswegen eigene Regeln ausgedacht haben.

===== Die Liste =====

==== Nur "+" nicht akzeptiert, ordentliche Fehlermeldung ====

  * [[http://freemail.web.de/|web.de Freemail]], siehe [[http://blog.zugschlus.de/archives/175-Achtfacher-Testsieger.html|meinen Blogartikel aus dem August 2005 zu diesem Thema.]] Die Webanwendung ist bis heute nicht gefixt. (Stand: 2006-05-29)
  * Bei [[http://www.netclusive.de|netclusive]] kann man mit einer geplussten Mailadresse nichts bestellen. "Ungültige Email-Adresse!" (sic!) lautet die Fehlermeldung. (Stand: 2006-08-19)
  * [[http://www.euserv.de/|EUserv]] mag im Kontaktformular für Kundenanfragen keine Pluszeichen. Und antwortet dann nicht.
  * Wer bei [[http://www.volkswagen.de/|Volkswagen]] ein Auto kaufen will, darf auch keine Pluszeichen in der Mailadresse haben. Sonst gibt es keine Probefahrt.
  * Auch bei [[http://www.douglas.de/|Douglas]] kann man keine Pluszeichen in der Mailadresse haben. (Stand: 2006/10)
  * [[http://www.pixdiscount.de/|Pixdiscount]] mag keine Pluszeichen. (Stand: 2006/11)
  * [[http://www.snapfish.de/|Snapfish.]] (Stand: 2006/11)
  * Als [[http://www.vcd.org/|VCD-]]Mitglied kann man sich für die Onlinedienste nicht anmelden, wenn man eine Geplusste Mailadresse verwendet. Auf entsprechende Hinweise zieht man sich darauf zurück, dass das ein "Feature" von Typo3 sei.

==== "+" und "---" nicht akzeptiert, aber Fehlermeldung ====

  * [[http://www.strato.de/|STRATO]] akzeptiert im Webfrontend für die Bestellung eines Dedicated Servers weder geplusste Mailadressen noch die von mir inzwischen eingeführte Alternative mit %%a---b@c.example%%. (Stand: 2006-09-26)
  * [[http://www.walbusch.de/|Walbusch]] akzeptiert für Kundenadressen weder geplusste Mailadressen noch %%a---b@c.example%%. (Stand: 2006-09-26)


==== Nur "+" nicht akzeptiert, stillschweigende "Verböserung" der Adresse ====

  * Bei [[http://www.star-hosting.de/|Star Hosting]] konnte ich mich mangels eines deutschen Personalausweises gar nicht erst online als Kunde anmelden. Bei der vermutlich manuellen Erfassung des schriftlich übermittelten Auftrags wurde dann das Pluszeichen stillschweigend aus der Adresse entfernt. Die Zugangsdaten für den neuen vserver gingen somit an eine falsche Mailadresse, der dabei entstehende Bounce wird ignoriert. Natürlich ist das System soweit korrekt, dass trotzdem eine Lastschrift erzeugt wird. Der Support sagt dazu nur lapidar "Pluszeichen sind in unserem System nicht zulässig." Daraus entstand eine zugegebenermaßen ganz lustige Diskussion, die darin mündete, dass mir der Techniker den Link zu RFC2822 vor die Füße geworfen hat mit der Frage, wo dort stünde, dass Pluszeichen zulässig sind. Nachdem ich ihm das durch Zitat der entsprechenden Abschnitte belegt habe, meldete er sich nicht mehr. (Stand: 2006-08-19)