Vyšlo na www.root.cz, 3.12.2009
Vytištěno z adresy: http://www.earchiv.cz/b09/b1203001.php3

Datové schránky (zatím) nemailují.

Nechcete-li kontrolovat svou datovou schránku každý den, můžete si nechat posílat emailem avizo při příchodu nové zprávy. Pokud vám přijde, pak z adresy notifikace@mojedatovaschranka.cz. Jenže ta neexistuje, stejně jako neexistuje žádný jiný funkční email v doméně mojedatovaschranka.cz. A to je docela problém, kvůli kterému se notifikační zprávy nemusí dostat ke svému cíli.

Jednou ze služeb informačního systému datových schránek (ISDS) je i zasílání emailových avíz při příchodu každé nové zprávy. Je to služba sice negarantovaná, již jen kvůli samotné podstatě fungování dnešní internetové pošty, ale na druhé straně je poskytována zdarma (na rozdíl od SMSkové notifikace, kde vás jedna SMSka přijde na 3 Kč). Tak proč tuto možnost nevyužívat.

Jenže je zde malý háček: ona mailová avíza chodí z adresy notifikace@mojedatovaschranka.cz, stejně jako potvrzení případných změn v nastavení vaší datové schránky, viz obrázek. 

Někteří uživatelé ale už zjistili, že jim takováto avíza nechodí, ač by měla. A když pátrali po tom, proč se tak děje, narazili na zajímavý problém: emailová adresa „notifikace@mojedatovaschranka.cz” neexistuje. Syntakticky je sice správná (správně utvořená), ale není platná – v tom smyslu, že na ni nelze nic doručit.

 A právě to je může být důvodem, proč některé emailové (SMTP) servery takovéto zprávy zahazují, ač na ně příjemci toužebně čekají.

Jak je to s poštou v doméně mojedatovaschranka.cz?

Naše pátrání po příčinách tohoto stavu můžeme začít u způsobu, jakým je řešeno doručování pošty v samotné doméně mojedatovaschranka.cz.

Jelikož jde o dosti „exponovanou“ doménu, dá se očekávat, že její poštovní servery (SMTP servery) budou umístěny někde úplně jinde, než na strojích, kde běží samotný informační systém datových schránek. Podívejme se tedy do MX záznamů domény mojedatovaschranka.cz, kam vedou.

Pro ty, kteří MX (Mail eXchanger) záznamy neznají, malé vysvětlení: tyto záznamy říkají, které stroje fungují jako poštovní servery pro příjem pošty pro danou doménu. Například pro doménu root.cz jde o stroj stana.iinfo.cz. Tedy „v úplně jiné doméně“, což není nijak nestandardní řešení. Ostatně, i pro doménu lupa.cz a další (ze stáje Internet Info) jde o stále stejný stroj a na něm běžící SMTP server.

Pokud se ale zeptáme na MX záznamy pro doménu mojedatovaschranka.cz, získáme docela překvapivou odpověď: tato doména žádné MX záznamy nastavené nemá!

To je dnes dosti neobvyklé, ale ještě to není chybou. Doména mojedatovaschranka.cz stále ještě může přijímat svou poštu na SMTP serveru, který běží na „implicitním“ stroji (tom, který je dán tzv. A záznamem této domény jako takové). Tedy právě na tom, který se „ozve“, když do svého browseru zadáme jen „mojedatovaschranka.cz“. Tedy stroj s IP adresou 90.182.205.177.

Stále je tedy možné vyhovět minimálnímu požadavku, který vyplývá již z RFC 822: aby v každé doméně byla funkční adresa správce pošty, zde konkrétně adresa postmaster@mojedatovaschranka.cz. Z hlediska bezpečnosti je to ale asi to nejhorší, co se dá udělat: zprovoznit poštovní server na stejném stroji, na kterém běží samotný WWW server.

Jenže: snadno zjistíme, že tomu tak není, a že na tomto stroji žádný poštovní server neběží. Jen WWW server, přijímající požadavky na portu 80 (pro klasické HTTP)  a 443 (pro zabezpečené HTTPS).

To ale má významné důsledky. Třeba ten, že do domény mojedatovaschranka.cz vlastně nejde doručit žádnou poštu. Tedy ani na tu jedinou povinnou adresu, kterou je postmaster@mojedatovaschranka.cz – což je nedodržením požadavků RFC 822.

Stejně tak to znamená, že nelze nic doručit ani na adresu notifikace@mojedatovaschranka.cz. Vlastně ani na žádnou jinou, která má „za zavináčem“ doménové jméno mojedatovaschranka.cz.

Co to znamená?

Podívejme se nyní, co naše zjištění znamená pro doručování v opačném směru. Tedy pro doručování zpráv, u kterých je neexistující (neplatná) adresa notifikace@mojedatovaschranka.cz uvedena jako adresa odesilatele.

Problém je v tom, že u správně sestavené zprávy (dle příslušných RFC) takováto adresa musí být platná (musí existovat a musí být možné na ni doručit). Většina SMTP serverů se nad to sice může povznést a zprávu přesto přenést – ale riskují tím nepříjemný problém. Pokud totiž zjistí, že ji z nějakého důvodu (tentokráte již na straně příjemce) nemohou doručit, pak o tom musí informovat odesilatele, v daném případě tedy na adresu notifikace@mojedatovaschranka.cz. Když se ale o to začnou pokoušet, zjistí, že se jim to nedaří -  a tak se o to pokouší znovu a znovu, plných 5 dnů, a teprve pak mají právo to vzdát.

Právě kvůli tomu, aby se takovémuto plýtvání zdroji (a zbytečnému zaměstnávání SMTP serverů) zabránilo, existuje požadavek na platnou adresu odesilatele. To, zda adresa odesilatele skutečně platná je, mohou zjišťovat i antispamové filtry, a zprávy bez platné adresy odesilatele zahazovat již v rámci svého boje proti spammingu.

Pro přesnost si ještě dodejme, že adresa odesilatele (v položce From v hlavičce emailu) nemusí bezpodmínečně být tou, na kterou se odesílá zpráva  o problémech s doručením. Striktně vzato je to až adresa odesilatele z SMTP obálky, použitá v dialogu mezi odesílajícíma přijímajícím serverem v příkazu Mail From. Existují přitom určité možnosti, jak obě adresy nastavit odlišně, čehož se využívá například v různých emailových konferencích a distribučních mechanismech. Dříve se dala také využít položka Errors-to v hlavičce emailu, ale ta už by se dnes neměla používat.

Podstatné ale je, že notifikační emaily, odesílané informačním systémem datových schránek, žádné takovéto opatření nevyužívají – a tak se jako adresa pro zasílání eventuelních zpráv o problémech s doručením automaticky použije právě adresa notifikace@mojedatovaschranka.cz. Jenže jak už víme, na tu není možné nic doručit.

A právě to způsobuje výše popisované problémy s (ne)doručováním emailových notifikací.

Chyba, nebo záměr?

Položme si nyní důležitou otázku: jde o technickou chybu, na kterou provozovatele datových schránek ještě nikdo neupozornil? A sami si jí také ještě nevšimli?

Bohužel nikoli. Technická podpora ISDS na popisované skutečnosti již byla upozorněna – ale její reakce, kterou v nedávných dnech rozesílala protestujícím uživatelům, se nesla v opačném duchu: nejde o chybu, ale o záměr.

Dobrý den,
adresa"notifikace@mojedatovaschranka.cz"  JE validní SMTP adresa. SFP JE nastaveno.
Jediné, co je na diskusi: zda existuje nějaký důvod vyžadovat existenci MX/A záznamu, kde bude poslouchat SMTP server pro navracení mailů.
Tento požadavek je logický, odůvodnitelný jako jedna z obran proti SPAMu, ale NENÍ (prosíme o vyvrácení - citací příslušného RFC) dle RFC.
Je tedy jen volbou zákazníka, že od nás maily nepřebírají (ať již na základě tohoto požadavku na přijímající MX, nebo třeba proto, že jsme v nějakém blacklistu, či na základě jiného více či méně iracionálního důvodu). Právo na to nastavit si SVÉ MX podle svého uvážení mají.
Tedy lidé zodpovědní za infrastrukturu v dané oblasti se nedomnívají, že by chyba byla na naší straně. Pokud s tím nesouhlasíte, prosím o konkrétní citaci z RFC, která říká, že musí existovat aktivní mailserver a přijímat maily pro danou adresu.
SMTP server pro incoming spojení není v současné době nasazen zcela cíleně - neexistuje žádný důvod k příjmu mailů do domény @mojedatovaschranka.cz a jakákoli nadbytečná aplikace vystavená do internetu jen zvyšuje bezpečnostní rizika.
Na nejbližší projektové schůzce bude předán směrem k Ministerstvu Vnitra dotaz, zda mailserver neotevřeme, ale v tento okamžik to nevidím jako pravděpodobné.

Teprve v úterý ráno mi od technické podpory přišla následující zpráva, která signalizuje, že již problém docenili a budou s ním něco dělat. I když to nějakou dobu ještě potrvá:

Po probrání s kolegy z infrastruktury jsme došli k tomu, že podobné nastavení mailserveru může mít více uživatelů a je tedy potřeba tento problém ošetřit. Proto žádáme MV o vytvoření MX záznamů pro danou doménu a jejich nasměrování na nějaký vhodný SMTP server nebo o povolení příchozího provozu na SMTP server ISDS. Předpokládáme, že odpověď bude kladná.
Nicméně vzhledem k tomu, že v tomto projektu musí každou infrastrukturní změnu schválit MV, Česká Pošta i TO2, rozhodně se nejedná o něco, co proběhne v horizontu jednotek dní.
V rámci nejbližších dní doporučujeme obejít problém přidáním domény mezi "důvěryhodné", pokud používaný server podobné nastavení má.

No, jen doufám že půjde o MX záznam a SMTP server na nějakém jiném stroji (a ne o variantu „povolení příchozího provozu na SMTP server ISDS“).

Problém s SMS notifikací

Když už jsem u problémů s avizováním příchodu datových zpráv do datové schránky, dovolím si upozornit na další problém, tentokráte u SMS notifikací.

Setkal jsem se s ním na vlastní kůži, když jsem si hned na začátku (po 1.7.2009) nechal tuto službu aktivovat  - ale žádná SMS notifikace mi nepřišla. Problém byl ale také na mé straně.

Schválně: když se podíváte na následující obrázek, jak byste mu rozuměli?

Já jsem mu porozuměl tak, že když nechci dostávat denní výpisy (tedy zřejmě každý den jednu SMS zprávu za 3 Kč), ale chci dostat SMSku při příchodu každé jednotlivé datové zprávy, musím zaškrtnout poslední, čtvrtou možnost.

Jenže právě to byla chyba, a kvůli tomu mi žádná SMSka nepřišla. Teprve mnohem později se v nastavení objevila malá vysvětlující noticka, která říká, že vše je vlastně úplně jinak, než jak jsem tomu rozuměl:

Takže: pokud nechcete dostávat denní výpisy, musíte nejprve říci, že je dostávat chcete, a vybrat si jaký. Teprve pak řeknete, že je vlastně dostávat nechcete, ale že místo toho chcete dostávat notifikaci pro každou jednotlivou datovou zprávu.

Inu, člověk se neustále učí. Na obou stranách barikády.