Lassen Sie bei einer B2B-Registrierung Rollenadressen zu, sofern Ihr Produkt nicht für jeden Nutzer eine persönliche E-Mail-Adresse verlangt. Eine Adresse wie support@example.com kann genau der Kontakt sein, den ein Kunde verwenden möchte. Hängen Anmeldung oder Kontowiederherstellung vom Zugriff auf dieses Postfach ab, verlangen Sie eine Bestätigung, bevor Sie diese Funktionen freigeben.
Wenn Sie für die Anmeldung eine persönliche Adresse verlangen, erklären Sie diese Anforderung. Bieten Sie ein separates Feld für gemeinsame Rechnungs- oder Servicekontakte an. Eine technisch nutzbare Adresse sollte wegen einer Kontoregel nicht als ungültig bezeichnet werden.
Was der Rollenname aussagt
Eine Rollenadresse ist nach einer Aufgabe wie Support oder Vertrieb benannt. Abschnitt 3 von RFC 2142 beschreibt geschäftliche Postfachnamen wie INFO, SALES und SUPPORT. Der Name belegt nicht, dass eine Organisation dieses Postfach eingerichtet hat.
Die Organisation kann Nachrichten an eine Person, ein gemeinsames Postfach oder ein Ticketsystem weiterleiten. Aus der Einordnung der Adresse geht nicht hervor, welcher Fall vorliegt. Der Glossareintrag zum Rollenpostfach erklärt den Begriff und die Grenzen des Merkmals.
Emvero gleicht den Teil vor @ mit seiner Liste von Rollennamen ab. Bei einer Übereinstimmung setzt der Dienst checks.role_account auf true und ergänzt den Reason Code ROLE_ACCOUNT. Nur für diesen Vergleich ignoriert Emvero die Groß- und Kleinschreibung und entfernt einen Plus-Zusatz: support+trial@example.com kann zum Grundnamen support passen. Die eingegebene Empfängeradresse bleibt unverändert. Verwenden Sie für die Bestätigung und spätere Nachrichten die ursprüngliche Adresse. Der Leitfaden zu Plus-Adressen erklärt, warum das Entfernen des Zusatzes das Ziel verändern kann.
Ein gesetztes Rollenmerkmal sagt nicht, wie viele Menschen das Postfach lesen. Fehlt das Merkmal, kann das Postfach trotzdem gemeinsam genutzt werden. Aus dem Merkmal oder seinem Fehlen lassen sich weder die Identität einer Person noch ihre Einwilligung in eine Kampagne noch ein Missbrauch des Testzugangs ableiten.
Die Regel nach dem Zweck des Feldes wählen
Ein E-Mail-Feld kann eine Adresse für die Anmeldung, den Rechnungsversand oder den Kontakt zum Support erfassen. Entscheiden Sie nach diesem Zweck, welche Adressen Sie zulassen. Die folgenden Regeln sind Empfehlungen für Ihre Anwendung; Emvero wendet sie nicht automatisch an.
| Zweck der Adresse | Empfohlene Regel für eine Rollenadresse | Was noch zu prüfen ist |
|---|---|---|
| Kontakt für Rechnungen oder Servicemitteilungen | Die vom Kunden für diese Aufgabe gewählte Adresse zulassen. | Ob der Kunde diesen Kontakt gewählt hat und die Adresse technisch nutzbar ist. Den Postfachzugriff bestätigen, wenn der Ablauf davon abhängt. |
| Anmeldung bei einem Konto, für das ein gemeinsames Postfach zulässig ist | Registrierung zulassen. Eine Bestätigung verlangen, bevor Anmeldung oder Kontowiederherstellung per E-Mail freigegeben werden. | Ob jemand die Nachricht empfangen und die Bestätigung abschließen kann. |
| Anmeldung bei einem Konto für eine bestimmte Person | Um eine persönliche geschäftliche Adresse bitten und die Anforderung erklären. Den gemeinsamen Kontakt separat speichern. | Identität und Berechtigung mit den dafür vorgesehenen Verfahren Ihrer Anwendung prüfen. Der Adressname belegt beides nicht. |
| Testzugang, bei dem Sie wiederholte Registrierungen erkennen möchten | Nicht allein wegen eines Funktionsnamens ablehnen. | Kontoverlauf und andere relevante Missbrauchshinweise. Eine Rollenadresse beweist keinen Missbrauch; eine andere Adresse beweist keine neue Person. |
Ein Kunde möchte beispielsweise alex@example.com für die Anmeldung und billing@example.com für Rechnungen verwenden. Speichern Sie zu jedem Kontakt, wofür er verwendet wird. Eine Einschränkung für das Anmeldefeld sollte den Rechnungskontakt nicht aus dem Kundendatensatz entfernen.
Auch wenn Sie eine persönliche Adresse verlangen, bleiben Ihre Prüfungen von Identität und Berechtigung notwendig. Eine Adresse, die wie ein Personenname aussieht, liefert keinen stärkeren Identitätsbeleg als support@.
ROLE_ACCOUNT im Zusammenhang mit dem Prüfergebnis lesen
Nach den aktuellen Regeln von Emvero verändert das Rollenmerkmal allein weder status noch action. Das folgende Beispiel zeigt ein abgeschlossenes Ergebnis mit Rollenmerkmal. Es wurde zur Veranschaulichung erstellt und enthält nur einen Teil der Felder; es ist keine Antwort auf eine echte Anfrage:
{
"status": "deliverable",
"action": "allow",
"checks": {
"smtp": "accepted",
"role_account": true
},
"reason_codes": ["SMTP_RCPT_ACCEPTED", "ROLE_ACCOUNT"]
}
allow bedeutet, dass die Prüfung keinen technischen Grund ergeben hat, die Adresse abzulehnen. Ihre Anwendung kann nach ihren Zugangsregeln weiterhin eine Bestätigung oder eine persönliche Adresse verlangen. Speichern Sie das zurückgegebene Ergebnis und die Entscheidung Ihrer Anwendung getrennt. Ändern Sie deliverable nicht in undeliverable, um eine Einschränkung durch Ihre Kontoregeln darzustellen.
Andere Befunde können das Gesamtergebnis ändern. Auch bei einer Rollenadresse kann die Postfachprüfung ohne eindeutiges Ergebnis bleiben oder die Domain Catch-all-Verhalten zeigen. Lesen Sie status, action, checks und reason_codes zusammen. Der Leitfaden zum Prüfergebnis erklärt die Zusammenhänge. Insbesondere steht risky nicht für eine einzige festgelegte Aktion.
Bestätigung und Zulässigkeit getrennt behandeln
Eine abgeschlossene Bestätigung zeigt, dass jemand zu diesem Zeitpunkt Zugriff auf die Nachricht hatte und den Bestätigungsschritt in Ihrer Anwendung ausgeführt hat. Sie belegt weder alleinigen Postfachzugriff noch die Identität einer bestimmten Person im Unternehmen. Bei der Adressprüfung versendet Emvero keine Bestätigungsmail. Ihre Anwendung muss die Nachricht separat senden und prüfen, ob die Bestätigung abgeschlossen wurde. Der Vergleich von Verifizierung und Bestätigung erläutert, was die beiden Schritte jeweils feststellen.
Speichern Sie auf Ihrem Server getrennt, was die Prüfung ergeben hat, ob Sie die Adresse zulassen und ob sie bestätigt wurde. Die Bestätigung muss sich auf genau die Adresse beziehen, an die Sie die Nachricht gesendet haben. Ändert jemand die Adresse, muss auch die neue Adresse bestätigt werden.
Gibt eine abgeschlossene Prüfung unknown zurück, reichen die Belege nicht für eine eindeutige Aussage über die Adresse. Wenn Sie den Postfachzugriff feststellen müssen, lassen Sie die Registrierung fortsetzen. Verlangen Sie aber eine Bestätigung, bevor Sie einen Zugang per E-Mail freigeben. allow_with_email_confirmation empfiehlt diesen Ablauf; die Bestätigung führt weiterhin Ihre Anwendung durch. Das unklare Ergebnis bedeutet nicht, dass die Adresse ungültig ist.
pending bedeutet, dass die Prüfung noch läuft. Fragen Sie das Ergebnis nach dem in der API-Antwort angegebenen Intervall erneut ab. Legen Sie fest, wie lange Ihre Anwendung wartet und wie sie fortfährt, wenn bis dahin kein Ergebnis vorliegt. Ein HTTP-Fehler weist auf ein Problem mit der Anfrage oder dem Dienst hin. Weder ein Fehler noch pending belegt, dass die Adresse undeliverable ist. Der Leitfaden zur Prüfung im Registrierungsformular beschreibt den Serverablauf und die Möglichkeiten nach Ablauf der Wartezeit.
Eine Einschränkung verständlich erklären
Wenn Ihre Regel für persönliche Adressen die Registrierung verhindert, erläutern Sie die Anforderung im Formular. Zum Beispiel:
Für die Anmeldung bei diesem Konto benötigen Sie Ihre persönliche geschäftliche E-Mail-Adresse. Eine gemeinsame Rechnungs- oder Supportadresse können Sie nach der Registrierung ergänzen.
Verwenden Sie diesen Hinweis nur, wenn das Produkt ein separates Kontaktfeld tatsächlich anbietet. Andernfalls nennen Sie den verfügbaren Weg zur Korrektur. Lassen Sie den eingegebenen Wert stehen, damit er bearbeitet werden kann.
Vermeiden Sie „Diese E-Mail-Adresse ist ungültig“, wenn nur Ihre Regel für Rollenadressen greift. Wer dieses Postfach täglich nutzt, erhält sonst eine falsche Erklärung. Prüfen Sie die Zulässigkeit auf dem Server zusätzlich zu möglichen Hinweisen im Browser. API-Zugangsdaten bleiben auf dem Server.
Die Regel vor dem Aktivieren prüfen
Testen Sie die Entscheidungen Ihrer Anwendung mit erfundenen Adressen und vorgegebenen Prüfergebnissen. Die Tabelle setzt voraus, dass Ihre Anwendung das genannte Ergebnis erhalten hat. Dafür müssen Sie keine realen Postfächer prüfen.
| Fall | Erwartetes Verhalten Ihrer Anwendung |
|---|---|
Rollenmerkmal mit deliverable und allow; gemeinsame Kontakte sind erlaubt |
Registrierung fortsetzen. Postfachbestätigung verlangen, wenn der Zugang davon abhängt. |
| Dasselbe Ergebnis; zur Anmeldung ist aber eine persönliche Adresse nötig | Kontoregel erklären und um eine andere Anmeldeadresse bitten. Die ursprüngliche Adresse nur auf Wunsch des Kunden als separaten Kontakt behalten. |
Rollenmerkmal mit unknown |
Das unklare Ergebnis speichern. Eine Bestätigung verlangen, wenn der Postfachzugriff festgestellt werden muss. |
Noch laufende Prüfung mit pending |
Die Prüfung weiterhin als unvollständig führen. Das Ergebnis innerhalb der Wartefrist erneut abfragen; danach nach der festgelegten Regel fortfahren. |
| Kein Rollenmerkmal | Übliche Zugangs- und Bestätigungsregeln anwenden; keine Identität daraus ableiten. |
Beobachten Sie nach dem Aktivieren, an welcher Stelle Nutzer die Registrierung abbrechen oder ihre Adresse korrigieren. Prüfen Sie, ob sie die Bestätigung abschließen und ihre gewählten Rechnungskontakte weiterhin verwenden können. Entscheiden Sie anhand dieser Beobachtungen, ob die Einschränkung hilft, die ursprüngliche Zugangsanforderung zu erfüllen.
Sobald die Regel feststeht, prüfen Sie die eingegebenen Adressen mit der E-Mail-Verifizierungs-API auf Ihrem Server. Wenden Sie Ihre Kontoregeln an und bestätigen Sie den Postfachzugriff in separaten Schritten.