Názory k článku
Víte, jak vypadá e-mailová adresa? Zkuste si malý test

13, ale jako ... brát za validní adresy takový, který na spoustě míst tak jako tak neprojdou - podle mě znamená, že praxe se dost liší od teorie.

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

Není to tak dlouho, kdy mi Vodafone ve své samoobsluze odmítal e-mailovou adresu jen proto, že doména byla čtyřznaková a maximum jsou prý tři znaky! Uff. Už to opravili, ale trvalo to asi rok.

adresa na domene .info od roku 2003 a este minuly rok som komusi pisal ze haloooo?

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.

Validace nad potrebny ramec . To znam. Moje mama se narodila 1.1. Nekolikkrat jsem narazil ze ji sluzba odmitlna registrovat protoze neni spravne vyplneny datum.

Ú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…

Zrovna seynam.cz je existujici domena vc. existujiciho MTA. Podle jakeho klice budete losovat domeny, kdy uzivatele budete buzerovat na validitu domeny a kdy ne? ;-) Ten algoritmus chci videt.

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.

Zase na druhou stranu - kdo soudný by chtěl emailovou adresu na sto a více znaků, a taky - došlo z podivných domén jako .fun nebo .moscow něco jiného než spam?
Každou chvíli přichází spammeři s podobnou podivnou doménou.

Ono je to s tema dlouhyma TLD tezke, treba v ramci ceskeho basketbalu se pouzivaji maily @cz.basketball, tedy urcite existuji "podivne" nespamujici / legitimni domeny.

Tedy dostat něco z adresy "cz.basketball", splní to dokonale marketingový účel protože se vzápětí půjdu podívat, co je na takové doméně za hustohustou site.

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

.Shop, .online jsou docela pouzivane "nove" domeny, na kterych je rada legitimniho obsahu.

Tady by to asi chtelo aby existovali nizkourovnove funkce ktere overi jestli je string email. Idelane aby meli volitelny parametr jak moc chci akceptovat ty kurdlinky co jsou v tom testu. Abychom nepouzivali ruzne scripty a regex.
Mysli ze PHP nic zabudovaneho nema.

filter_var($email, FILTER_VALIDA­TE_EMAIL))

Ale ano, validuje to platnost e-mailu, ne subsetu

Tak napsat neco takoveho, co rozlozi emailovou adresu do casti (name, user, tag, comment, domain) a pak to validovat vuci zakladnim constraintum + vasim preferencim zas tak tezke neni, ne?

Ve skutečnosti to docela těžké je. Tedy pokud chcete opravdu validovat ty obskurnosti, které standard povoluje.

Coz lini programatori obchazi prave tim, ze zacnou validni formaty odmitat, protoze je pro ty chudinky tezky to napsat poradne :-)

Já mám teda spíš pocit, že pro některé chudinky bylo těžké napsat pořádně RFC. Fakt nechápu některé ujetosti, které RFC povoluje, a jsem rád za to, že to neprojde přes MTA a díky tomu jsou emaily aspoň trochu přehledné

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

Jeste vtipnejsi je tady detail, ze programatori tvorici kod pro erar (verejny sektor) se s oblibou vymlouvaji na nepresne zadani, kdyz vysledkem jejich prace je nejaky paskvil. Ale kdyz maji na stole exaktni RFC, tak vymysli kybl vymluv... proc to podle nej neudelat :-)

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

Kdysi jsem byl na nějaké přednášce o adresách (a nejen mailových) a od té doby si říkám, že veškeré validace regexy jsou úplně mimo možnou realitu a nebo musí být tak složité, že se v nich nemá šanci nikdo soudný vyznat.

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.

Nějaký veřejný server možná. Ale internet se opravdu neskládá jenom z veřejných poskytovatelů mailboxů.

A tak ano, na svem mailserveru si muzu vytvorit cokoliv. Problem je, ze pak nastoupi programator nejake aplikace, co se o sve libovuli a typicky i na zaklade neznalosti usnese, ze muj standartum vyhovujici email je z nejakeho ne zcela jasneho duvodu pro nej neakceptovatelny.

No - a zkuste odhadnout, kolik e-mailových adres je na veřejných serverech a kolik na vlastních.

Pohořel jsem s 8 body :-(

To byl dobrý test. Budu rád za další podobné

tady máš něco s javascriptem: https://jsdate.wtf/

Musím uznat, že jsem si kdysi horké chvilky v javascriptu při práci s datumy užil a teď už vím proč... 8/28 :(

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.

Když máš za zavináčem hovínko tak to není nezmyslný case? :P Oboje to vyjde nastejno, jak mail, tak javascript, jen ty si ten JS asi bereš moc osobně, protože se tím živíš :)

8. 9. 2025, 10:07 editováno autorem komentáře

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?

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

17 - 21 bych asi nedal ... ale 90% z toho co tram uvadeji by bezny webmail nedovolil vubec zadat ;-) , zbytek by zahodil spam filter - a s kde cim by neumel delat treba exchange ;-) ale i jine nastroje