Ja. Eine E-Mail-Adresse mit einem Pluszeichen im Lokalteil kann gültig sein. Weisen Sie sie nicht wegen des Zeichens + zurück und entfernen Sie den Zusatz nicht. Prüfen Sie die vollständige Adresse: Eine korrekte Syntax belegt noch nicht, dass der empfangende Server sie annimmt.
Für Formulare und API-Anbindungen gilt: Behalten Sie die Adresse bei, die eingegeben wurde. Wenn Sie Alex+orders@example.com in Alex@example.com ändern, prüfen Sie einen anderen Empfänger und speichern eine andere Kontaktadresse.
Was das Pluszeichen bedeutet
Bei der Plus-Adressierung steht ein Zusatz, auch Tag genannt, vor dem @. In Alex+orders@example.com ist Alex+orders der Lokalteil und example.com die Domain. Ein Mailsystem, das diese Funktion unterstützt, kann die Adresse an dasselbe Postfach wie Alex@example.com weiterleiten.
Wie das funktioniert, hängt vom empfangenden System ab. Nach RFC 5233 ist die Kodierung solcher Unteradressen vom jeweiligen System abhängig. Aus einem sichtbaren + kann Ihre Anwendung nicht ableiten, wie eine beliebige Domain die Adresse auswertet.
In Exchange Online ist die Plus-Adressierung standardmäßig aktiviert. Organisationen können sie jedoch deaktivieren. Prüfen Sie bei Bedarf die Konfiguration des empfangenden Anbieters. Weitere Angaben finden Sie in der Microsoft-Dokumentation zur Plus-Adressierung.
Alle Beispieladressen sind synthetisch und verwenden reservierte Beispieldomains. Sie zeigen die Verarbeitung, keine tatsächlich verfügbaren Postfächer.
Das Zeichen zulassen und die gesamte Adresse prüfen
Die Grammatik für einen Lokalteil ohne Anführungszeichen erlaubt +. Alle weiteren Syntaxregeln gelten weiterhin. Das Zeichen allein macht eine Zeichenkette noch nicht zu einer gültigen Adresse. RFC 5322, Abschnitt 3.2.3.
Der aktuelle Parser von Emvero akzeptiert beispielsweise die Struktur von Alex+orders@example.com, weist aber Alex..orders@example.com zurück. Bei der zweiten Adresse sind die aufeinanderfolgenden Punkte der Fehler. Die weiteren Grenzen erläutern die Regeln zur E-Mail-Syntax.
Wenn Ihr Formular die erste Adresse ablehnt, prüfen Sie sowohl die Validierung im Frontend als auch den Parser im Backend. Eine Liste erlaubter Zeichen, die im Lokalteil nur Buchstaben, Ziffern, Punkte, Unterstriche und Bindestriche enthält, schließt + schon vor der Verifizierung aus.
Trennen Sie die Formatprüfung von den später erhobenen Belegen. Der Vergleich von Syntaxprüfung und SMTP-Verifizierung zeigt, was die beiden Verfahren jeweils feststellen können.
Die Domain normalisieren und den Lokalteil erhalten
Das Zielsystem legt die Bedeutung des Lokalteils fest. SMTP-Clients müssen dessen Groß- und Kleinschreibung erhalten; bei Domainnamen ist sie ohne Bedeutung. RFC 5321, Abschnitte 2.3.11 und 2.4.
Behalten Sie in einer allgemeinen Anbindung die Schreibweise, die Punkte und den Pluszusatz des Lokalteils bei. Übertragen Sie die Aliasregeln eines Anbieters nicht auf alle Adressen.
Der aktuelle Parser von Emvero erlaubt die übliche Syntax mit Pluszusatz. Er erhält den Lokalteil und normalisiert die Domain. Für diese synthetische Eingabe ist folgende Verarbeitung zu erwarten:
| Eingabe oder Bestandteil | Wert |
|---|---|
| Eingegebene Adresse | Alex+orders@EXAMPLE.COM |
| Erhaltener Lokalteil | Alex+orders |
| Normalisierte Domain | example.com |
| Adresse für die Prüfung | Alex+orders@example.com |
Eine Prüfung ohne den Zusatz würde eine andere Frage beantworten. Selbst wenn beide Adressen dasselbe Postfach erreichen, gingen die gewählte Kontaktadresse und der Tag in Ihrer Anwendung verloren.
Prüfen, ob aus + ein Leerzeichen wurde
Beim Parsen von application/x-www-form-urlencoded wird ein direkt enthaltenes + zu einem Leerzeichen. Eine korrekte Serialisierung kodiert das Pluszeichen als %2B. WHATWG URL Standard.
Verwenden Sie einen Serializer, statt die Abfragezeichenkette selbst zusammenzusetzen:
const email = "Alex+orders@example.com";
const body = new URLSearchParams({ email });
console.log(body.toString());
console.log(new URLSearchParams(body.toString()).get("email"));
Die Ausgabe lautet:
email=Alex%2Borders%40example.com
Alex+orders@example.com
Vergleichen Sie den Feldwert mit dem Wert, den Ihr Backend empfängt. Kommt dort Alex orders@example.com an, prüfen Sie zuerst die Kodierung. Korrigieren Sie den Serializer: Nach dem Dekodieren jedes Leerzeichen durch + zu ersetzen, würde fehlerhafte Eingaben verdecken.
Senden Sie für eine Emvero-Anfrage JSON aus Ihrem Backend an POST /v1/verifications. Lassen Sie die vollständige Adresse im Anfrageinhalt stehen:
{
"email": "Alex+orders@EXAMPLE.COM"
}
Bewahren Sie API-Zugangsdaten auf dem Server auf.
Die Plus-Adresse prüfen und den Postfachzugriff bestätigen
Ein Pluszeichen allein belegt weder ein vorhandenes Postfach noch einen Wegwerfanbieter oder ein doppeltes Konto. Prüfen Sie die vollständige eingegebene Adresse und lesen Sie action und reason_codes aus der Antwort. Je nach Belegen kann die Empfehlung allow, allow_with_email_confirmation oder reject lauten.
Bei unknown reichen die vorhandenen Belege nicht aus, um die Adresse abschließend zu beurteilen. Bei pending ist die Prüfung noch nicht fertig. Keiner dieser Zustände rechtfertigt eine dauerhafte Ablehnung allein wegen eines Pluszeichens.
Wenn der Kontozugang vom Zugriff auf das Postfach abhängt, senden Sie eine eigene Bestätigungsnachricht an die vollständige Adresse. Die Verifizierung durch Emvero sendet diese Nachricht nicht und belegt nicht, wer das Postfach kontrolliert. Der Leitfaden zur Prüfung im Anmeldeformular ordnet Verifizierung und Bestätigung in den gesamten Ablauf ein.
Warum Sie diese Ergebnisse getrennt speichern sollten, zeigt der Vergleich von Adressprüfung und E-Mail-Bestätigung.
Regeln für doppelte Konten getrennt behandeln
Das Entfernen eines Tags eignet sich nicht als allgemeine Identitätsregel. Sie könnten Adressen zusammenführen, die das empfangende System unterschiedlich behandelt. Aliase allein zeigen außerdem nicht, ob zwei Anmeldungen von derselben Person stammen.
Falls Ihr Produkt bestätigte Adressen nach einer Regel für einen bekannten Anbieter gruppieren muss, speichern Sie diese Zuordnung getrennt von der Adresse für Kontakt, Bestätigung und Kontowiederherstellung. Überschreiben Sie die Kontaktadresse nicht und führen Sie Konten nicht automatisch zusammen. Der Leitfaden zum Missbrauch von Testzugängen erklärt, was E-Mail-Belege zu dieser Entscheidung beitragen können.
Ergänzen Sie vor einer Änderung der Validierung Regressionstests für den vollständigen Weg durch Ihre Anwendung:
Alex+orders@example.comdurchläuft Prüfung, Übertragung und Speicherung mit unverändertem Lokalteil.- Bei
Alex+orders@EXAMPLE.COMlässt sich die Domain normalisieren, ohneAlex+orderszu ändern. Alex..orders@example.comwird wegen fehlerhafter Syntax weiterhin zurückgewiesen.- Eine Formularkodierung mit anschließendem Dekodieren erhält
+. Ein nur für Vergleiche entfernter Tag führt nicht dazu, dass Konten zusammengeführt werden.
Binden Sie die API zur E-Mail-Verifizierung ein, um die Adresse zu prüfen, nachdem sie unverändert im Backend angekommen ist.