Inu proto, ze programatori aplikaci jsou lini, nectou moc specifikace (RFC) a strci tam nejaky jednoduchy test opreny o regular na zakladni veci obsahujici jen pismena, cisla a tecku, aby se nereklo. Pro mnohe je sproste slovo treba i IDN a k nalezeni jsou i omezeni na prostou delku, kdy je vynucovana delka adresy kratsi nez povoluji standardy (ala system 50 znaku vam musi stacit).
Bohužel na každém místě projde něco jiného a je spousta míst, kde neprojde ani adresa na doméně 3. řádu.
Protože mě takovéhle případy dost nas***jí, tak jsem kdysi hledal regex, který by to dokázal zvalidovat správně. Našel jsem jeden, co pokrýval téměř kompletně specifikaci, ale vypadal spíš jako zašifrovaná slohová práce než regex.
K čemu vůbec je dobrá takhle detailní validace e-mailové adresy? Spousta validních adres je stejně nedoručitelných.
Jako provozovatel služby, která z nějakého důvodu vyžaduje e-mailovou adresu, podle mě není prakticky velký rozdíl mezi validní nedoručitelnou adresou a nevalidní (a tudíž nedoručitelnou) adresou. Pokud tedy chci mít jistotu, že adresa je doručitelná, nezjistím to jinak než tím, že se na ní pokusím něco doručit. A v takovém případě ji prostě předám SMTP klientovi tak, jak ji uživatel zadal - žádná pokročilá validace není potřeba. Maximálně můžu ušetřit pár strojových cyklů odmítáním zjevně nevalidních adres, kde třeba chybí zavináč. Ale i tohle SMTP klient odchytí.
V praxi se stále používají i v nových projektech stále ty víc jak deset let staré scripty z doby před uvolněním trhu s gTLD doménami. Takže jestli tenhle zábavně-edukační projekt otevře oko třeba jen jednomu jedinému kodérovi, který se chytí za nos a pochopí, že svět se posunuje ikdyž se nekouká, je to dobře.
Pokud formular jen validuje vstup (aniz by realne testoval existenci mailboxu, coz je vetsina), nedava smysl vynucovat nejaka pravidla nad ramec toho, co rikaji standardy. On to byl jen tak mimochodem i pripad u RIPE, kdy se vyvojar rozhodl, ze 80-znakovy email musi stacit vsem. Umela podminka, co s (ne)dorucitelnosti emailu nic docineni nemela.
Úplně stačí mít nesprávně dlouhé jméno. Můj kamarád z krátkým jménem má příjmení Aš
(jako to město), a mnohokrát narazil na omezení minimální délka příjmení jsou 3 znaky
nebo jméno + příjmení musí být minimálně 5 znaků dlouhé
, a jednou dokonce došlo k záměně s doménou, když měl u uživatelské jméno ve tvaru ***.as.
Díváš se na to z pohledu technika, ne z pohledu uživatele. Uživatel může při zadávání e-mailové adresy udělat chybu, a pak je dobré jej na ni upozornit hned, aby ji mohl opravit. Zejména když často e-mailová adresa == účet, takže zadání chybné e-mailové adresy efektivně znamená, že jsi vytvořil účet, ke kterému se už v životě nedostaneš. Což zamrzí, když se ten účet vytváří třeba po dokončení objednávky a objednávka se do něj přesune.
Takže i když uživatel zadá e-mail ve tvaru @seynam.cz nebo @seynam.cy, je dobré se ho zeptat, zda je to opravdu správně – i když technicky jsou to správné e-maily, bez nějakých záludností.
Myslet si o tom můžu co chci, ale kolik chyb lidé udělají, když mají zadat svůj e-mail, telefonní číslo nebo jenom opsat čtyřmístný variabilní symbol…
To by nebyl Danny, aby nemusel oponovat, i když úplně hloupě. Jaký je asi poměr případů, kdy někdo zadá seynam.cz omylem a kdy někdo opravdu používá e-mail na dané doméně? 1 000:1? 10 000:1? Nejde o žádnou buzeraci, jde o pomoc uživatelům.
Pokud by někdo náhodou měl e-mail na téhle doméně, znamená to jedno kliknutí navíc. Opravdu je to nepřekonatelný problém? Navíc u domény, u které jde jen stěží předpokládat dobré úmysly vlastníka? Vážně tě nenapadlo, že tam ten MTA s největší pravděpodobností běží právě proto, aby přijímal e-maily určené úplně někomu jinému a těžil z nich informace? Třeba jen o pravděpodobně existujících adresách?
První verze algoritmu je jednoduchá – stačí mít trochu přehled o českém internetu a zamyslet se. Pokročilejší verze algoritmu je sledovat e-mailové adresy, na které se nedaří doručovat. Což neznamená jenom to, že není kam doručit nebo MTA e-mail odmítne. Může to znamenat i to, že nepřijde žádná reakce na e-mail.
A razite tyhle teze aspon u sveho zamestnavatele? Ze by jako formulariky vyzadujici zadani vstup provadely testy na zaklade tehle vasi teorie? :-) Nebo zas jen blouznite a modelujete neco, co ani u vas nedelate...? :-)
Cesky internet fakt nejsou jen emaily s koncovkou .cz. Ostatne i vase firemni prezentace chce byt svetova a preferuje .com pred .cz, zeano. Muzete prijit s tezi, ze to neni vase prace... ale ano, pak plati to ad vyse, ze vas vliv je zanedbatelny a tudiz vase napady nikdo nebere vazne.
Nevím co myslíte tím "podivné" domény. Jsou to normální TLDčka. Já mám třeba .xyz, protože moje jméno bylo v .cz zabrané a xyz se mi všeobecně líbí. Někomu se třeba líbí Moskva, nebo má rád legraci :-)
Moscow si třeba umím dost dobře představit u agentury pořádající zájezdy do moskvy, fun pak třeba u aquaparků a různých atrakcí.
Neni nic jednodussiho, nez prijit na IETF a zmenit to. Samozrejme to znamena svou tezi o ujetosti obhajit pred sirsim plenem - ale myslim si, ze to nedate :-) Spouta veci muze mit svuj duvod, byt ho sami treba i nechapeme nebo pro nej sami vyuziti nemame.
Pres standardni MTA to vetsinou bez obtizi prochazi, protoze tvurci tohoto leta vyvijeneho software nemaji pocit, ze jsou papeztejsi - no a do teto skupiny "papezu" si muzeme dosadit nektere dominantni hrace na trhu z rad velkych korporaci (ktere vyuzivaji svou silu k tomu, aby standardy ignorovali), pripadne frikulini co maji potrebu si psat vlastni implementace s tim, ze to je prece "jednoduchy". Dalsi problem jsou tvurci ruznych webovych aplikaci, formulariku atd... kteri do toho skocili systemem prece si nebudu komplikovat zivot .
Ve finale se bavime o retezci. Cela kontrola vstupu je o tom, ze se povoli jasne definovany format. A ne, ze se u te kontroly necha projit jen neco, co je snadne co se implementace tyce. Pokud je vyvojar natolik liny, ze to delat nechce... at jde delat neco jineho.
Jestli je pro vas nebo kohokoliv jineho na tomto ukolu neco tezke, tak by jste se nemeli venovat IT.
Existuje sada X RFC ktere vam zcela jednoznacne napovi jak takova funkce bude vypadat. Staci zapojit mozek (a uvazovat strojove).
A jak jsem naznacil pokud je snaha se omezit na podmnozinu standardu - muzete tomu hintnout ktere feature chcete aby neprosli, muzete si urcit dalsi argumenty jako casovy kontext - aby to bralo do uvahy jen RFC vznikle pred tim datem, a muzete nakonec taky provest validaci dorucitelnosti - at uz jen existenci domeny nebo existenci uctu. Pak uzivatel muze dostat docela jasny a vymluvny validacni vysledek - co je na jeho vstupu spatne, nebo jake politice nevoni (stalo se mi napr. - zadejte firemni email.. a bylo to odmitnuto pokud domena byla jedna z beznych freemailu.. neberu to jako spatny, kdyz me to rekne chybu jasne a vystizne).
Problem muze byt pouze adekvatne slozity - po veskerem historickem vyvoji se tomu ani nedivim, ale nikdy bych tento ukol neoznacil jako "Ve skutečnosti to docela těžké" (jako pocitove - nemozne).
Nevim jak vy, ale ja mam na svem kontu i nekolik patchu akceptovanych v linuxovem kernelu. A to se za vyvojare neprohlasuju. Vyvojar by mel dodrzovat specifikaci... a potazmo implementovat standardy, tak jak jsou definovane. Ale spousta vyvojaru jsou ve skutecnosti egoisti, co si mysli ze vecem rozumi lepe, nez tvurci specifikaci.
Na to existuje jednoducha odpoved - clovek ma delat praci, kterou povazuje za smysluplnou. Pokud nekomu nevadi, ze rychle vyviji... ehm... zmetky, je to ciste jeho volba. A nebo proste na vic, nez na ty zmetky nema. Coz je ostatne videt mj. na tom, co produkuji "vyvojari" z nejlidnatejsi zeme sveta. Ale ono i s hornikem z OKD narychlo preucenym na programatora muze byt kopec zabavy, zejo :-) Chapu, on je rad ze svou praci ma... ale vysledkem toho, ze se podobny styl dlouhodobe toleruje vede akorat k tomu, ze se ridime do stavu, ktery bude stale hur udrzitelny pri zivote - zvlast pokud vas (nastupujici) regulace donuti nest take odpovednost. Srouby se utahuji, zeano :-)
No, minimálně tam, kde funguju já, jsou vývojáři z nemalé části lepiči řešení z různých frameworků. Co kolikrát vídám v databázi za selecty (poté, co přijde obligátní problém "je to pomalé a určitě za to může DBA"), to jsou exekuční plány na nízké desítky pagedownů, že se v tom nemůže vyznat ani plastová chytrystika. Ale já jim to nezávidim, jejich práci bych nechtěl dělat.
6. 9. 2025, 10:48 editováno autorem komentáře
Ne, ze bych tomu rozumel, ostatne mam jen 15 bodu, ale mam dojem, ze tam zdaleka nebylo vsechno. Treba adresy s vice zavinaci, ty mam dojem, ze byly mozne.
Nektere ty priklady jsou ale vazne povedene.
Tak ono by bylo lepsi kdyby existoval nekde prehled featur, s odkazama na RFC+odstavec, a pak prehledova tabulka podporovanosti.
Neco, co kdysi delalo W3C velice detailne - per feature, per browser. Ale jak je dnes verze co tyden tak to je takovy.. meh. Urcite by to slo zjednodusit (treba s poznamkou jako... >= odVerze ).
Ano, regexp na validaci e-mailové adresy podle standardu (nebo takový, který se tomu alespoň blíží), je writeonly – ponoříte se do standardu, ten regexp napíšete, a pak už ho v životě nikdo neupraví ani neopraví, protože není v lidských silách přijít na to, která část regexpu odpovídá které části standardu.
Např. Perl podporoval komentáře, které mohly být součástí regexpu – ale pochybuju, že by to nějak výrazně pomohlo.
:) a to som si myslel, ze to ovladam perfektne... I scored 15/21 on https://e-mail.wtf and all I got was this lousy text to share on social media.
V praxi je spousta adres sice validních, ale nevytvořitelných, protože ten e-mail server prostě odmítne takový mailbox vůbec založit.
Čili složitá validace podle normy
v podstatě nestačí. Na druhou stranu: ani samotný pokus poslat zprávu na uvedený e-mail není dostatečnou kontrolou.
Mimochodem, zkuste si některé z těch kvízových e-mailů - upravený pro oblíbenou e-mailovou službu - prostě poslat. Může tam být tisíckrát napsáno, že jde o platnou variantu, přesto se vrátí odpověď ve stylu: The recipient address <---@---> is not a valid RFC,553-5.1.3 5321 address.
Ja len nechápem kto by vôbec prečo skúšal volať `new Date` s takýmito argumentami ako "maybe 1"... p.s. dal som 18 score, a to si hovorím že JS viem v podstate na 99.9% z pohľadu API a syntaxe... no ale vidím "new Date("maybe 1")` skutočne neviem čo vracia, teda teraz už viem, ale koho to vôbec napadlo? Proč?
Tu však než nadávať na štandard JS, ktorý pokrýva takto nezmyselné casy, ktoré aj tak nie sú používané, si myslím že prípad s emailom je horší, lebo ten je skutočne používaný. Preto RFC pre maily je fakt o dosť horšia vec, a vidieť to v reálnom svete, kde aplikácie ti nedovolia vložiť valídny mail, alebo naopak.
No, ono hovinko za zavinacem nemusi byt az tak nerealne... 11 TLD vam to dokonce povoli... :-)
Ako absurdita nie je to že 99% webov nesprávne parsuje e-maily, ale to že RFC pre e-mail je takto nezmyselne komplikovaný. Až tak extrémne zbytočne komplikvoaný že ani nedáva zmysel reálne aby weby všetky maily parsovali správne, keďže to nie je len zbytočne vyhodený výkon a veľkosť kódu, effort atď, na to aby sme pohandlovali správne absolútne nezmyselné mailové adresy.
Nedávno som videl niekoho validovať mail štýlom `mail.includes("@")` a myslím si že to nie je špatné, samozrejme používateľ bude môcť zadať mail, ktorý reálne nemôže existovať, takže aj tak ten mail sa nedoručí, ale zároveň je kopec mailov, čo sú skutočné a mnohé weby zbytočne nepovolia.
Tak či tak, toto je hlavne katastrofálne RFC, nie softvérové riešenie v realite, kedy väčšina nie je podľa štandardov.
Argumentace vykonem je chucpe. Ty RFC jsou v zasade pomerne stare, takze jste se svym tvrzenim rozhodl dokonce popirat Mooruv zakon. Po vasem, argumentace vykonem je velmi hloupa vyhovorka.
RFC maji svou historii. Veci maji sve duvody. A soucasne plati, ze to nejsou staticke dokumenty - meni se, umi ledacos reflektovat - pokud se najde konsensus. Navic zrovna tady nekdy proste staci nevynalezat kolo... a vzit neco, co uz nekdo jiny za vas vymyslel.
Katastrofa jsou hlavne dnesni snehove vlocky, co si na jedne strane umele vymysli striktni validaci co nejblize zdroji... a pak breci, ze je slozite ji implementovat :-) Ve finale staci vyresit aplikacni workflow... treba tak, ze nejdriv overite dorucitelnost emailu (ktera se beztak casto resi) a teprve pak povolite dalsi kroky. Neni nutne uz na urovni formulare pro zadani emailu sofistikovane premyslet nad tim, jestli je email dorucitelny... nechte tu praci MSA/MTA a pracujte s negativni odpovedi. Presne v duchu unixove filosofie... keep it simple, stupid.
Tento sposb nieje simple. Overovat email nieje simple.
Zalezi na pripade/konkretnej sluzbe a podla toho pouzit adekvatny sposob.
Ja som sa s tym nestretol aby to tak niekto robil napriklad pri e-shopoch a jednorazvoych objednavkach.
Na jednom fore som sa stretol s overovanim existenie domeny pri prridavani anonymneho prispevku bez registracie.
Rovnako email nieje garantovana sluzba.
Uz som zazil viackrat, ze napriklad pri pouzivani potvrdzovacieho emailu pri registracii niekam mi ten email neprisel a nevedel som sa pohnut dalej.
NIkde zase bolo mozne vytvorit ucet aj bez okamziteho overenia emailu cez potvrdzovaci email ale musel si to urobit do niekolkych dni.
Email je negarantovana sluzba, ale nejake urovne odpovednosti tam jsou. Aneb pokud se MTA email dorucit nepodari, jiste o tom vi - a umi o tom dat vedet... ale ze by s osetrenim techto stavu vyvojari webovych aplikaci vubec ztraceli cas se moc rict neda, zejo. Aneb ta blackohle casto nevznika na urovni samotneho emailu, ale az v tech aplikacich - co se neobtezuji zpracovavat zpravy o nedoruceni.
A ti tvurci tech webovych aplikaci se sice nezabyvaji tim, zda je zadany email opravdu dorucitelny ci alespon existujici - zato implementuji ruzne obskurdni podminky, co provadi faktickou offline radoby-validaci vstupu. Kdy ale soucasne nedokazou napsat validator syntaxe, co by respektoval standardy. Realita je takova, ze ten vstup muze na prvni pohled obsahovat spoustu podivnosti - a presto muze jit o legitimni emailovou adresu. A pokud to programator neumi napsat poradne, mel by se spis na podobne veci vykaslat a necpat do provozu polovicate paskvily.
Jsi dobrej teoretik, ale praxe je jinde.
Kdyby programátoři měli číst (nebo dokonce znát zpaměti) RFC, tak se nikdy nic nenapíše.
Buďme rádi, že se věci zjednodušují tak, aby fungovaly pro 99,99% případů.
Pěkný příklad z našich luhů a hájů: řešil jsi někdy do detailu rodná čísla? Viděl jsem prasárnu, kde se to bralo jako string bez validace, bez ohledu na délku, v konečném ohledu to ničemu nevadilo.
Pokud se ale rodné číslo bude řešit doopravdy tak, jak se vyskytuje, tak:
- neplatí modulo 11 (pro nově vystavená rodná čísla už platí vždy)
- nemusí být unikátní (v minulosti se párkrát vydalo shodné rodné číslo různým osobám)
Ruku na srdce, kolik z vás při implementaci rodných čísel toto bralo v potaz?
Praxe je s nicim se nes*at a hlavne to mit rychle hotove :-) A pak hodiny prokrastinovat na internetu.
Ze snaha pouzivat rodne cisla jako unikatni identifikator se vi. Taky se z mnoha agend realne odstranuje coby nadbytecny udaj. Ale i zakon existenci duplicit fakticky priznava uz od roku 2004. Takze uz pres 20 let, pokud nekdo s timto nepocita, pak dela neco spatne...
Jen jste uvedl dalsi priklad toho, ze pred implementaci cehokoliv je zadouci se seznamit s tim, jak vstup doopravdy funguje.
17/21. Pohořel jsem na mezerách a tečkách.
Ale pár velkých hráčů (vč O2) pohořelo i na mojí velmi jednoduché a zcela validní adrese bez jakýchkoliv obskurností, která má přesně 8 znaků. Jeden před zavináčem a 6 za, včetně domény `.cz`. A svého času jsem velmi rád používal adresu `nick@[mo.je.i.p]`. Na tom si vylámal zuby kde kdo :)