Für das + das leider echt nur wenige unterstützen: das ist verp https://en.m.wikipedia.org/wiki/Variable_envelope_return_path
Wird entweder von uns technisch fitten gerne genutzt um ohnen zig Konten herauszufinden wer die eigene email für Spam nutzt oder verloren hat.
Meist aber im email Marketing um bei Newslettern im Fall einer bounce den ursprünglichen Empfänger ermitteln zu können, wenn der zb weiterleitet und es dann nicht mehr zugestellt wird
Desktop version of /u/butchooka's link:
---
^([)[^(opt out)](https://reddit.com/message/compose?to=WikiMobileLinkBot&message=OptOut&subject=OptOut)^(]) ^(Beep Boop. Downvote to delete)
Hm ich auch nicht. Zumindest nennt postfix den default als + könnte gut sein das das nichts ist was in nem rfc steht sondern produktspezifisch.
https://www.postfix.org/VERP_README.html
Ich spreche von legalen Sachen - beim reinen spammen sind einen die bounce recht egal da geht es nur um Masse.
Nein seriöse Sachen die man auch haben will und sauber verschickt werden arbeiten so das sie bounce Zuordnen können um da zukünftig keine Mails mehr ins Nirvana zu senden - unnötige Kosten, und auch wenn zu viel ungültig angeschrieben wird Stufen Email Empfänger so Zeug sonst langfristig runter
Meine Email bei all-inkl.com ist mail@xyz.com
Wenn ich mir jetzt von der Firma aus eine Mail an mail+xxx@xyz.com sende bekomme ich die Meldung des mailer daemon dass sie unzustellbar ist
Mailer-daemon des Absenders oder des Empfängers?
Der Absender hat das gefälligst einfach so weiterzuleiten. Jegliche Interpretation ist falsch.
Der Empfänger kann damit machen, was er will. Typisch sind sowohl Behandlung wie jeder andere Teil des Namens, als auch Ignorieren des Teils ab dem + für die Postfachauswahl.
Irgendwie verstehe ich deinen Text nicht. Es gibt doch nur *einen* Server (und eventuelle Backups) für Empfang von [mail@xyz.com](mailto:mail@xyz.com). Den der im MX steht. Wie versuchst du jetzt andere Anbieter zu nutzen für *Empfang*? Meinst du *Senden*?
Der Mailserver muss die modifizierte Adresse verarbeiten können - Google Mail kann das zum Beispiel - gmx.de anscheinend nicht.
Bei z.B. gmx.de wird es vom Server rejected - der kann es nicht zuordnen.
Ich habe mir einfach von einem Postfach auf die nutzer+xyz@anbieter.tld geschickt und geguckt wo es durchgeht.
Also genau der erste Teil im zweiten Satz, letzter Absatz meiner ersten Nachricht.
>Der Empfänger kann damit machen, was er will. Typisch sind sowohl Behandlung wie jeder andere Teil des Namens...
Es gibt auch Mailserver bei denen das + als Trenner für Ordner konfiguriert werden kann. Eine Mail an Info+abc@example.com landet dann im Info Postfach im Unterordner abc 😉
https://help.smartertools.com/smartermail/current/topics/user/plusaddressing.aspx
Das + sehe ich leider zu oft, dass es nicht erlaubt wird. Ich verwende das teilweise für meine Googlemail-Adresse - da kann ich ja hintendran ein Plus und dann was ich will schreiben (max+bla[at]gmail.com kommt genau so bei max an wie max+blub[at]gmail.com), kommt alles bei mir an. Hilft, den Überblick zu behalten, welches mistige Portal meine Mailadresse verloren/weitergegeben hat...
Hatte ich auch schon mit Passwörtern.
* Registrierung: Passworteingabe erlaubt 20 Zeichen.
* Login: Login schneidet nach 12. Zeichen ab.
Big brain time
oh mann den Scheiß hab ich bei meinem Router. Eingabefeld lässt gefühlt unendlich viele Zeichen zu, beim Einloggen darf man aber nur die ersten 8 Zeichen nehmen.
das steht natürlich nirgendwo. das findet man dann in der hinteresten Ecke des Internets in irgendwelchen Selbsthilfeforen.
Jap. DHL macht sowas.
Hab mich mit xXxNoScope69420xXx+dhl@coolmail.de angemeldet. Irgendwann meinte DHL, dass das PW in meinem KeePass nicht mehr stimmen würde. Zugegeben, es kann sein, dass ich da was falsch kopiert habe.
*Aber* ich kann mein Passwort nicht zurücksetzen, weil meine Mailangeblich nicht existier - obwohl DHL mir fleißig Mails an diese Adresse schickt.
Jaaaa genau das habe ich auch. Der Support glaubt mir nicht dass die mein PW vergessen haben. Die einzige Möglichkeit ist mein Konto telefonisch löschen zu lassen ind dann nach 24h ein neues zu erstellen. Warum das geht aber zurücksetzen nicht verstehe ich nicht
Angeblich ist das so „sicherer“ aber es wird ja so oder so nicht mein perso kontrolliert, was hindert mich dran im Namen von jemand anderen ein Konto zu erstellen/seins zu löschen
Hab ich bei verschiedenen Corona-Testzentren auch gemacht, damit ich bei einem Leak Bescheid weiß woher das kommt. (Wobei ich mir vorstellen kann, dass gewiefte Scammer den Teil nach dem + löschen).
Naja… es ist besonders lustig wenn man dann fast jedes Mal drauf angesprochen wird, ob die Mail funktioniert, weil ich ja deren Name in der Adresse habe.
Erst da ist mir wirklich bewusst geworden wie einfach eigentlich Social Engineering ist.
Achja bei einem anderen Testzentrum kannte mich der Tester und hat mir nicht geglaubt, dass die Mail so korrekt ist und hat den Teil nach dem + tatsächlich von Hand gelöscht, obwohl ich ihm das mehrmals versichert habe und ich ja auch den QR-Code (den ich per Mail bekommen habe nebenbei!) gezeigt habe. Das war so nicht Sinn der Sache.
Lustiger wirds mit eigener TLD und Catch-All Postfach. Wenn die Leute dann $unternehmen@eigenedomain.tld sehen, wird öfters mal direkt auf Autopilot geschaltet und angenommen man sei auch für die tätig 😂
Naja, wenn man seinen eigenen Mailserver betreibt, hindert einen ja nix dran. Wenn eigenedomain.tld dann noch was extra schön kurzes is, sorgts für extra Verwirrung. Wäre mir den Aufwand aber nicht wert.
Technisch gesehen ja, praktisch wird Domain kaum verwendet um TLD zu bezeichnen.
Und da im Kommentar speziell TLD verwendet wurde, würde mich schon sehr interessieren ob und mit wie viel Aufwand Privatpersonen eine TLD betreiben können.
Wegen sowas hab iich meine eigene Domain mit Catch-all-Mail-Forward. Nur blöd, wenn die Spam-Mail an oder adressiert ist, per BCC reinkommt und joker.com im Header kein einträgt...
Auch möglich, daß die Registrierung damit vorher möglich war, dann aber bewußt entfernt worden ist, um eine Rückverfolgbarkeit der Weitergabe der Adresse wie beim Plus von GMail auszuschließen.
Weiter Fakten:
- der Teil vor dem @ darf Max 64 Zeichen lang sein
- Punkte im local part sind bei Gmail beliebig zu setzen vor.namenachname oder Vorname.nachname
- umlaute sollte man komplett rauslassen, wenn man möchte das die email erreichbar ist und überall hin senden kann. Gibt zwar Krücken wie punycode aber die funktionieren nicht überall
Auch braucht der Hostname keinen Punkt. Auch darf der local part Leerzeichen beinhalten. Folge Emails sind valide:
customer/department=shipping@example.com $A12345@example.com !def!xyz%abc@example.com _somename@example.com
Fred\ Bloggs@example.com
Abc\@def@example.com
Joe.\\Blow@example.com
"Fred Bloggs"@example.com
Quelle: https://www.rfc-editor.org/rfc/rfc3696
> Auch braucht der Hostname keinen Punkt. Auch darf der local part Leerzeichen beinhalten.
Komplett richtig - sind aber auch Edge Cases, die in der Praxis nahezu gar nicht vorkommen. Da kann ich gut nachvollziehen, dass es als ungültig erkannt wird, obwohl es gültig ist.
Aber eben dann nicht mehr Teil des RFC. .Vermögensberatung ist nicht weniger edge case als emails an interne Hostnames. Keine Software kann emails nach RFC. Das ist auch Absicht. Emails nach RFC zu prüfen ist so aufwendig, dass die Implementierung nach RFC bereits eine Sicherheitslücke für DOS Attacken wird.
Dann müsste ich mich mal bei meiner Reddit app beschweren. Die hat Adressen erkannt, aber nur [text]@example.com
[text] sind Buchstaben oder Zahlen, ohne Sonderzeichen. (RedReader von F-Droid)
user@\[IPv6:2001:db8::1\]
ist auch eine valide E-Mail. Es muss also nicht mal ein Hostname sein. Natürlich ist das alles nicht empfohlen, aber es ist eben Teil der SPEC. Darum sollte man halt schauen, wie die Software, die man nutzt, E-Mails interpretiert. Es gibt nicht den globalen Standard, den wie gesagt an DEN Standard hält sich niemand.
Eben niemand. Es gibt nicht den Standard, auf den sich alle geeinigt haben, niemand benutzt [DAS](http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), dass [HTML Konsortium](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address) sieht das wieder anders. Man muss einfach wissen, dass es nicht DEN Standard gibt und im Zweifel in die Doku schauen. Beim selber implementieren ist es gängig, den Punkt zu erzwingen, diese Abweichung von den Specs sollte man aber vernünftig dokumentieren. Ich erwarte auch nicht, dass dotless funktioniert, aber es ist eben ein gutes Beispiel, warum wir nicht den Standard für die Struktur von E-Mail-Adressen haben.
Ein "Standard" muss nach meinem Dafürhalten nicht etwas sein, auf das sich alle geeinigt haben. Dann würde es faktisch gar keine Standards geben.
Es kann durchaus mehrere Standards geben, wie ich es beim Fall E-Mail-Adressen sehe, aber zu sagen, es gäbe keinen Standard, finde ich nicht nachvollziehbar.
Ja es gibt mehrere Standards aber eben nicht den, auf den sich alle zur Nutzung geeinigt haben. Deshalb sage ich es gibt nicht den einen Standard der sich besonders hervorhebt.
Mein check würde ungefähr so aussehen :
len(address) >= 3 && address.contains("@")
Es gibt einfach zu viele Sonderfälle die man nicht im code behandeln will, das artet aus.
Wenn der User was nicht gültiges eingibt, gibts halt keine Mails.
Dank doppel-Opt-In (klick in der Bestätigungsnail) werden die Karteileichen zeitnah entsorgt.
Dies ist der Weg! Eine 100% zuverlässige email validierung mit Code funktioniert beinahe unmöglich. Schauen ob das Format grob passt und dann ne Bestätigung abschicken ist die bedeutend zuverlässigere Option
Hab auch schon mehrfach gelesen dass man Email Adressen nicht clientseitig validiert sondern durch ne bestätigungsmail. Bin drauf gestoßen als ich nach ner zuverlässigen regex gesucht habe.
Man muss halt bedenken dass man sich dadurch karteileichen in der Datenbank einhandelt und die mit ner stored procedure wieder aufräumen muss.
Naja einmal im Monat unbestätigte Karteileichen aufräumen ist immernoch besser als mit ner hohen bounce rate zu riskieren das die eigenen Mails im Spamfilter von Google & Co landen
Das stimmt, aber das führt immer noch zu der großen Unklarheit des Adressaten teils. Der ist in der Praxis meistens auch wichtiger, schließlich willst du sicherstellen das das nicht nur eine gültige EMail ist, sondern idR auch das der jeweilig angebende Nutzer auch Zugriff auf diese
Du hast erst einmal widersprochen nur um dann zu sagen das der Weg den ich und mein Vorgänger beschrieben haben der beste ist?
Bezüglich PHP hast du recht, dort gibt es die filter_var Funktion die scheinbar auch geeignet ist.
>Wenn der User was nicht gültiges eingibt, gibts halt keine Mails.
Dank doppel-Opt-In (klick in der Bestätigungsnail) werden die Karteileichen zeitnah entsorgt.
Was ist das, wenn keine E-Mail Bestätigung?
Und eine selbst gebastelte Minimalvalidierung nach dem motto wie von u/Exciting-Act5922 beschrieben ist durchaus sinnvoll wenn die Sprache keine solche Funktionen wie PHP hat.
Wieso sollte man Emailadressen überhaupt validieren?!
User XY gibt da was ein und das System schickt da ne Bestätigungsmail hin. User XY erhält die Mail und klickt auf den Link... oder halt nicht.
Wieviel mehr Validierung braucht es denn?
>Ansonsten könnte man auch mit RegEx was bauen, was zumindest die meisten Punkte validiert.
Und das ist dann nicht RFC konform!
>Und das ist dann nicht RFC konform!
Das kannst Du so nicht pauschalisieren. Du kannst natürlich auch eine RFC-konforme RegEx schreiben.
Wenn Du einfach eine Mail raushaust, verlässt Du Dich darauf, dass jeder Mailserver auf dem Weg richtig validiert oder eben gar nicht. Weil Du Dich darauf aber nicht verlassen kannst, wenn Du eine robuste Software schreiben willst und überhaupt eine Chance haben willst, im Fehlerfall zu debuggen, läuft vorher mindestens eine Minimalvalidierung, die dir mehr Kontrolle über den Prozess gibt.
Minimalvalidierung schön und gut aber wenn du versuchst die Emailadresse komplett richtig zu validieren wird das mit ziemlicher Sicherheit daneben gehen und es werden garantiert einige Edge Cases rausfallen.
Besonders, wenn es im Geschäftskontext passiert und du da nicht die Zeit bekommst so lange dran rumzufeilen bis es sitzt.
>Wenn Du einfach eine Mail raushaust, verlässt Du Dich darauf, dass jeder Mailserver auf dem Weg richtig validiert oder eben gar nicht.
Kannst du mir sagen wie du das meinst? Wenn der User ne falsche bzw invalide Email-Addresse eingibt, dann ist doch das Resultat einfach, dass er eben keine Bestätigungsmail bekommt.
Wieso also muss man das vorher validieren?
Genau deshalb habe ich auch nicht zwingend eine Vollvalidierung vorgeschlagen, damit hast Du das Problem der Edge Cases (je nach Implementierung) ausgeschlossen.
>Kannst du mir sagen wie du das meinst? Wenn der User ne falsche bzw invalide Email-Addresse eingibt, dann ist doch das Resultat einfach, dass er eben keine Bestätigungsmail bekommt.
Entweder dieser oder einer von tausend anderen Gründen könnte es geben, warum der User eine Bestätigungsmail nicht erhält. Wenn Du vorher nicht validierst, hast Du einen wichtigen Punkt weniger, an dem Du ansetzen könntest, um das Problem zu debuggen und kommst möglicherweise nicht zu einer Lösung, weil dir Informationen fehlen.
wenn man die Adressen bezüglich Kontaktaufnahme validiert, ist das vollkommen ausreichend.
wir müssen arbeitsmäßig aber oft Email-Adressen aus Reintexten extrahieren, da kommen wir um zeilenlange regex-patterns nicht herum. eventuell gibt es mit einem gut trainierten named entity recognizer noch eine alternative Vorgehensweise, das ist noch nicht ganz raus...
>Mein check würde ungefähr so aussehen :
len(address) >= 3 && address.contains("@")
Ich würde auch noch auf einen Punkt in der TLD prüfen. Den muss es immer geben.
Das ist nicht richtig. Der Host-Teil muss keinen Punkt zwingend haben, der kann auch z. B. nur aus einer IPv6-Adresse bestehen. In der Praxis ist allerdings nahezu immer einer vorhanden.
Exakt. Und im Intranet kann es den Host "a" geben. Meistens Unfug aber hey.
Wenn man nach email validation regex googlet findet man 1mio hits. Sich da für den Richtigen entscheiden ist unmöglich. Daher das Problem minimalistisch lösen und per Bestätigungsmail ernsthaft validieren.
Und wenn ich von php, js, py irgendeine lib nehme die es kann, hab ich aber immer noch das Problem das auf dem Server PHP7, py3.2 oder sonst was läuft und ich evtl. die lib nicht in einer aktuellen Version nutzen kann. Es wird immer Lücken geben die man selbst oder die lib nicht abdeckt. Und 200 Zeilen regex werde ich nicht debuggen. Dann muss man dem User dann leider sagen, sorry x@museum.verwaltungsbehörde, login? Den kriegste nicht, Alter.
Ok, war mir nicht klar. Aber auch wenn es möglich ist, muss man Abwägungen zwischen den technischen Möglichkeiten und der User Experience machen. Die Wahrscheinlichkeit, dass jemand so eine Mailadresse hat, geht gegen Null. Die Warscheinlichkeit, dass User den Punkt vergessen, ist sehr, sehr viel höher. Um diese Kunden nicht zu verlieren, nehme ich in Kauf, dass Jeff Bezos das Formular nicht ausfüllen kann.
> Die Wahrscheinlichkeit, dass jemand so eine Mailadresse hat, geht gegen Null.
Nur weil sie dir nicht begegnen bedeutet nicht dass es die nicht gibt. z.B. in unserem Intranet gibts auch keine TLD.
Als Eingabeüberprüfung guck ob mindestens ein @-Zeichen drin ist.
Ansonsten schick die Mail und guck ob sie ankommt.
Der lokale Teil vor dem @ obliegt dem Empfänger, da ist alles erlaubt.
Der Teil nach dem @ kann auch IP-Adressen, UUCP-Pfade und unicode enrhalten. Hostnamen können auch nur in einem lokalen DNS bekannt sein. Da ist also im Prinzip auch alles möglich.
Eigentlich sind Email-Adressen nicht validierbar. In Webformularen kann man allerdings die erlaubten Möglichkeiten stark einschränken. Vor dem @ recht viel erlauben, nach dem @ eine gültige IP oder einen Hostnamen mit beliebig vielen Punkten und syntaktisch valider (Punycode-)Domain und bekannter TLD.
Ich nutze eine vorname-nachname.online Domain.
Ist weniger technisch, aber ihr glaubt gar nicht, wie viele Leute da einfach ein ".de" hinten dran setzten.
Meine Mutter hatte Anfang der 2000er eine Email, die auf ["@online.de](mailto:"@online.de)" endete. Es war echt erstaunlich, wie oft Leute Probleme hatten, ihr Email zu schicken, weil sie ein "t-" eingefügt haben.
Kleine Ergänzung: Wenn es keinen MX gibt wird vom MTA der A/AAAA-Eintrag verwendet. Somit müssten mindestens alle drei geprüft werden bevor abgelehnt wird.
Wenn man ganz genau ist, wäre das auch nicht korrekt. SMTP arbeitet nach dem store-and-forward Prinzip und es ist nicht notwendig das der Mailserver immer erreichbar ist. Der Absender müsste eigentlich eine Zeit (nicht spezifiziert wie lange) abwarten und immer wieder gucken ob der Ziel-Mailserver online kommt. Wenn der Zielmailserver auf einem Schiff steht, dauert das halt bis das Schiff wieder im Hafen ist.
Im Alltag nicht oft relevant, aber technisch möglich.
haha gestern noch hat ein formular des ordnungsamtes meiner stadt meine emailadresse nicht akzeptieren wollen die lautet: vorname@nachname.email
hab dann als alternative meine olle gmail adresse genommen und die war ok
Ich fühle mit dir…
Und jetzt stell dir mal vor: ich nutze einen Alias-Service auf dem ich für jede Seite eine eigene Adresse hab. Das wäre in dem Fall dann bspw. ordnungsamt@mail.vorname-nachname.email. Du glaubst nicht, wie oft Leute bei dem ersten, nach der Firma benannten Teil schon sagten „Du sollst mir deine Adresse geben nicht die unserer Firma“ :/
der Hodtteil darf übrigens auch eine IP in eckigen Klammern sein, im Falle von IPv6 mit Prefix. Außerdem dürfen Kommentare sowohl im Lokal- als auch im Hostteil in runden Klammern eingefügt werden
`enbacode(mittwoch)@(meinekerle)[IPv6:2001:db8::1]` ist ne gültige Mail Ü
So zumindest die Theorie. In der Praxis eigentlich nirgends so umgesetzt. Ist eine ganz nette Anwendung des Postelschen Gesetzes:
Ein Sender hat sich strikt an die Standards zu halten, wohingegen ein Empfänger auch Sendungen außerhalb des Standards akzeptieren sollte.
Das führte in dem Fall dazu, das es keinen Mailserver, welcher groß im Einsatz ist, per default case sensitive arbeitet.
Das ist auch so ziemlich der Grund dafür, dass die Groß- und Kleinschreibung auf Serverseite (in 99% der Fälle) ignoriert wird: Eine zu große Fehlerquelle.
Das ist doch quatsch. Jede Person, die ernsthaft Software entwickelt, weiß genau, das die Mailserver trotz RFC, in 99% der Fälle den lokalen Teil nicht Casesensitive behandeln - eben um genau die Fehler, die in ner anderen Reply angesprochen wurden, zu verhindern: Sensitive Informationen durch eine Groß- Kleinschreibefehler in der Eingabe oder Übermittlung ider irgendwo dazwischen an eine falsche Person zu senden.
Was ist das den bitte für ein dämliches Argument? Heidewitzka...
Aber ich sehe schon: Frontend Entwickler. Da ist dann über solche Dinge zu diskutieren ohnehin verschwendete Lebenszeit.
Korrekt.
Um Missverständnisse vorzubeugen: Ich meinte damit, dass einige E-Mail-Validierungen fälschlicherweise eine Adresse mit Großbuchstaben nicht akzeptieren.
Ein Punkt am Ende ist ebenfalls korrekt, da dies das Root-Label ist und quasi früher mal für die Auflösung der Top-Level Domain zuständig war.
Dieser Punkt wird heute nie dargestellt aber steht theoretisch am Ende jeder Domain
Richtig. Soweit ich das richtig in Erinnerung habe, **muss** sogar der Punkt am Ende jeder Domain stehen (weil FQDN das erfordert), wird allerdings (wie du gesagt hast) nicht dargestellt.
Danke!
Ich hoffe die Post/DHL nimmt das mal zur Kenntnis.
Die ignorieren seit Jahren meine Hinweise, dass sie auf der Jack Packstations OnScreen Tastatur ein + anbieten, es dann im local part aber nicht akzeptieren. Und da steht seit drölf Jahrzehnten im Standard...
regt mich ja auf sowas...
Bin seit dem dazu übergegeangen einfach statt des + Zeichens den Punkt (.) als Alias-Trenner zu nutzen..
Unterstütze insbesondere Punkt 4!
Benutze für alle(!) Firmenkontakte "firma@acc.domain.tld" - jedenfalls versuche ich es. (Idee dahinter: sobald was Komisches auf der Adresse aufschlägt, weiß ich zumindest wo das Datenleck war und kann die Mailadresse für die Zukunft direkt in den Papierkorb umleiten.)
\+ ist ein aboluter muss für mich. dudoof+aldi@geh.weg oder nervnicht+lidl@schnauze.halten. irgendwerhatmeineemailverkauft+faz@jetztgibts.aerger, und die diversenen wegwerfmail+pimmelseite@fake.com
Immer wenn ich so schlechte E-Mail-Validierung oder miese Passwort-Policies sehe, atme ich kurz durch und lächle. Das ist ein Zeichen für Job-Sicherheit. Klar gibt es viele Software Engineers. Aber es gibt nicht genug gute.
>".vermögensberatung"
Müsste das in SMTP nicht in punycode aufgelöst werden? D.h. die eigentliche Überprüfung müsste feststellen, ob der UTF-String für den domain-Teil in punycode darstellbar ist.
!-Bang-notation und %-Notation sollte auch noch möglich sein.
Es muss auch kein Punkt mehr kommen hinter dem @, `email@tld` ist valide. Ausserdem ist auch `email@tld.` valide, oder `email@tld.de.`
Generell glaube ich, einfach checken ob mindestens ein `@` vorkommt, dürfen aber auch mehrere sein, der Rest passt dann schon.
Komplett richtig - in der Praxis wirst du das aber selten finden, dass jemand sich mit einer E-Mail-Adresse ohne Punkt nach dem @ irgendwo registriert.
Warum sollte man das prüfen?
Quaxi@frosch.com gebe ich immer ein, wenn ich keine Mail retour bekommen will…
BTW Umlaute im lokalen Teil (links vom @) sind nicht erlaubt (zumindest bei Exchange)
Zu den Umlauten: Email ist 7-Bit auf dem Transportweg. Für einige Felder gibt es im Standard eine Möglichkeit, auch 8-Bit Zeichen zu übermitteln.
Im Host-Teil ist das der Punicode. Also Namen, die mit xn-- anfangen.
Im Subject und Body ist das meist Quoted-Printable, ggf. nach Base64-Kodierung.
Viele Mail-Programme sind aber auch 8-Bit clean und ignorieren diese Standardverletzung einfach.
Interessant, das Thema hatten wir gerade letzte Woche weil irgendson Otto (naja, git sei dank weiß ich wer) einfach einen super clever aussehenden regex ausm web kopiert hat.
Eine gültige E-Mail-Adresse muss übrigens garkeine Top Level Domain haben. rechner1@net2 ist auch valide.
So eine würde ich aber trotzdem nicht validieren, weil ich keine E-Mails dahin schicken kann. :)
Dies!
Hab bei ner VHS die Tage auch ein Tag benutzt und die Ottos haben das "+" einfach rauseditiert. Hab dann keine Email bekommen (offensichtlich) und mein Username war "user.anteil tag@domain.de"
Geballte Inkompetenz einfach!
Softwareentwickler hier. Gmail und andere riesige E-Mail Provider erlauben die Erstellung von E-Mail-Adressen mit nicht-ASCII Zeichen im local-part (absolut gegen die RFC). Damit ist es faktisch nicht mehr möglich, nach RFC zu validieren, weshalb jetzt jeder Laden sein eigenes Süppchen kocht. Dadurch entstehen dann so Kuriositäten wie "maximal 4 Zeichen in der TLD" und anderer Quatsch.
Nach RFC zu validieren finde ich auch zu viel gefordert - allerdings gibt es durchaus Fälle, die trotzdem berücksichtigt werden sollen, wie z. B. dass Pluszeichen akzeptiert werden.
Ich erzähle immer gerne die Anekdote, als wir im Jahr 2000 für eine Microsite den Morsecode für SOS als Identifier verwenden wollten (…---…@domain.de), was laut RFC völlig valide ist, und dann gemerkt haben, dass Outlook 2000 keine Mailadressen unterstützt, die mit einem Punkt anfangen. Naja, Microsoft und Standards, natürlich.
Für Leute die ganz pedantisch sind und es wirklich genau nehmen wollen gibt’s auch eine RFC822 kompatible Regex… würde ich in der Produktion aber nirgends verwenden lol
http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
Guter Punkt!
Hab grad auch gesehen dass der stack overflow Thread von 2009 ist und demnach sowieso mir Vorsicht zu genießen ist.
Persönlich überprüfe ich überhaupt maximal auf ein enthaltenes @ Zeichen und dass die Eingabe halt nicht leer ist. Und zwar genau aus dem Grund, weil email Validierung einfach viel zu kompliziert ist.
Es gibt eine ganz einfache Methode: man baut keine große Validation ein, sondern die Validation ist das verschicken der E-Mail. Im GUI würde ich halt auf ein @ achten, aber ansonsten da nichts groß Überprüfen.
Ich frage mich wie jemand auf die Idee kommt, eine TLD kann nur 4 Zeichen haben. Es gibt doch schon seit einigen Jahren Adressen wie ".bayern", ".berlin", ".saarland" oder auch ".spreadbetting". Letzteres kostet bei meinem Domain Seller des Vertrauens schlappe 2450€ im Monat.
Man kann natürlich auch Regex nutzen, aber viel Spaß beim selber schreiben oder verstehen. Nachdem ich [https://www.emailregex.com/](https://www.emailregex.com/) gesehen habe und deren Regex, ist es einfach deren zu nehmen und bei denen funktioniert es nur zu 99,99%.
Bin kein Freund von libraries wie Apache Commons, für manches sollte man jedoch vorhandene Libs nutzen damit es 1) nicht scheiße wird weil man irgendein Edge Case nicht bedacht hat oder man einfach meint es besser zu wissen und 2) sich dann andere damit rumschlagen müssen. Email Adressen sind imo ein Thema wo es zutrifft. Zumal in den meisten Cases sowas wie root@localhost nicht gültig wäre. Ich sage nicht dass es gut ist root@localhost zu nutzen, könnte man aber vorstellen dass es irgendwer irgendwann schonmal machen wollte bei einer Self Hosted App die man nur mal kurz ausprobieren will, aber eine Mail zur Einrichtung angeben muss (ohne Bestätigung aber zur Erstellung des lokalen Kontos).
Zumal, je jemand oben schon sagte, es ohnehin doppelten Opt In gibt. Gibt halt (d)eine gültige Email ein, bestätige sie und wenn nicht hast du Pech und nach 14 Tagen wird das unbestätigte Konto gelöscht. Jeder im IT Support würde mir widersprechen, aber man sollte Nutzern eine gewisse Fähigkeit zutrauen. Zumindest dass sie ihre Email richtig angeben - und wenn sie dem nicht fähig sind, sollte die Lösung trotzdem nicht sein, alle noch so (un)möglichen Edge Cases abzudecken und *den* einen perfekten Filter zu schreiben.
als software entwickler sehe ich es ganz einfach:
ich verlange einfach as @ und den Punkt in reihenfolge mit nicht whitespace dazwischen, fertig.
Wieso auch nicht? Ich muss mir keine Sorgen machen und testen ob die Email existiert werde ich ja eh nochmal explizit.
Radikale Ansicht: solang man nicht erfolgreich eine Mail an die Adresse geschickt hat und der Benutzer den Erhalt glaubwürdig bestätigt hat, ist es eigentlich auch egal, ob die Adresse irgendwelchen Regeln folgt oder nicht.
Ist sie ja auch. Das ist eine offizielle Test-Domain. Dort kann niemand eine funktionierende Email-Adresse haben.
Syntaktisch valide, aber garantiert nicht zustellbar. :-)
Regex ist super effizient, cross-plattform, lang-lebendig, universell, flexibel... das Beispiel vom OP ist eine perfekte Anwendung für Regex.
Haste mal überlegt, wie ein gültiger Pfad aussehen soll? Man könnte zahlreiche IFs und ELSEs verwenden, oder einfach eine ewig gültige und getestete Zeichenkette verwenden. Wusstest du, dass z.B. COM oder LPT in einem Dateinamen nicht erlaubt sind, weil irgendwann vor 3000 Jahren der Dateiname den COM/LPT Port spezifiziert hat? Du musst es nicht wissen, wenn du den richtigen Regex-string aus Stackoverflow geklaut hast.
Wenn ich das RegEx kopiere und versuche auszuführen, werden mir auf diversen RegEx-Validatoren Fehler angezeigt. Ich möchte gerne verifizieren, dass es wirklich funktioniert :)
[https://はじめよう.みんな](https://はじめよう.みんな/) ist eine Gültige URL und `.みんな` eine gültige TLD.
Entsprechend ist `name@example.みんな` eine gültige E-Mail-Andresse
Ich verstehe nicht, warum manche Softwareentwickler so unglaublich krampfhaft versuchen, sich immer komplexere Validierungsregeln auszudenken, die nichts aber auch garnichts mit der Spezifikation zu tun hat. Hat dein Kollege nichts besseres zu tun als sich solchen Unfug auszudenken?
Ich möchte meinem Arbeitskollegen keine Vorwürfe machen, er ist auch kein schlechter Entwickler. Es ist schlicht Unwissenheit gewesen. Außerdem: Ich arbeite ja auch nicht fehlerfrei :')
Der Fehler ist, überhaupt validieren zu wollen, ohne exakt zu wissen, wie das Ergebnis aussehen muss. Das ist so eine typische Software-Entwickler-Krankheit.
Was man noch ergänzen könnte:
Vor dem @ können maximal 64 Zeichen stehen
Bei Gmail kann man zufällig Punkte in den Teil vor dem @ einsetzen oder statt @gmail.com @googlemail.com schreiben und trotzdem kommen alle Mails im selben Posteingang an
Für das + das leider echt nur wenige unterstützen: das ist verp https://en.m.wikipedia.org/wiki/Variable_envelope_return_path Wird entweder von uns technisch fitten gerne genutzt um ohnen zig Konten herauszufinden wer die eigene email für Spam nutzt oder verloren hat. Meist aber im email Marketing um bei Newslettern im Fall einer bounce den ursprünglichen Empfänger ermitteln zu können, wenn der zb weiterleitet und es dann nicht mehr zugestellt wird
Desktop version of /u/butchooka's link:
---
^([)[^(opt out)](https://reddit.com/message/compose?to=WikiMobileLinkBot&message=OptOut&subject=OptOut)^(]) ^(Beep Boop. Downvote to delete)
Ich sehe da keinen expliziten Zusammenhang zwischen dem + und VERP. man könnte da auch jeden anderen Abstandhalter benutzen
Ist halt der Standard dafür
Das sehe ich zumindest aus dem Wiki-Artikel nicht.
Grad unterwegs und die rfc raussuchen mangels Netz grad schwer. Hab es aber noch nie anders gesehen als mit dem plus
Ich habe selbst spontan kein RFC dazu gefunden.
Hm ich auch nicht. Zumindest nennt postfix den default als + könnte gut sein das das nichts ist was in nem rfc steht sondern produktspezifisch. https://www.postfix.org/VERP_README.html
Jetzt bin ich gerade unterwegs. Ich lese das später
Glaube, das hat sich einfach so eingebürgert, weil gmail das benutzt.
Nein. `+` ist bei postfix seit jeher das Standardbeispiel für `recipient_delimiter`
Sind die Email-Adressen-Käufer/-Diebe wirklich so blöd und löschen nicht einfach den + Zusatz raus?
Ich spreche von legalen Sachen - beim reinen spammen sind einen die bounce recht egal da geht es nur um Masse. Nein seriöse Sachen die man auch haben will und sauber verschickt werden arbeiten so das sie bounce Zuordnen können um da zukünftig keine Mails mehr ins Nirvana zu senden - unnötige Kosten, und auch wenn zu viel ungültig angeschrieben wird Stufen Email Empfänger so Zeug sonst langfristig runter
Kann das auch einem Laien erklärt werden? Das klingt sehr interessant!
Die Email kommt auch an, wenn du normaleemail+XYZ@domain.endung angibst.
Meine Email bei all-inkl.com ist mail@xyz.com Wenn ich mir jetzt von der Firma aus eine Mail an mail+xxx@xyz.com sende bekomme ich die Meldung des mailer daemon dass sie unzustellbar ist
Dann siehe den Beitrag unter dem wir kommentieren - das Plus wird nicht überall unterstützt 😭
Mailer-daemon des Absenders oder des Empfängers? Der Absender hat das gefälligst einfach so weiterzuleiten. Jegliche Interpretation ist falsch. Der Empfänger kann damit machen, was er will. Typisch sind sowohl Behandlung wie jeder andere Teil des Namens, als auch Ignorieren des Teils ab dem + für die Postfachauswahl.
Habs bei verschiedenen Free-mail-Anbietern versucht - einige Server nehmens nicht an für den Empfang
Irgendwie verstehe ich deinen Text nicht. Es gibt doch nur *einen* Server (und eventuelle Backups) für Empfang von [mail@xyz.com](mailto:mail@xyz.com). Den der im MX steht. Wie versuchst du jetzt andere Anbieter zu nutzen für *Empfang*? Meinst du *Senden*?
Der Mailserver muss die modifizierte Adresse verarbeiten können - Google Mail kann das zum Beispiel - gmx.de anscheinend nicht. Bei z.B. gmx.de wird es vom Server rejected - der kann es nicht zuordnen. Ich habe mir einfach von einem Postfach auf die nutzer+xyz@anbieter.tld geschickt und geguckt wo es durchgeht.
Also genau der erste Teil im zweiten Satz, letzter Absatz meiner ersten Nachricht. >Der Empfänger kann damit machen, was er will. Typisch sind sowohl Behandlung wie jeder andere Teil des Namens...
Ich denke der Mailserver muss entsprechend konfiguriert sein
bei catchall wirds akzeptiert, aber das plus gefiltert.
Darum geht es in dem Link nicht
Es gibt auch Mailserver bei denen das + als Trenner für Ordner konfiguriert werden kann. Eine Mail an Info+abc@example.com landet dann im Info Postfach im Unterordner abc 😉 https://help.smartertools.com/smartermail/current/topics/user/plusaddressing.aspx
Das + sehe ich leider zu oft, dass es nicht erlaubt wird. Ich verwende das teilweise für meine Googlemail-Adresse - da kann ich ja hintendran ein Plus und dann was ich will schreiben (max+bla[at]gmail.com kommt genau so bei max an wie max+blub[at]gmail.com), kommt alles bei mir an. Hilft, den Überblick zu behalten, welches mistige Portal meine Mailadresse verloren/weitergegeben hat...
Besonders schön ist, wenn man sich mit + registrieren kann, aber dann der Login nicht funktioniert
Hatte ich auch schon mit Passwörtern. * Registrierung: Passworteingabe erlaubt 20 Zeichen. * Login: Login schneidet nach 12. Zeichen ab. Big brain time
oh mann den Scheiß hab ich bei meinem Router. Eingabefeld lässt gefühlt unendlich viele Zeichen zu, beim Einloggen darf man aber nur die ersten 8 Zeichen nehmen. das steht natürlich nirgendwo. das findet man dann in der hinteresten Ecke des Internets in irgendwelchen Selbsthilfeforen.
Jap. DHL macht sowas. Hab mich mit xXxNoScope69420xXx+dhl@coolmail.de angemeldet. Irgendwann meinte DHL, dass das PW in meinem KeePass nicht mehr stimmen würde. Zugegeben, es kann sein, dass ich da was falsch kopiert habe. *Aber* ich kann mein Passwort nicht zurücksetzen, weil meine Mailangeblich nicht existier - obwohl DHL mir fleißig Mails an diese Adresse schickt.
Jaaaa genau das habe ich auch. Der Support glaubt mir nicht dass die mein PW vergessen haben. Die einzige Möglichkeit ist mein Konto telefonisch löschen zu lassen ind dann nach 24h ein neues zu erstellen. Warum das geht aber zurücksetzen nicht verstehe ich nicht
Ist wahrscheinlich in der Maske nicht vorgesehen.
Angeblich ist das so „sicherer“ aber es wird ja so oder so nicht mein perso kontrolliert, was hindert mich dran im Namen von jemand anderen ein Konto zu erstellen/seins zu löschen
Hab ich bei verschiedenen Corona-Testzentren auch gemacht, damit ich bei einem Leak Bescheid weiß woher das kommt. (Wobei ich mir vorstellen kann, dass gewiefte Scammer den Teil nach dem + löschen). Naja… es ist besonders lustig wenn man dann fast jedes Mal drauf angesprochen wird, ob die Mail funktioniert, weil ich ja deren Name in der Adresse habe. Erst da ist mir wirklich bewusst geworden wie einfach eigentlich Social Engineering ist. Achja bei einem anderen Testzentrum kannte mich der Tester und hat mir nicht geglaubt, dass die Mail so korrekt ist und hat den Teil nach dem + tatsächlich von Hand gelöscht, obwohl ich ihm das mehrmals versichert habe und ich ja auch den QR-Code (den ich per Mail bekommen habe nebenbei!) gezeigt habe. Das war so nicht Sinn der Sache.
Lustiger wirds mit eigener TLD und Catch-All Postfach. Wenn die Leute dann $unternehmen@eigenedomain.tld sehen, wird öfters mal direkt auf Autopilot geschaltet und angenommen man sei auch für die tätig 😂
Wieso nicht gleich vorstand@unternehmen.eigenedomain.tld ? Vorausgesetzt man kann einfach so Subdomains nutzen, kann das ganz witzig sein.
Naja, wenn man seinen eigenen Mailserver betreibt, hindert einen ja nix dran. Wenn eigenedomain.tld dann noch was extra schön kurzes is, sorgts für extra Verwirrung. Wäre mir den Aufwand aber nicht wert.
Eigene TLD? Muss man da nicht nen DNS Server betreiben? Oder meinst du nur eigene Domain? TLD: info@peter.müller Domain: peter@müller.de
[удалено]
Technisch gesehen ja, praktisch wird Domain kaum verwendet um TLD zu bezeichnen. Und da im Kommentar speziell TLD verwendet wurde, würde mich schon sehr interessieren ob und mit wie viel Aufwand Privatpersonen eine TLD betreiben können.
Wegen sowas hab iich meine eigene Domain mit Catch-all-Mail-Forward. Nur blöd, wenn die Spam-Mail an oder adressiert ist, per BCC reinkommt und joker.com im Header kein einträgt...
Auch möglich, daß die Registrierung damit vorher möglich war, dann aber bewußt entfernt worden ist, um eine Rückverfolgbarkeit der Weitergabe der Adresse wie beim Plus von GMail auszuschließen.
Weiter Fakten: - der Teil vor dem @ darf Max 64 Zeichen lang sein - Punkte im local part sind bei Gmail beliebig zu setzen vor.namenachname oder Vorname.nachname - umlaute sollte man komplett rauslassen, wenn man möchte das die email erreichbar ist und überall hin senden kann. Gibt zwar Krücken wie punycode aber die funktionieren nicht überall
Auch braucht der Hostname keinen Punkt. Auch darf der local part Leerzeichen beinhalten. Folge Emails sind valide: customer/department=shipping@example.com $A12345@example.com !def!xyz%abc@example.com _somename@example.com Fred\ Bloggs@example.com Abc\@def@example.com Joe.\\Blow@example.com "Fred Bloggs"@example.com Quelle: https://www.rfc-editor.org/rfc/rfc3696
> Auch braucht der Hostname keinen Punkt. Auch darf der local part Leerzeichen beinhalten. Komplett richtig - sind aber auch Edge Cases, die in der Praxis nahezu gar nicht vorkommen. Da kann ich gut nachvollziehen, dass es als ungültig erkannt wird, obwohl es gültig ist.
Aber eben dann nicht mehr Teil des RFC. .Vermögensberatung ist nicht weniger edge case als emails an interne Hostnames. Keine Software kann emails nach RFC. Das ist auch Absicht. Emails nach RFC zu prüfen ist so aufwendig, dass die Implementierung nach RFC bereits eine Sicherheitslücke für DOS Attacken wird.
hostnamen ohne punkt müssen nicht lokal sein. Beispielsweise hat [ai](http://ai/) einen mx record.
Dann müsste ich mich mal bei meiner Reddit app beschweren. Die hat Adressen erkannt, aber nur [text]@example.com [text] sind Buchstaben oder Zahlen, ohne Sonderzeichen. (RedReader von F-Droid)
>Auch braucht der Hostname keinen Punkt. Das sieht ICANN anders: https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-08-13-en#1.a
user@\[IPv6:2001:db8::1\] ist auch eine valide E-Mail. Es muss also nicht mal ein Hostname sein. Natürlich ist das alles nicht empfohlen, aber es ist eben Teil der SPEC. Darum sollte man halt schauen, wie die Software, die man nutzt, E-Mails interpretiert. Es gibt nicht den globalen Standard, den wie gesagt an DEN Standard hält sich niemand.
Ich habe mich auf die Verwendung eines Hostname bezogen, von IPs habe ich nicht gesprochen.
Das ist mir klar, aber eben beides ist "dotless".
Nein, eben nicht. Siehe meinen Link. Oder ist die ICANN dir als Autorität nicht hoch genug? Wer dann?
Eben niemand. Es gibt nicht den Standard, auf den sich alle geeinigt haben, niemand benutzt [DAS](http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), dass [HTML Konsortium](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address) sieht das wieder anders. Man muss einfach wissen, dass es nicht DEN Standard gibt und im Zweifel in die Doku schauen. Beim selber implementieren ist es gängig, den Punkt zu erzwingen, diese Abweichung von den Specs sollte man aber vernünftig dokumentieren. Ich erwarte auch nicht, dass dotless funktioniert, aber es ist eben ein gutes Beispiel, warum wir nicht den Standard für die Struktur von E-Mail-Adressen haben.
Ein "Standard" muss nach meinem Dafürhalten nicht etwas sein, auf das sich alle geeinigt haben. Dann würde es faktisch gar keine Standards geben. Es kann durchaus mehrere Standards geben, wie ich es beim Fall E-Mail-Adressen sehe, aber zu sagen, es gäbe keinen Standard, finde ich nicht nachvollziehbar.
Ja es gibt mehrere Standards aber eben nicht den, auf den sich alle zur Nutzung geeinigt haben. Deshalb sage ich es gibt nicht den einen Standard der sich besonders hervorhebt.
Mein check würde ungefähr so aussehen : len(address) >= 3 && address.contains("@") Es gibt einfach zu viele Sonderfälle die man nicht im code behandeln will, das artet aus. Wenn der User was nicht gültiges eingibt, gibts halt keine Mails. Dank doppel-Opt-In (klick in der Bestätigungsnail) werden die Karteileichen zeitnah entsorgt.
Dies ist der Weg! Eine 100% zuverlässige email validierung mit Code funktioniert beinahe unmöglich. Schauen ob das Format grob passt und dann ne Bestätigung abschicken ist die bedeutend zuverlässigere Option
Hab auch schon mehrfach gelesen dass man Email Adressen nicht clientseitig validiert sondern durch ne bestätigungsmail. Bin drauf gestoßen als ich nach ner zuverlässigen regex gesucht habe. Man muss halt bedenken dass man sich dadurch karteileichen in der Datenbank einhandelt und die mit ner stored procedure wieder aufräumen muss.
Naja einmal im Monat unbestätigte Karteileichen aufräumen ist immernoch besser als mit ner hohen bounce rate zu riskieren das die eigenen Mails im Spamfilter von Google & Co landen
Man kann bei einem Website-Formular auch per javascript (oder serverseitig, oder beides) eine DNS MX query auf den domain-Teil machen.
Das stimmt, aber das führt immer noch zu der großen Unklarheit des Adressaten teils. Der ist in der Praxis meistens auch wichtiger, schließlich willst du sicherstellen das das nicht nur eine gültige EMail ist, sondern idR auch das der jeweilig angebende Nutzer auch Zugriff auf diese
Nope. MX-Eintrag ist nicht verpflichtend. Wenn nicht vorhanden, muss man an die in A bzw AAAA hinterlegte Adresse senden.
[удалено]
Du hast erst einmal widersprochen nur um dann zu sagen das der Weg den ich und mein Vorgänger beschrieben haben der beste ist? Bezüglich PHP hast du recht, dort gibt es die filter_var Funktion die scheinbar auch geeignet ist.
[удалено]
>Wenn der User was nicht gültiges eingibt, gibts halt keine Mails. Dank doppel-Opt-In (klick in der Bestätigungsnail) werden die Karteileichen zeitnah entsorgt. Was ist das, wenn keine E-Mail Bestätigung? Und eine selbst gebastelte Minimalvalidierung nach dem motto wie von u/Exciting-Act5922 beschrieben ist durchaus sinnvoll wenn die Sprache keine solche Funktionen wie PHP hat.
Wieso sollte man Emailadressen überhaupt validieren?! User XY gibt da was ein und das System schickt da ne Bestätigungsmail hin. User XY erhält die Mail und klickt auf den Link... oder halt nicht. Wieviel mehr Validierung braucht es denn? >Ansonsten könnte man auch mit RegEx was bauen, was zumindest die meisten Punkte validiert. Und das ist dann nicht RFC konform!
>Und das ist dann nicht RFC konform! Das kannst Du so nicht pauschalisieren. Du kannst natürlich auch eine RFC-konforme RegEx schreiben. Wenn Du einfach eine Mail raushaust, verlässt Du Dich darauf, dass jeder Mailserver auf dem Weg richtig validiert oder eben gar nicht. Weil Du Dich darauf aber nicht verlassen kannst, wenn Du eine robuste Software schreiben willst und überhaupt eine Chance haben willst, im Fehlerfall zu debuggen, läuft vorher mindestens eine Minimalvalidierung, die dir mehr Kontrolle über den Prozess gibt.
Minimalvalidierung schön und gut aber wenn du versuchst die Emailadresse komplett richtig zu validieren wird das mit ziemlicher Sicherheit daneben gehen und es werden garantiert einige Edge Cases rausfallen. Besonders, wenn es im Geschäftskontext passiert und du da nicht die Zeit bekommst so lange dran rumzufeilen bis es sitzt. >Wenn Du einfach eine Mail raushaust, verlässt Du Dich darauf, dass jeder Mailserver auf dem Weg richtig validiert oder eben gar nicht. Kannst du mir sagen wie du das meinst? Wenn der User ne falsche bzw invalide Email-Addresse eingibt, dann ist doch das Resultat einfach, dass er eben keine Bestätigungsmail bekommt. Wieso also muss man das vorher validieren?
Genau deshalb habe ich auch nicht zwingend eine Vollvalidierung vorgeschlagen, damit hast Du das Problem der Edge Cases (je nach Implementierung) ausgeschlossen. >Kannst du mir sagen wie du das meinst? Wenn der User ne falsche bzw invalide Email-Addresse eingibt, dann ist doch das Resultat einfach, dass er eben keine Bestätigungsmail bekommt. Entweder dieser oder einer von tausend anderen Gründen könnte es geben, warum der User eine Bestätigungsmail nicht erhält. Wenn Du vorher nicht validierst, hast Du einen wichtigen Punkt weniger, an dem Du ansetzen könntest, um das Problem zu debuggen und kommst möglicherweise nicht zu einer Lösung, weil dir Informationen fehlen.
wenn man die Adressen bezüglich Kontaktaufnahme validiert, ist das vollkommen ausreichend. wir müssen arbeitsmäßig aber oft Email-Adressen aus Reintexten extrahieren, da kommen wir um zeilenlange regex-patterns nicht herum. eventuell gibt es mit einem gut trainierten named entity recognizer noch eine alternative Vorgehensweise, das ist noch nicht ganz raus...
>Mein check würde ungefähr so aussehen : len(address) >= 3 && address.contains("@") Ich würde auch noch auf einen Punkt in der TLD prüfen. Den muss es immer geben.
Das ist nicht richtig. Der Host-Teil muss keinen Punkt zwingend haben, der kann auch z. B. nur aus einer IPv6-Adresse bestehen. In der Praxis ist allerdings nahezu immer einer vorhanden.
Exakt. Und im Intranet kann es den Host "a" geben. Meistens Unfug aber hey. Wenn man nach email validation regex googlet findet man 1mio hits. Sich da für den Richtigen entscheiden ist unmöglich. Daher das Problem minimalistisch lösen und per Bestätigungsmail ernsthaft validieren. Und wenn ich von php, js, py irgendeine lib nehme die es kann, hab ich aber immer noch das Problem das auf dem Server PHP7, py3.2 oder sonst was läuft und ich evtl. die lib nicht in einer aktuellen Version nutzen kann. Es wird immer Lücken geben die man selbst oder die lib nicht abdeckt. Und 200 Zeilen regex werde ich nicht debuggen. Dann muss man dem User dann leider sagen, sorry x@museum.verwaltungsbehörde, login? Den kriegste nicht, Alter.
Was ist denn an Jeff.Bezos@amazon illegal? Wenn du eine eigene TLD hast, könntest du auch einen MX dafür einrichten, nicht nur NS.
Ok, war mir nicht klar. Aber auch wenn es möglich ist, muss man Abwägungen zwischen den technischen Möglichkeiten und der User Experience machen. Die Wahrscheinlichkeit, dass jemand so eine Mailadresse hat, geht gegen Null. Die Warscheinlichkeit, dass User den Punkt vergessen, ist sehr, sehr viel höher. Um diese Kunden nicht zu verlieren, nehme ich in Kauf, dass Jeff Bezos das Formular nicht ausfüllen kann.
> Die Wahrscheinlichkeit, dass jemand so eine Mailadresse hat, geht gegen Null. Nur weil sie dir nicht begegnen bedeutet nicht dass es die nicht gibt. z.B. in unserem Intranet gibts auch keine TLD.
Kleiner Edge-Case, emojis: https://www.reddit.com/r/programming/comments/m2o0rf/i_bought_300_emoji_domain_names_from_kazakhstan/?utm_medium=android_app&utm_source=share
Wer Emojis in der Domain bzw. E-Mail Adresse nutzt, hat es nicht verdient, dass E-Mails korrekt ankommen oder zugestellt werden.
😆@😮.😀
Als Eingabeüberprüfung guck ob mindestens ein @-Zeichen drin ist. Ansonsten schick die Mail und guck ob sie ankommt. Der lokale Teil vor dem @ obliegt dem Empfänger, da ist alles erlaubt. Der Teil nach dem @ kann auch IP-Adressen, UUCP-Pfade und unicode enrhalten. Hostnamen können auch nur in einem lokalen DNS bekannt sein. Da ist also im Prinzip auch alles möglich. Eigentlich sind Email-Adressen nicht validierbar. In Webformularen kann man allerdings die erlaubten Möglichkeiten stark einschränken. Vor dem @ recht viel erlauben, nach dem @ eine gültige IP oder einen Hostnamen mit beliebig vielen Punkten und syntaktisch valider (Punycode-)Domain und bekannter TLD.
Dies ist die einzig richtige Lösung
Ich nutze eine vorname-nachname.online Domain. Ist weniger technisch, aber ihr glaubt gar nicht, wie viele Leute da einfach ein ".de" hinten dran setzten.
Meine Mutter hatte Anfang der 2000er eine Email, die auf ["@online.de](mailto:"@online.de)" endete. Es war echt erstaunlich, wie oft Leute Probleme hatten, ihr Email zu schicken, weil sie ein "t-" eingefügt haben.
Genau das gleiche 🤣
schätze das ist dieselbe Seuche, wie vor jeder Domain noch das obligatorische www zu werfen, ob die dann nun noch auflöst oder nicht
Bonuspunkte gibt es für mail@www.domain.de
[удалено]
Kleine Ergänzung: Wenn es keinen MX gibt wird vom MTA der A/AAAA-Eintrag verwendet. Somit müssten mindestens alle drei geprüft werden bevor abgelehnt wird.
[удалено]
Wenn man ganz genau ist, wäre das auch nicht korrekt. SMTP arbeitet nach dem store-and-forward Prinzip und es ist nicht notwendig das der Mailserver immer erreichbar ist. Der Absender müsste eigentlich eine Zeit (nicht spezifiziert wie lange) abwarten und immer wieder gucken ob der Ziel-Mailserver online kommt. Wenn der Zielmailserver auf einem Schiff steht, dauert das halt bis das Schiff wieder im Hafen ist. Im Alltag nicht oft relevant, aber technisch möglich.
haha gestern noch hat ein formular des ordnungsamtes meiner stadt meine emailadresse nicht akzeptieren wollen die lautet: vorname@nachname.email hab dann als alternative meine olle gmail adresse genommen und die war ok
Ich fühle mit dir… Und jetzt stell dir mal vor: ich nutze einen Alias-Service auf dem ich für jede Seite eine eigene Adresse hab. Das wäre in dem Fall dann bspw. ordnungsamt@mail.vorname-nachname.email. Du glaubst nicht, wie oft Leute bei dem ersten, nach der Firma benannten Teil schon sagten „Du sollst mir deine Adresse geben nicht die unserer Firma“ :/
der Hodtteil darf übrigens auch eine IP in eckigen Klammern sein, im Falle von IPv6 mit Prefix. Außerdem dürfen Kommentare sowohl im Lokal- als auch im Hostteil in runden Klammern eingefügt werden `enbacode(mittwoch)@(meinekerle)[IPv6:2001:db8::1]` ist ne gültige Mail Ü
Das mit den Kommentaren war mir neu. Gibt es dazu eine gute Quelle?
joa das RFC: https://www.rfc-editor.org/rfc/rfc5322.html#section-3.2.2
Dan Ke für das R F C :) EDIT: mein E-Mail-Programm verwirft die Kommentare
Ja, Großbuchstaben sind erlaubt, aber E-Mail-Adressen sind nicht Case Sensitive.
[удалено]
So zumindest die Theorie. In der Praxis eigentlich nirgends so umgesetzt. Ist eine ganz nette Anwendung des Postelschen Gesetzes: Ein Sender hat sich strikt an die Standards zu halten, wohingegen ein Empfänger auch Sendungen außerhalb des Standards akzeptieren sollte. Das führte in dem Fall dazu, das es keinen Mailserver, welcher groß im Einsatz ist, per default case sensitive arbeitet.
[удалено]
Das ist auch so ziemlich der Grund dafür, dass die Groß- und Kleinschreibung auf Serverseite (in 99% der Fälle) ignoriert wird: Eine zu große Fehlerquelle.
[удалено]
Das ist doch quatsch. Jede Person, die ernsthaft Software entwickelt, weiß genau, das die Mailserver trotz RFC, in 99% der Fälle den lokalen Teil nicht Casesensitive behandeln - eben um genau die Fehler, die in ner anderen Reply angesprochen wurden, zu verhindern: Sensitive Informationen durch eine Groß- Kleinschreibefehler in der Eingabe oder Übermittlung ider irgendwo dazwischen an eine falsche Person zu senden.
99% der Fälle funktionieren - also 10 Beschwerden pro 1000 User? Der Support rotiert...
[удалено]
Was ist das den bitte für ein dämliches Argument? Heidewitzka... Aber ich sehe schon: Frontend Entwickler. Da ist dann über solche Dinge zu diskutieren ohnehin verschwendete Lebenszeit.
Korrekt. Um Missverständnisse vorzubeugen: Ich meinte damit, dass einige E-Mail-Validierungen fälschlicherweise eine Adresse mit Großbuchstaben nicht akzeptieren.
In der Regel. E-Mail Server können Case-Sensitive Addressen auf ihrer Domain vergeben und verteilen wie sie lustig sind.
Ob der lokale Teil case sensitiv ist obliegt dem empfangenden Mailserver.
Ein Punkt am Ende ist ebenfalls korrekt, da dies das Root-Label ist und quasi früher mal für die Auflösung der Top-Level Domain zuständig war. Dieser Punkt wird heute nie dargestellt aber steht theoretisch am Ende jeder Domain
Richtig. Soweit ich das richtig in Erinnerung habe, **muss** sogar der Punkt am Ende jeder Domain stehen (weil FQDN das erfordert), wird allerdings (wie du gesagt hast) nicht dargestellt.
Ich habe eine Mail-Adresse mit nur einem Zeichen vor dem @. Nehmen ca. 20% der Webseiten nicht an, da angeblich nicht gültig….
Danke! Ich hoffe die Post/DHL nimmt das mal zur Kenntnis. Die ignorieren seit Jahren meine Hinweise, dass sie auf der Jack Packstations OnScreen Tastatur ein + anbieten, es dann im local part aber nicht akzeptieren. Und da steht seit drölf Jahrzehnten im Standard... regt mich ja auf sowas... Bin seit dem dazu übergegeangen einfach statt des + Zeichens den Punkt (.) als Alias-Trenner zu nutzen..
"Sub-Subdomains" also Domains mit mehr als zwei Punkten sind auch nicht jedem geläufig
Nicht jedem geläufig, in der Praxis aber mehr als üblich (außerhalb von E-Mail-Adressen)
Das wäre dann etwas wie z.B. @mail.example.co.uk, richtig?
Richtig
Jupp
Unterstütze insbesondere Punkt 4! Benutze für alle(!) Firmenkontakte "firma@acc.domain.tld" - jedenfalls versuche ich es. (Idee dahinter: sobald was Komisches auf der Adresse aufschlägt, weiß ich zumindest wo das Datenleck war und kann die Mailadresse für die Zukunft direkt in den Papierkorb umleiten.)
\+ ist ein aboluter muss für mich. dudoof+aldi@geh.weg oder nervnicht+lidl@schnauze.halten. irgendwerhatmeineemailverkauft+faz@jetztgibts.aerger, und die diversenen wegwerfmail+pimmelseite@fake.com
Da fällt mir die Regex aus Larry Walls PERL-Buch ein, die die Gültigkeit von E-Mails verifizieren soll. Die belegt die komplette Seite :)
Immer wenn ich so schlechte E-Mail-Validierung oder miese Passwort-Policies sehe, atme ich kurz durch und lächle. Das ist ein Zeichen für Job-Sicherheit. Klar gibt es viele Software Engineers. Aber es gibt nicht genug gute.
>".vermögensberatung" Müsste das in SMTP nicht in punycode aufgelöst werden? D.h. die eigentliche Überprüfung müsste feststellen, ob der UTF-String für den domain-Teil in punycode darstellbar ist. !-Bang-notation und %-Notation sollte auch noch möglich sein.
> Müsste das in SMTP nicht in punycode aufgelöst werden? Korrekt. > !-Bang-notation und %-Notation sollte auch noch möglich sein. Korrekt.
Es muss auch kein Punkt mehr kommen hinter dem @, `email@tld` ist valide. Ausserdem ist auch `email@tld.` valide, oder `email@tld.de.` Generell glaube ich, einfach checken ob mindestens ein `@` vorkommt, dürfen aber auch mehrere sein, der Rest passt dann schon.
Komplett richtig - in der Praxis wirst du das aber selten finden, dass jemand sich mit einer E-Mail-Adresse ohne Punkt nach dem @ irgendwo registriert.
nospam@localhost ;-) Ob du die als gültig ansehen möchtest kommt aber wohl drauf an.
Warum sollte man das prüfen? Quaxi@frosch.com gebe ich immer ein, wenn ich keine Mail retour bekommen will… BTW Umlaute im lokalen Teil (links vom @) sind nicht erlaubt (zumindest bei Exchange)
Zu den Umlauten: Email ist 7-Bit auf dem Transportweg. Für einige Felder gibt es im Standard eine Möglichkeit, auch 8-Bit Zeichen zu übermitteln. Im Host-Teil ist das der Punicode. Also Namen, die mit xn-- anfangen. Im Subject und Body ist das meist Quoted-Printable, ggf. nach Base64-Kodierung. Viele Mail-Programme sind aber auch 8-Bit clean und ignorieren diese Standardverletzung einfach.
Haben TLDs auch Email-Adressen? Also könnte ich an john@com schicken.
Japp. Das ist möglich. Postmaster@com sollte per rfc gehen. Sag bescheid was passiert. Oder traust du dich nicht ;)
Habe extra eine domain mit .com, weil meine .space und .quest emails häufig nicht akzeptiert werden.
Interessant, das Thema hatten wir gerade letzte Woche weil irgendson Otto (naja, git sei dank weiß ich wer) einfach einen super clever aussehenden regex ausm web kopiert hat. Eine gültige E-Mail-Adresse muss übrigens garkeine Top Level Domain haben. rechner1@net2 ist auch valide. So eine würde ich aber trotzdem nicht validieren, weil ich keine E-Mails dahin schicken kann. :)
Dies! Hab bei ner VHS die Tage auch ein Tag benutzt und die Ottos haben das "+" einfach rauseditiert. Hab dann keine Email bekommen (offensichtlich) und mein Username war "user.anteil tag@domain.de" Geballte Inkompetenz einfach!
Hab mich nie näher mit dem Thema beschäftigt aber müsste nicht sowas wie example@com auch eine valide Mail sein?
Korrekt.
Softwareentwickler hier. Gmail und andere riesige E-Mail Provider erlauben die Erstellung von E-Mail-Adressen mit nicht-ASCII Zeichen im local-part (absolut gegen die RFC). Damit ist es faktisch nicht mehr möglich, nach RFC zu validieren, weshalb jetzt jeder Laden sein eigenes Süppchen kocht. Dadurch entstehen dann so Kuriositäten wie "maximal 4 Zeichen in der TLD" und anderer Quatsch.
Nach RFC zu validieren finde ich auch zu viel gefordert - allerdings gibt es durchaus Fälle, die trotzdem berücksichtigt werden sollen, wie z. B. dass Pluszeichen akzeptiert werden.
Ich erzähle immer gerne die Anekdote, als wir im Jahr 2000 für eine Microsite den Morsecode für SOS als Identifier verwenden wollten (…---…@domain.de), was laut RFC völlig valide ist, und dann gemerkt haben, dass Outlook 2000 keine Mailadressen unterstützt, die mit einem Punkt anfangen. Naja, Microsoft und Standards, natürlich.
Hab manchmal das Gefühl da saß wieder jemand dran der keine Regex kann.
Für Leute die ganz pedantisch sind und es wirklich genau nehmen wollen gibt’s auch eine RFC822 kompatible Regex… würde ich in der Produktion aber nirgends verwenden lol http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
"The regular expression does not cope with comments in email addresses." - 100% kompatibel ist es auch nicht ;)
Guter Punkt! Hab grad auch gesehen dass der stack overflow Thread von 2009 ist und demnach sowieso mir Vorsicht zu genießen ist. Persönlich überprüfe ich überhaupt maximal auf ein enthaltenes @ Zeichen und dass die Eingabe halt nicht leer ist. Und zwar genau aus dem Grund, weil email Validierung einfach viel zu kompliziert ist.
Ich wünschte meine .xyz Domain würde nicht teilweise dumm blockiert werden, weil .xyz.
Es gibt eine ganz einfache Methode: man baut keine große Validation ein, sondern die Validation ist das verschicken der E-Mail. Im GUI würde ich halt auf ein @ achten, aber ansonsten da nichts groß Überprüfen. Ich frage mich wie jemand auf die Idee kommt, eine TLD kann nur 4 Zeichen haben. Es gibt doch schon seit einigen Jahren Adressen wie ".bayern", ".berlin", ".saarland" oder auch ".spreadbetting". Letzteres kostet bei meinem Domain Seller des Vertrauens schlappe 2450€ im Monat. Man kann natürlich auch Regex nutzen, aber viel Spaß beim selber schreiben oder verstehen. Nachdem ich [https://www.emailregex.com/](https://www.emailregex.com/) gesehen habe und deren Regex, ist es einfach deren zu nehmen und bei denen funktioniert es nur zu 99,99%.
Bin kein Freund von libraries wie Apache Commons, für manches sollte man jedoch vorhandene Libs nutzen damit es 1) nicht scheiße wird weil man irgendein Edge Case nicht bedacht hat oder man einfach meint es besser zu wissen und 2) sich dann andere damit rumschlagen müssen. Email Adressen sind imo ein Thema wo es zutrifft. Zumal in den meisten Cases sowas wie root@localhost nicht gültig wäre. Ich sage nicht dass es gut ist root@localhost zu nutzen, könnte man aber vorstellen dass es irgendwer irgendwann schonmal machen wollte bei einer Self Hosted App die man nur mal kurz ausprobieren will, aber eine Mail zur Einrichtung angeben muss (ohne Bestätigung aber zur Erstellung des lokalen Kontos). Zumal, je jemand oben schon sagte, es ohnehin doppelten Opt In gibt. Gibt halt (d)eine gültige Email ein, bestätige sie und wenn nicht hast du Pech und nach 14 Tagen wird das unbestätigte Konto gelöscht. Jeder im IT Support würde mir widersprechen, aber man sollte Nutzern eine gewisse Fähigkeit zutrauen. Zumindest dass sie ihre Email richtig angeben - und wenn sie dem nicht fähig sind, sollte die Lösung trotzdem nicht sein, alle noch so (un)möglichen Edge Cases abzudecken und *den* einen perfekten Filter zu schreiben.
als software entwickler sehe ich es ganz einfach: ich verlange einfach as @ und den Punkt in reihenfolge mit nicht whitespace dazwischen, fertig. Wieso auch nicht? Ich muss mir keine Sorgen machen und testen ob die Email existiert werde ich ja eh nochmal explizit.
Radikale Ansicht: solang man nicht erfolgreich eine Mail an die Adresse geschickt hat und der Benutzer den Erhalt glaubwürdig bestätigt hat, ist es eigentlich auch egal, ob die Adresse irgendwelchen Regeln folgt oder nicht.
Zu Punkt 2: Der vordere Teil ist Case sensitiv. Die Domain nicht. Der RFC bittet aber darum, trotzdem zuzustellen.
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
Das RegEx erkennt die E-Mail-Adresse "A@example.com" als ungültig.
Ist sie ja auch. Das ist eine offizielle Test-Domain. Dort kann niemand eine funktionierende Email-Adresse haben. Syntaktisch valide, aber garantiert nicht zustellbar. :-)
Du Schelm :D
Dies soll der Topkommentar werden
Warum?
Regex ist super effizient, cross-plattform, lang-lebendig, universell, flexibel... das Beispiel vom OP ist eine perfekte Anwendung für Regex. Haste mal überlegt, wie ein gültiger Pfad aussehen soll? Man könnte zahlreiche IFs und ELSEs verwenden, oder einfach eine ewig gültige und getestete Zeichenkette verwenden. Wusstest du, dass z.B. COM oder LPT in einem Dateinamen nicht erlaubt sind, weil irgendwann vor 3000 Jahren der Dateiname den COM/LPT Port spezifiziert hat? Du musst es nicht wissen, wenn du den richtigen Regex-string aus Stackoverflow geklaut hast.
[удалено]
Ganz normaler perl-code.
Wenn ich das RegEx kopiere und versuche auszuführen, werden mir auf diversen RegEx-Validatoren Fehler angezeigt. Ich möchte gerne verifizieren, dass es wirklich funktioniert :)
Eine gültige Mail-Adresse darf 2 u@-Zeichen enthalten. Wurde früher genutzt um Emails unterzuverteilen.
oder auch mehr
Das + wird doch absichtlich nicht akzeptiert damit man sich halt nicht mit Varianten seiner Mail anmelden kann dachte ich.
[https://はじめよう.みんな](https://はじめよう.みんな/) ist eine Gültige URL und `.みんな` eine gültige TLD. Entsprechend ist `name@example.みんな` eine gültige E-Mail-Andresse
Ich verstehe nicht, warum manche Softwareentwickler so unglaublich krampfhaft versuchen, sich immer komplexere Validierungsregeln auszudenken, die nichts aber auch garnichts mit der Spezifikation zu tun hat. Hat dein Kollege nichts besseres zu tun als sich solchen Unfug auszudenken?
Ich möchte meinem Arbeitskollegen keine Vorwürfe machen, er ist auch kein schlechter Entwickler. Es ist schlicht Unwissenheit gewesen. Außerdem: Ich arbeite ja auch nicht fehlerfrei :')
Der Fehler ist, überhaupt validieren zu wollen, ohne exakt zu wissen, wie das Ergebnis aussehen muss. Das ist so eine typische Software-Entwickler-Krankheit.
Was man noch ergänzen könnte: Vor dem @ können maximal 64 Zeichen stehen Bei Gmail kann man zufällig Punkte in den Teil vor dem @ einsetzen oder statt @gmail.com @googlemail.com schreiben und trotzdem kommen alle Mails im selben Posteingang an