Ja. Eine E-Mail-Adresse mit einem Apostroph kann gültig sein, wenn das Zeichen vor dem @ steht. Bei o'neil@example.com ist der Name vor dem @ der lokale Teil. Der gerade ASCII-Apostroph gehört zu den Zeichen, die RFC 5322 dort erlaubt.
Lehnt ein Formular diese Adresse ab, prüfen Sie, an welcher Stelle die Validierung oder Speicherung scheitert. Wenn Sie das Zeichen löschen, verändern Sie die Adresse. Eine zulässige Schreibweise belegt weder, dass ein Anbieter dieses Postfach bereitstellt, noch dass es Nachrichten empfangen kann.
Zeichen und Position prüfen
Der gerade Apostroph ' hat den Codepunkt U+0027, das gekrümmte Zeichen ’ den Codepunkt U+2019. Im Eingabefeld können sie ähnlich aussehen, sind aber unterschiedliche Zeichen. Das zweite gehört nicht zum ASCII-Zeichensatz der gewöhnlichen Grammatik für den lokalen Teil.
| Beispiel | Bedeutung |
|---|---|
o'neil@example.com |
Der gerade Apostroph ist in diesem lokalen Teil zulässig |
o’neil@example.com |
Ein anderes Unicode-Zeichen wurde eingegeben; die Unterstützung internationalisierter Adressen ist gesondert zu prüfen |
o'neil@exam'ple.com |
Die Domain enthält ein Zeichen, das in gewöhnlichen Mail-Domainnamen nicht erlaubt ist |
o'neil..sales@example.com |
Aufeinanderfolgende Punkte machen diesen lokalen Teil ohne Anführungszeichen ungültig |
Die SMTP-Adressgrammatik definiert die Regeln für Domains und durch Punkte getrennte Abschnitte des lokalen Teils. Die Beispiele verwenden eine reservierte Dokumentationsdomain und stellen keine erreichbaren Postfächer dar.
Enthält das Feld ein gekrümmtes Zeichen, bitten Sie die Person, die beabsichtigte Schreibweise zu bestätigen. Ersetzen Sie das Zeichen nicht stillschweigend und entfernen Sie keine Satzzeichen. Weitere Formatregeln finden Sie in der Referenz zur E-Mail-Syntax.
Den Schritt finden, der die Adresse ablehnt
Beginnen Sie beim Browserfeld. Ein HTML-Feld mit <input type="email"> lässt den geraden Apostroph im lokalen Teil zu. Ein eigenes pattern, eine JavaScript-Prüfung oder eine Formularbibliothek kann strengere Regeln ergänzen. Die HTML-Spezifikation für E-Mail-Felder definiert eine Browsergrammatik, die von der SMTP-Syntax abweicht.
Führen Sie diesen Code in der Browserkonsole aus, um nur die eingebaute Formatprüfung zu testen. Er erstellt ein Eingabefeld außerhalb des Dokuments und sendet keine Anfrage:
const field = document.createElement("input");
field.type = "email";
field.required = true;
console.table([
"o'neil@example.com",
"o’neil@example.com",
"o'neil@exam'ple.com",
"o'neil..sales@example.com"
].map(value => {
field.value = value;
return { value, formatAccepted: field.checkValidity() };
}));
Die Ergebnisse lauten der Reihe nach true, false, false, true. Das letzte zeigt, warum die Unterscheidung wichtig ist: Der Browser akzeptiert aufeinanderfolgende Punkte vor dem @, die SMTP-Grammatik für einen lokalen Teil ohne Anführungszeichen hingegen nicht. Die Feldprüfung ersetzt keine Serverprüfung.
Besteht das erste Beispiel diesen Test, scheitert aber in Ihrem Formular, untersuchen Sie dessen zusätzliche Prüfregeln. Akzeptiert das Formular die Adresse, vergleichen Sie den übermittelten Wert mit dem Wert, den der Server erhält. Prüfen Sie anschließend den Server-Parser und seine Fehlermeldung. Das JavaScript-Formularbeispiel zeigt, wie Sie Rückmeldungen geben und die Eingabe unabhängig auf dem Server prüfen.
Die Adresse beim Speichern und Wiederverwenden erhalten
Nach erfolgreicher Formatprüfung auf dem Server prüfen Sie, ob Schreiben und Lesen den lokalen Teil unverändert lassen. o'neil@example.com und oneil@example.com sind unterschiedliche eingegebene Adressen. Ihre Anwendung kann das Löschen des Zeichens nicht als Korrektur begründen.
Übergeben Sie die Adresse bei SQL-Abfragen als gebundenen Parameter an den Datenbanktreiber. Setzen Sie sie nicht durch Zeichenkettenverkettung in die Abfrage ein. OWASP empfiehlt parametrisierte Abfragen, um Eingabedaten von SQL-Code zu trennen. Das Entfernen von Apostrophen ersetzt diese Trennung nicht.
Testen Sie alle Stellen, die den gespeicherten Kontaktwert lesen. Die Registrierung kann gelingen, während Anmeldung, Profiländerung, Export oder Passwortzurücksetzung andere Prüfregeln anwenden. Halten Sie für einen reproduzierbaren Fehlerbericht die synthetische Eingabe, den fehlerhaften Schritt, die Meldung und den Wert nach dem Speichern und erneuten Laden fest. Verwenden Sie dafür keine echten Kundenadressen.
Kann ein angebundener Dienst die Adresse nicht verarbeiten, erklären Sie die Einschränkung und lassen Sie die Person eine Alternative angeben. Erzeugen Sie diese nicht selbst, indem Sie den Postfachnamen umschreiben.
Die unverändert übernommene Adresse verifizieren
Senden Sie die unverändert übernommene Adresse von Ihrem Server an die E-Mail-Verifizierungs-API. So sammeln Sie Belege zur Domain und, sofern verfügbar, zum Empfänger. Die API-Zugangsdaten bleiben auf dem Server. Emvero lässt den lokalen Teil einschließlich seiner Satzzeichen unverändert.
Das Ergebnis unknown bedeutet, dass die vorhandenen Belege keine eindeutige Antwort erlauben. Bei pending läuft die Prüfung noch. Keines der beiden Ergebnisse belegt einen dauerhaften Grund, die Adresse abzulehnen. Müssen Sie feststellen, ob die Person Zugriff auf das Postfach hat, verlangen Sie die Bestätigung über einen Link oder Code. Der Vergleich von Verifizierung und E-Mail-Bestätigung erklärt, warum auch ein zulässiges Zeichen und ein akzeptierter Empfänger diese Frage offenlassen.