Poslední příspěvky
A co clojure?
Jeden z častých DKIM problémů v praxi představují maily s řádky delšími než limit 998 znaků. Často produkované nějakými html generátory. Obvyklá dvojice Postfix+OpenDKIM nedokáže s tímto prohřeškem pracovat (třeba řádek násilím zlomit). Jiným problémem může být zásah do MIME mailů v podobě změny kódování obsahu někde po cestě. A není to tak dlouho, co jsem se potýkal se zásahy MS Exchange do záhlaví jednotlivých částí MIME mailů při jejich lokálním doručování a přeposílání prostřednictvím uživatelských pravidel.Takže jsou to různé chyby implementace, ne přímo problémy DKIM. Ale chápu, že bez použití DKIM se ty chyby neprojeví, takže je to jeden z problémů, na které člověk narazí, když DKIM začne používat. Asi by se to dalo obejít tím, že se pro hashování těla e-mailu bude používat jenom jeho začátek.
Samostatnou kapitolou pak jsou mailing listy. Například chcete na listserveru do Subjectu přidávat jméno listu, na konec mailu přidat patičku listserveru a chcete z mailu odfiltrovat nežádoucí MIME části. Tím vším porušíte původní DKIM podpis. A nový DKIM podpis přidat nemůžete kvůli nesouladu jména domény původního odesilatele a podepisujícího serveru.To, že mailinglisty do e-mailu zasahují, je podle mne špatně, odjakživa. Díky DKIM je to akorát víc vidět. Už dříve to rozbíjelo elektronicky podepsané e-maily. Vkládat patičku do HTML e-mailů také způsobuje problémy… Kvůli předávání těchto informací máme v RFC 4021 definované hlavičky List-*, případně další hlavičky v RFC 8058.
Jeden z častých DKIM problémů v praxi představují maily s řádky delšími než limit 998 znaků. Často produkované nějakými html generátory. Obvyklá dvojice Postfix+OpenDKIM nedokáže s tímto prohřeškem pracovat (třeba řádek násilím zlomit). Jiným problémem může být zásah do MIME mailů v podobě změny kódování obsahu někde po cestě. A není to tak dlouho, co jsem se potýkal se zásahy MS Exchange do záhlaví jednotlivých částí MIME mailů při jejich lokálním doručování a přeposílání prostřednictvím uživatelských pravidel.S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.Jaké nedostatky má DKIM? ...
Ano, moje trapná chyba a omluva čtenářům. Mozek už usínal, a z posledních sil si vzpomněl na dmarc tag fo=, který ale slouží k něčemu jinému.Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM.Ona to ani vyžadovat nemůže.
A presne tohle neni pravda. Urad te nemuze jako fyzickou osobu ovcana kontaktovat pres DS podnikatele, ale naopak to akceptovat je povinen.Ne, v opačném případě (podání úřadu z chybné DS) k tomu úřad musí přistupovat jako k podání s vadou a ověřit, kdo to doopravdy podal. Někdy to může udělat sám, někdy musí toho, kdo měl podání podat, vyzvat, aby podání potvrdil.
Pokud je osvc zaroven platcem DPH tak je jeho RC zaroven DICNení, DIČ je „CZ“ plus rodné číslo.
coz je mimochodem uz drahne let ilegalniNesmysl, není to ilegální.
protoze prohlasit, ze se dicem stava cz+ic (stejne jako u vsech firem) ... je nad schopnosti byrokratu.Vůbec nejde o schopnosti byrokratů, ale o to, jak tu změnu technicky provést. DIČ se používá na spoustě míst a tím, že prohlásíte, že DIČ je něco jiného, se to všude zázrakem samo nepřepíše. Navíc DIČ je platné mezinárodně – nevím, zda se v mezinárodním styku vůbec počítá s tím, že se DIČ může změnit.
Úkony konat můžeš, ale druhá strana je nemusí akceptovat, protože vystupuješ v roli PFO a nikoliv v roli FO, ...A presne tohle neni pravda. Urad te nemuze jako fyzickou osobu ovcana kontaktovat pres DS podnikatele, ale naopak to akceptovat je povinen.
Ale stát to samozřejmě vůbec neulehčuje tím, že DIČ je u PFO ve formátu "CZ<RČ>", což je jednak naprosto matoucí a jednak demence na druhou, protože jako OSVČ vytrubujete svoje RČ úplně všem.Pokud je osvc zaroven platcem DPH tak je jeho RC zaroven DIC, ktere musi uvadet na fakturach, coz je mimochodem uz drahne let ilegalni, ale stat stim dlouhodobe nic nedela, protoze prohlasit, ze se dicem stava cz+ic (stejne jako u vsech firem) ... je nad schopnosti byrokratu.
Ještě poznámku.Pripadne tomu statu v mnoha pripadech staci, kdyz dostane papir, na tom papriu jsou kdovi ci nacionale ...a nejaka cmaranice, ktere se rika podpis ... a nijak se nic neoveruje. To plati zejmena pro vsechna hlaseni prave treba OSVC.
Když se odesílá elektronické hlášení o nějaké dani - například DPH, tak je třeba nějakým způsobem ověřit, že to odesílá ten správný subjekt. A když to odesílá OSVČ, tak to ověření může provést asi "miliónem" způsobů, které všechny fungují, ale jenom ten jeden, datová schránka PFO, souvisí s tím "podnikáním". Takové MojeID nebo soukromé bankovní identity o tom vůbec nic netuší, ale přesto to státu stačí, aby se "hmotná" fyzická osoba identifikovala i jako "nehmotná" podnikající fyzická osoba.
Mě by třeba, ať zůstaneme v kontextu komunikace s OSPOD, docela zajímalo co se bude dít, když třeba v nějakém úředním řízení, řekněme třeba při sporu o dítě, budu se soudem komunikovat z DS PFO. Protože těžko moje živnost bude mít rodičovská práva.Nebude se dit vubec nic, viz vejs. Tvoje komunikace smerem ke statu muze byt vedena jak z DS ovcana tak z DS podnikatele. Neplati to jen opacne, tzn pokud te ourad k necemu vyziva, musi to dorucit do spravne DS.
SPF kontrola nepracuje s hlavičkou From:, ale s adresou mail sender.Samotné SPF ano. Ale dnes se SPF používá jako součást DMARC, kdy doména validovaná přes SPF nebo DKIM vstupuje do validace adresy From e-mailu – DMARC Alignment kontroluje, zda doména ve From odpovídá doméně SPF nebo DKIM.
Můžete narazit i na názor, že při přeposílání má přeposílající převzít za tento mail odpovědnost tak, že adresu mail sender změní na svoji vlastní. (A adresu From: ponechá beze změny.) To je také možné řešení.K tomu také slouží SRS. Přepisovat obálkového odesílatele je správně, špatně je naopak to, že se na to dříve kašlalo. Obálkový odesílatel je ten, kdo je odpovědný za doručení daného e-mailu a komu se tedy musí vracet případné chyby.
S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.Jaké nedostatky má DKIM? Pokud někdo nepřepisuje hlavičku v e-mailu, které přepisovat nemá, tak DKIM podporuje z principu všechny možné scénáře použití e-mailu.
Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM.Ona to ani vyžadovat nemůže. Jediný problém nastává, pokud někdo používá jenom SPF.
Chcete-li plnit DMARC zcela důsledně, tak dojdete k závěru, že adresy From:, mail sender a doménové jméno z DKIM podpisu musejí být prakticky stejné, resp. ve vzájemném souladu/alignmentu.Pro důsledné plnění DMARC stačí používat DKIM.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2025 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.