Vlákno názorů k článku Novinky v datových schránkách: 10 dnů se může protáhnout, nové možnosti vystoupení z anonymity a nová úvodní stránka od Ditys - V případě použití běžného e-mailu v kombinaci s...
-
NJN, odpadl by problém s identifikací – a přibyl problém s garancí resp. prokazováním doručení. Neřešitelný. :-)
Nejsem fanda ISDS a stávající technické provedení, založené obskurní technologii od Software602, pokládám za velmi nešťastné, nicméně pro daný účel IMO jiné řešení, nežli samostatný a centrálně spravovaný systém, není reálné.
-
Aha, děkuji za rozšíření obzorů. :-) Jsa nucen pravidelně ze .ZFO soubory pracovat v aplikaci FormFiller, jsem opravdu vůči SW602 trochu zaujatý, nepopírám. Pokud jde o otevřený a standardní formát, existuje prosím nějaká alternativní aplikace, ve které lze s .ZFO formuláři pracovat?
(Omlouvám se za úkrok stranou od původně probíraného tématu, ale pokud bych nebyl nucen pracovat ve FormFilleru, jistě by to můj názor na SW602 potažmo ISDS radikálně zlepšilo. :-))
-
Je otazkou, jestli je rec o ZFO padajici z datovych schranek a nebo interaktivni formulare primo vytvorene pro FormFiller - to bych nezamenoval :-) K tomu druhemu take nekdo uz pred lety napsal opensource alternativu jako diplomku. Pro praci s datovymi schrankami tu pak je treba Datovka, ale tam podle me ty interaktivni formulare nefunguji (ale na zpracovani zprav z datovky to staci).
15. 6. 2022, 13:05 editováno autorem komentáře
-
Opravdu? Nestudoval jsem podrobně, pouze letmo prolétl odkázanou Wiki stránku, ale např. z poznámky „Communication between De-Mail and regular email addresses is not possible.“ usuzuji, že jde o samostatný systém, oddělený od běžné e-mailové infrastruktury (byť třeba využívající stejné standardy/protokoly).
-
Je to oddělené řešení. Nicméně není to jeden centrální systém – zapojit se může každý, kdo získá akreditaci (podobně jako třeba s kvalifikovanými certifikáty). Takže dnes jsou do toho zapojení 4 poskytovatelé, u 5. běží akreditace. Konkrétní poskytovatel klidně může pro své uživatele integrovat e-mail a De-Mail do jednoho klienta.
To, že není možné posílat mezi běžným e-mailem a De-Mail je logické – u De-Mail je právě ta garance doručení, kterou nelze u běžného e-mailu zajistit.
-
Za mne je otázka, zda vůbec potřebujeme to prokazatelné doručení, když pak stejně existuje fikce doručení. Nicméně pokud legislativa požaduje prokazatelné doručení, pak není možná implementace v rámci běžného e-mailového systému v tom smyslu, že byste mohl poslat e-mail na libovolnou e-mailovou adresu a měl byste potvrzené doručení. Šlo by to ale implementovat jako rozšíření e-mailu – kdybyste poslal e-mail na adresu, která garantované doručení podporuje, poštovní server adresáta by vám poslal zpět doručenku s pečetí. Ovšem podle mne by to pro uživatele bylo spíš matoucí, proč když pošlou e-mail na jednu adresu, mají to s doručenkou, a na jinou adresu ne.
Nicméně to, že datové schránky jsou monopolní, je jedna z jejich velmi špatných vlastností.
-
Fikce doručení funguje tak, že stačí vhodit do schránky lísteček, když jde náhodou kolem pošťák. Nebo vyvěsit oznámení na úřední desce úřadu nebo obecního úřadu. Takže na ni může doplatit i ten, kdo se nevyhýbá přebírání zásilek. Pokud dám bokem antispamové filtry, není na tom e-mail o nic hůř (zejména když nepotvrzený e-mail je možné znovu doručit prakticky zadarmo). A co se týče těch antispamových filtrů – neměl by být takový problém naučit je, že elektronicky podepsané e-maily z domén veřejné správy se nezahazují. (Kdyby státní správa používala doménu gov.cz, bylo by to ještě jednodušší.)
Potvrzení doručení ve smyslu RFC1891 je hlavně z pohledu zákona cár papíru. Aby to potvrzení dávalo nějaký smysl z pohledu zákona, musí tam být elektronická pečeť. A jinak nedobrovolné potvrzení doručení samozřejmě nemůže být založené jen na komunikaci dvou stran – vždy tam musí být nějaká neutrální důvěryhodná třetí strana, která prohlásí, že od teď už má adresát zprávu k dispozici a je jenom na něm, zda si ji přečte. (U papírových dopisů je tou důvěryhodnou třetí stranou ten pošťák, který vhodí lísteček do schránky, ze které lísteček druhou stranou vypadne a sežere ho pes.)
-
Pokud nekdo z vaznych duvodu skutecne nemohl papirovou zasilku prevzit, muze doruceni fikci zrusit. Takze zas tak "absolutni" ta fikce doruceni take neni.
Pozadavek na el.pecet u potvrzeni u doruceni je ptakovina, na kterou se - troufam si rict - vykasle majorita spravcu MTA. Ano, SMTP na podobne veci neni vubec vhodny protokol - X.400 byl v tomto smeru lepe navrzeny protokol, ale byl uz pro mnohe "moc slozity"... takze jsme zustali u hloupejsiho SMTP a krecovite do nej roubujeme aspon neco...
-
Opravdu? Tak ja vas odcituju...
Šlo by to ale implementovat jako rozšíření e-mailu – kdybyste poslal e-mail na adresu, která garantované doručení podporuje, poštovní server adresáta by vám poslal zpět doručenku s pečetí.
Co jineho, nez nejake (dalsi) rozsireni SMTP by to bylo? :P16. 6. 2022, 14:24 editováno autorem komentáře
-
Nebylo by to žádné rozšíření SMTP. Protože teprve v okamžiku doručení e-mailu do schránky adresáta (tedy daleko za hranicí SMTP) by se vygenerovala doručenka, která by se doručila odesílateli – možná jako běžný e-mail protokolem SMTP, ale v tom případě by to byl pro SMTP obyčejný e-mail jako každý jiný, takže by nebylo nutné žádné rozšíření.
Jinak samozřejmě platí, že pokud by někdo chtěl provozovat službu garantovaného doručení (lépe – přijetí) e-mailu, musel by implementovat něco, co teď implementované nemá. To je právě ten důvod, proč teď e-maily nezajišťují garantované doručení, proč vznikla potřeba nějakým způsobem garantované doručení řešit a proč vznikla debata, zda by bylo možné to řešit nad stávajícím e-mailovým systémem.
-
Tusim... takze se nasledne vubec nedivim, ze zakonodarce nezkousel krecovite priohnout email k ucelu, na ktery nebyl navrzen.
