Mehrere E-Mail-Adressen in einem Formularfeld: Was Ihre Web-App eindeutig festlegen sollte

Soll ein Formular genau eine Kontaktadresse oder mehrere Empfänger aufnehmen? Entscheiden Sie das ausdrücklich, bevor ein gewöhnliches E-Mail-Feld zur freien Empfängerliste wird. Für mehrere Adressen brauchen Sie ein verständliches Eingabeformat, eine Prüfung jeder Adresse und Regeln dafür, was mit der gesamten Liste geschieht. Ein vom Browser akzeptierter Eintrag beweist weder die Existenz der Postfächer noch eine Berechtigung zum Versand.

Hier geht es um die Erfassung einer begrenzten Empfängerliste in einer Geschäfts-App. Ein möglicher, erfundener Anwendungsfall ist die Auswahl zusätzlicher Empfänger für einen ausdrücklich angeforderten Projektbericht. Newsletter-Anmeldung, Kontoinhaberschaft und rechtliche Versandvoraussetzungen sind andere Fragen.

Ein Feld mit mehreren Adressen braucht einen anderen Vertrag

Die MDN-Dokumentation zu input type="email" unterscheidet eine einzelne syntaktisch passende Adresse von einer Liste. Mit dem Attribut multiple kann der Wert mehrere durch Kommas getrennte E-Mail-Adressen enthalten. Führende und nachgestellte Leerzeichen werden dabei von den einzelnen Adressen entfernt.

Daraus folgt für die Beschriftung: „E-Mail-Adresse“ ist zu ungenau, wenn Ihre Anwendung tatsächlich mehrere Empfänger erwartet. Benennen Sie den Zweck, etwa „Zusätzliche Berichtsempfänger“, und erklären Sie das Trennzeichen in einem sichtbaren Hinweis.

Übernehmen Sie nicht ungeprüft die Konventionen eines anderen Programms. Eine durch Semikolons getrennte Liste oder eingefügte Kombinationen aus Anzeigenamen und Adressen sind nicht dasselbe wie die von MDN beschriebene kommagetrennte Adressliste. Wenn Ihre App solche Eingaben zusätzlich unterstützt, gehört deren Umwandlung ausdrücklich zum Entwicklungsumfang.

Prüfen Sie die Liste, nicht nur ihren Anfang

Ein Feld darf nicht allein deshalb als brauchbar gelten, weil die erste Adresse ordentlich aussieht. Legen Sie fest, dass jeder beabsichtigte Empfänger einzeln erkannt und geprüft wird. Zeigen Sie bei einem Fehler, welcher Eintrag korrigiert werden muss, ohne die übrigen Eingaben zu verlieren.

Vereinbaren Sie auch eine Höchstzahl von Empfängern und ob mindestens einer erforderlich ist. Diese Geschäftsregeln müssen im tatsächlichen Ablauf geprüft werden. Verlassen Sie sich nicht auf eine beschriftete Pflichtfeld-Markierung oder das Vorhandensein einzelner HTML-Attribute als Nachweis, dass Ihre gewünschte Mindestzahl durchgesetzt wird.

Falls nur bestimmte Empfängergruppen zulässig sind, braucht es dafür eine fachliche Regel. Ein formal passender Domainname ist nicht gleichbedeutend mit der Berechtigung, einen bestimmten Projektbericht zu erhalten. Prüfen Sie die Zugriffsentscheidung unabhängig von der Schreibweise der Adresse.

Browserprüfung und Serverprüfung gehören zusammen

MDN warnt ausdrücklich davor, die HTML-Formularprüfung als Ersatz für eine serverseitige Prüfung zu verwenden. Browserseitige Regeln lassen sich umgehen; Daten können auch direkt an den Server geschickt werden.

Für den Auftrag heißt das: Das Backend muss die tatsächliche Empfängerliste nach den vereinbarten Regeln prüfen. Ein deaktivierter Senden-Knopf im Browser ist keine ausreichende Absicherung. Bitten Sie um eine Demonstration, dass eine ungültige oder zu große Liste auch bei einer direkten Anfrage nicht als gültige Versandaufgabe übernommen wird.

Definieren Sie zudem, ob ein Fehler die gesamte Übernahme verhindert oder ob einzelne gültige Einträge separat gespeichert werden dürfen. Für eine kleine Empfängerliste ist eine gemeinsame Korrektur vor dem Bestätigen oft leichter verständlich. Das ist eine Gestaltungsempfehlung, keine von der HTML-Dokumentation vorgegebene Verarbeitungspolitik.

Formatgültig heißt nicht zustellbar

Die Dokumentation weist darauf hin, dass eine korrekt formatierte Adresse nicht notwendigerweise existiert. Trennen Sie deshalb mindestens die Aussagen „Adresse übernommen“ und „Nachricht zugestellt“.

Wenn ein späterer Versand scheitert, darf die App daraus nicht rückwirkend schließen, dass die Eingabe syntaktisch falsch war. Und wenn eine Nachricht angenommen oder zugestellt wird, ist damit nicht bewiesen, wer das Postfach kontrolliert oder ob die Person Zugriff auf den Inhalt haben soll.

Eine Änderung dieser Liste darf außerdem nicht nebenbei die Login-Adresse eines Kontos überschreiben. Rechnungsempfänger, Berichtsempfänger und Kontoinhaber können verschiedene Rollen haben. Falls Ihre App dieselbe Adresse für mehrere Zwecke verwendet, muss das eine bewusste, sichtbare Entscheidung sein.

Vor dem Absenden die tatsächlichen Empfänger zeigen

Als praktische Anforderung empfiehlt sich eine prüfbare Darstellung der erkannten Einträge vor einer sensiblen Aktion. Der Nutzer sollte sehen können, ob aus einer eingefügten Zeichenfolge wirklich die gewünschten Empfänger geworden sind.

Legen Sie fest, was bei doppelten Adressen geschieht. Entfernt die Anwendung sie, sollte die angezeigte bestätigte Liste das Ergebnis wiedergeben. Lassen Sie keine unbemerkten Änderungen am eigentlichen Adresstext zu, nur um eine vermeintlich ähnliche Adresse herzustellen.

Das Speichern einer Liste ist noch kein Auftrag, sofort Nachrichten zu senden. Benennen Sie die bestätigte Aktion präzise. Diese Anleitung fordert keine Testsendungen an echte Kunden und behauptet keinen bereits erprobten Versandablauf.

Eine kleine, aussagekräftige Abnahme

Prüfen Sie mit kontrollierten Testdaten zunächst eine einzelne Adresse und danach mehrere kommagetrennte Einträge. Ergänzen Sie Leerzeichen an den Grenzen und einen absichtlich fehlerhaften zweiten Eintrag. Stimmen Erkennung, sichtbare Liste und Fehlermeldung überein?

Prüfen Sie anschließend eine leere Liste, Ihre festgelegte Mindest- und Höchstzahl, einen doppelten Eintrag und eine direkte Anfrage ohne die Browserprüfung. Testen Sie auch das Einfügen eines Formats, das Sie ausdrücklich nicht unterstützen. Die App soll die notwendige Korrektur erklären, statt Empfänger stillschweigend wegzulassen.

Muss ich mehrere Adressen in einem einzigen Feld erlauben?

Nein. Eine Oberfläche mit einzeln hinzufügbaren Empfängern kann verständlicher sein. Entscheidend ist, dass Darstellung, gespeicherte Liste und serverseitige Regeln zusammenpassen. Das HTML-Attribut allein trifft diese Produktentscheidung nicht.

Kann ich eine Liste aus einem Mailprogramm einfach einfügen?

Nur wenn das vereinbarte Eingabeformat dazu passt oder eine bewusst entwickelte Umwandlung vorhanden ist. Beauftragen und testen Sie die tatsächlich benötigten Formate, statt jede Zwischenablage als reine Adressliste zu behandeln.

Bestätigt die Browserprüfung die Empfängeridentität?

Nein. Sie prüft die beschriebene Syntax, nicht die Identität einer Person oder die zulässige Verwendung eines Postfachs. Diese Anforderungen benötigen eigene Abläufe.

Halten Sie die Fälle in den Akzeptanzkriterien für Ihre Web-App fest. Über den passenden Funktionsumfang können Sie bei der Business-App-Entwicklung sprechen.

Quelle und Abgrenzung

MDN: input type=email, insbesondere die Abschnitte „Value“, „multiple“ und „Validation“. Belegt sind Syntax, kommagetrennte Mehrfacheingabe und die Grenzen der Browserprüfung. Empfängergrenzen, Berechtigungen, Bestätigung und Fehlerbehandlung sind hier vorgeschlagene Projektanforderungen, keine Behauptung über eine bereits implementierte App.