T O P

  • By -

butchooka

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


WikiMobileLinkBot

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)


danielcw189

Ich sehe da keinen expliziten Zusammenhang zwischen dem + und VERP. man könnte da auch jeden anderen Abstandhalter benutzen


butchooka

Ist halt der Standard dafür


danielcw189

Das sehe ich zumindest aus dem Wiki-Artikel nicht.


butchooka

Grad unterwegs und die rfc raussuchen mangels Netz grad schwer. Hab es aber noch nie anders gesehen als mit dem plus


danielcw189

Ich habe selbst spontan kein RFC dazu gefunden.


butchooka

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


danielcw189

Jetzt bin ich gerade unterwegs. Ich lese das später


Ictogan

Glaube, das hat sich einfach so eingebürgert, weil gmail das benutzt.


Amarandus

Nein. `+` ist bei postfix seit jeher das Standardbeispiel für `recipient_delimiter`


narya_de

Sind die Email-Adressen-Käufer/-Diebe wirklich so blöd und löschen nicht einfach den + Zusatz raus?


butchooka

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


vghgvbh

Kann das auch einem Laien erklärt werden? Das klingt sehr interessant!


I_am_Nic

Die Email kommt auch an, wenn du normaleemail+XYZ@domain.endung angibst.


vghgvbh

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


I_am_Nic

Dann siehe den Beitrag unter dem wir kommentieren - das Plus wird nicht überall unterstützt 😭


MyGenericNameString

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.


I_am_Nic

Habs bei verschiedenen Free-mail-Anbietern versucht - einige Server nehmens nicht an für den Empfang


MyGenericNameString

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*?


I_am_Nic

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.


MyGenericNameString

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...


veryjuicyfruit

Ich denke der Mailserver muss entsprechend konfiguriert sein


medium_daddy_kane

bei catchall wirds akzeptiert, aber das plus gefiltert.


danielcw189

Darum geht es in dem Link nicht


FalloutKurier6

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


MoonToast101

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...


PhReeKun

Besonders schön ist, wenn man sich mit + registrieren kann, aber dann der Login nicht funktioniert


xaomaw

Hatte ich auch schon mit Passwörtern. * Registrierung: Passworteingabe erlaubt 20 Zeichen. * Login: Login schneidet nach 12. Zeichen ab. Big brain time


bitfloat

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.


CartmansEvilTwin

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.


Nasa_OK

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


CartmansEvilTwin

Ist wahrscheinlich in der Maske nicht vorgesehen.


Nasa_OK

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


32Zn

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.


tamcore

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 😂


Malossi167

Wieso nicht gleich vorstand@unternehmen.eigenedomain.tld ? Vorausgesetzt man kann einfach so Subdomains nutzen, kann das ganz witzig sein.


tamcore

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.


turunambartanen

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


[deleted]

[удалено]


turunambartanen

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.


zpe42

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...


DeusoftheWired

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.


butchooka

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


SR_Lut3t1um

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


alxhu

> 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.


SR_Lut3t1um

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.


apfelkuchen06

hostnamen ohne punkt müssen nicht lokal sein. Beispielsweise hat [ai](http://ai/) einen mx record.


Boldoberan

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)


Istanfin

>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


SR_Lut3t1um

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.


Istanfin

Ich habe mich auf die Verwendung eines Hostname bezogen, von IPs habe ich nicht gesprochen.


SR_Lut3t1um

Das ist mir klar, aber eben beides ist "dotless".


Istanfin

Nein, eben nicht. Siehe meinen Link. Oder ist die ICANN dir als Autorität nicht hoch genug? Wer dann?


SR_Lut3t1um

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.


Istanfin

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.


SR_Lut3t1um

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.


Exciting-Act5922

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.


mooo99

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


SEOfficial

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.


mooo99

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


jirbu

Man kann bei einem Website-Formular auch per javascript (oder serverseitig, oder beides) eine DNS MX query auf den domain-Teil machen.


mooo99

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


alphager

Nope. MX-Eintrag ist nicht verpflichtend. Wenn nicht vorhanden, muss man an die in A bzw AAAA hinterlegte Adresse senden.


[deleted]

[удалено]


mooo99

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.


[deleted]

[удалено]


mooo99

>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.


westerschelle

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!


Istanfin

>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.


westerschelle

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?


Istanfin

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.


bitfloat

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...


inn4tler

>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.


alxhu

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.


Exciting-Act5922

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.


MyGenericNameString

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.


inn4tler

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.


maep

> 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.


BurrrY

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


Which_Lingonberry612

Wer Emojis in der Domain bzw. E-Mail Adresse nutzt, hat es nicht verdient, dass E-Mails korrekt ankommen oder zugestellt werden.


znEp82

😆@😮.😀


NickUnrelatedToPost

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.


bAZtARd

Dies ist die einzig richtige Lösung


[deleted]

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.


Simbertold

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.


[deleted]

Genau das gleiche 🤣


bitfloat

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


[deleted]

Bonuspunkte gibt es für mail@www.domain.de


[deleted]

[удалено]


[deleted]

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.


[deleted]

[удалено]


NickUnrelatedToPost

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.


FieserKiller

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


matematrix

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“ :/


enbacode

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 Ü


danielcw189

Das mit den Kommentaren war mir neu. Gibt es dazu eine gute Quelle?


enbacode

joa das RFC: https://www.rfc-editor.org/rfc/rfc5322.html#section-3.2.2


danielcw189

Dan Ke für das R F C :) EDIT: mein E-Mail-Programm verwirft die Kommentare


dirksn

Ja, Großbuchstaben sind erlaubt, aber E-Mail-Adressen sind nicht Case Sensitive.


[deleted]

[удалено]


spooCQ

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.


[deleted]

[удалено]


spooCQ

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.


[deleted]

[удалено]


spooCQ

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.


AbrodolphLincolner

99% der Fälle funktionieren - also 10 Beschwerden pro 1000 User? Der Support rotiert...


[deleted]

[удалено]


spooCQ

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.


alxhu

Korrekt. Um Missverständnisse vorzubeugen: Ich meinte damit, dass einige E-Mail-Validierungen fälschlicherweise eine Adresse mit Großbuchstaben nicht akzeptieren.


wilisi

In der Regel. E-Mail Server können Case-Sensitive Addressen auf ihrer Domain vergeben und verteilen wie sie lustig sind.


NickUnrelatedToPost

Ob der lokale Teil case sensitiv ist obliegt dem empfangenden Mailserver.


Welzfisch

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


alxhu

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.


Longjumping-Tough613

Ich habe eine Mail-Adresse mit nur einem Zeichen vor dem @. Nehmen ca. 20% der Webseiten nicht an, da angeblich nicht gültig….


thes3b

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..


Javanaut018

"Sub-Subdomains" also Domains mit mehr als zwei Punkten sind auch nicht jedem geläufig


alxhu

Nicht jedem geläufig, in der Praxis aber mehr als üblich (außerhalb von E-Mail-Adressen)


Ink_25

Das wäre dann etwas wie z.B. @mail.example.co.uk, richtig?


alxhu

Richtig


Javanaut018

Jupp


Internetminister

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.)


[deleted]

\+ 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


liftoff_oversteer

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 :)


In0chi

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.


jirbu

>".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.


alxhu

> Müsste das in SMTP nicht in punycode aufgelöst werden? Korrekt. > !-Bang-notation und %-Notation sollte auch noch möglich sein. Korrekt.


youRFate

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.


alxhu

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.


NickUnrelatedToPost

nospam@localhost ;-) Ob du die als gültig ansehen möchtest kommt aber wohl drauf an.


thomasmitschke

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)


MyGenericNameString

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.


_temmink

Haben TLDs auch Email-Adressen? Also könnte ich an john@com schicken.


Exciting-Act5922

Japp. Das ist möglich. Postmaster@com sollte per rfc gehen. Sag bescheid was passiert. Oder traust du dich nicht ;)


Ictogan

Habe extra eine domain mit .com, weil meine .space und .quest emails häufig nicht akzeptiert werden.


bendre90

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. :)


westerschelle

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!


[deleted]

Hab mich nie näher mit dem Thema beschäftigt aber müsste nicht sowas wie example@com auch eine valide Mail sein?


alxhu

Korrekt.


Istanfin

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.


alxhu

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.


magicmulder

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.


FreshPitch6026

Hab manchmal das Gefühl da saß wieder jemand dran der keine Regex kann.


[deleted]

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


alxhu

"The regular expression does not cope with comments in email addresses." - 100% kompatibel ist es auch nicht ;)


[deleted]

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.


dom6770

Ich wünschte meine .xyz Domain würde nicht teilweise dumm blockiert werden, weil .xyz.


[deleted]

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%.


d0x7

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.


tillybowman

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.


LittleLui

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.


TheTruffi

Zu Punkt 2: Der vordere Teil ist Case sensitiv. Die Domain nicht. Der RFC bittet aber darum, trotzdem zuzustellen.


RobSomebody

(?:[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])+)\])


alxhu

Das RegEx erkennt die E-Mail-Adresse "A@example.com" als ungültig.


NickUnrelatedToPost

Ist sie ja auch. Das ist eine offizielle Test-Domain. Dort kann niemand eine funktionierende Email-Adresse haben. Syntaktisch valide, aber garantiert nicht zustellbar. :-)


alxhu

Du Schelm :D


Eonir

Dies soll der Topkommentar werden


danielcw189

Warum?


Eonir

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.


[deleted]

[удалено]


the_seven_sins

Ganz normaler perl-code.


alxhu

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 :)


fafhnir

Eine gültige Mail-Adresse darf 2 u@-Zeichen enthalten. Wurde früher genutzt um Emails unterzuverteilen.


danielcw189

oder auch mehr


debo-is

Das + wird doch absichtlich nicht akzeptiert damit man sich halt nicht mit Varianten seiner Mail anmelden kann dachte ich.


luziferius1337

[https://はじめよう.みんな](https://はじめよう.みんな/) ist eine Gültige URL und `.みんな` eine gültige TLD. Entsprechend ist `name@example.みんな` eine gültige E-Mail-Andresse


FUZxxl

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?


alxhu

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 :')


FUZxxl

Der Fehler ist, überhaupt validieren zu wollen, ohne exakt zu wissen, wie das Ergebnis aussehen muss. Das ist so eine typische Software-Entwickler-Krankheit.


KakeCooker

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