Vlákno názorů k článku (Ne)bezpečný e-mail, aneb DKIM, DMARC, DANE a další nejen od D od Petr Macek - Chtel bych se zeptat ostatnich na tento letity...

Chtel bych se zeptat ostatnich na tento letity problem - preposilani mailu jinam a SPF. Pokud mate i DKIM a DMARC, tak by preposilani nemel byt problem. Staci aby vyhovel DKIM a zpravu by mel cilovy server prijmout.

Jenze obcas po ceste do toho mailu nejaky server sahne, pak nesedi ani DKIM a zprava se vraci. Nebo nekdo kontroluje jen SPF a jste zase v problemech.

Tech problemu ubyva, ale stejne se to jeste objevuje docela casto (resime postu pro desitky domen az nizsi stovky domen).

Dovecot to treba resi takto na urovni schranky
https://doc.dovecot.org/configuration_manual/sieve/configuring_auto_forward_sender_address/

nebo volbou sieve_redirec­t_envelope_from

Ja vim, ze to je slozitejsi... ale... i na preposilani reseni existuje...
https://en.wikipedia.org/wiki/Authenticated_Received_Chain

Přeposlání e-mailu není problém, pokud se udělá správně. E-mail uvedený v obálce zprávy je adresa toho, kdo za doručení zprávy zodpovídá, komu se mají reportovat případné chyby při doručování. Při přeposlání e-mailu tedy logicky v obálce přeposlaného e-mailu nemůže být původní odesílatel, ale e-mailová adresa ze serveru, který zprávu přeposílá – ten je za tu přeposlanou zprávu zodpovědný. No a tím pádem je SPF i DKIM v pořádku, protože jsou tam adresy toho přeposílajícího serveru.

Problém je, pokud příjemce špatně zachází s adresami a třeba se snaží porovnávat obálkového odesílatele a odesílatele uvedeného v e-mailu. Ale to už je zase jeho chyba.

Problém je v tom, jak přeposílání funguje na daném poštovním systému:
SMTP Relay - pouze na úrovni MTA
MTA+MDA - je doručeno a vykonají se pravidla na úrovni poštovního systému
MUA - forwarding pomocí pravidel na straně klinta

Problém je v tom, že na úrovni MTA+MDA to některé systémy neřeší vůbec, jiné podporují vložení scriptů nebo přesměrování pomocí uživatele, který má tato forwardovací pravidla nastavena. Ale některé systémy podporují nastavit i pravidla na úrovni poštovního systému. Takže to začíná být zamotané.

DKIM podpis je platný, pokud je možné načíst a ověřit klíč selektoru domény odesílatele a na základě klíče je možné ověřit podpis hlavičky/těla e-mailu. A to se řídí mimo jiné i zarovnáním domén definovaným v DMARC politice. Protože přeposláním se změní poslední hop v hlavičce a musí se změnit obálka, DKIM podpis nebude platný. Je nutné e-mail znovu podepsat. Alternativou je použít ARC, který podporuje řetězové přeposílání.
K tomu samozřejmě SPF. Pokud ho mám definovaný a použiji forwarding, dostávám se do zapeklité situace. Při použití údajů z předchozí hlavičky mi odeslání neprojde (nemohu odesílat namísto uvedené domény) a tak musím použít nové údaje. A i zde má na provoz vliv DMARC a definice zarovnání.

Celá tahle taškařice je problém ani ne tak kvůli implementačním rozdílům, jako nutnosti testovat odesílatele na straně příjímajícího systému. A nepochopení odesílatelů, že oni neověřují. Pouze dávají možnost příjemci si ověřit odesílatele.

Nechce se mi to ted hledal, ale nezda se mi veta:
Protože přeposláním se změní poslední hop v hlavičce a musí se změnit obálka, DKIM podpis nebude platný.

Dkim se odvozuje jen z nekolika hlavicek (h=to:subject:mes­sage-id:date....) Dalsi hop by nemel byt problem, protoze kazdy predavaci server jednu hlavicku received pridava a tim by to rozbil. Jestli se nepletu, dkim s obalkou vubec nepracuje

Omlouvám se za formulaci.
1) pokud přidám další hop do hlavičky, musím změnit podpis tagů v hlavičce, které jsou specifikované v seznamu určeném pro podpis. Jedná se o konfigurovatelnou hodnotu. DKIM obsahuje podpis těla a vybraných tagů hlaviček. Problémem můohou být některé tagy, jako je identifikace ageta (i=) a identifikace domény (d=), stejně jako návaznost na zarovnání (alignment) v rámci DMARC (adkim=s/r)
2) Obálka se mění, ale mezi DKIM a envelope není vztah. Každopádně musí dojít ke správnému ověření na straně příjemce dle RFC 5321 (FQDN odesílatele a existence těchto záznamů ... ano, spousta systémů to dodnes nekontroluje). V tu chvíli to samozřejmě znamená změnu počtu hopů v hlavičce, na straně MTA příjemce se při přijetí přidává jako poslední hop přijímající server a ostatní se posouvají. Ale v okamžiku vyhodnocování obálky dochází (mělo by docházet) k interakci s SPF odesílatele (řízené dle identifikace odesílajícího).
Právě to ověřování na straně příjemce je ten problém. Pokud podpis obsahuje tagy, které se při průchodu změní, je nutné e-mail přepodepsat. Pokud k této změně nedojde, není potřeba nic řešit. DKIM dle návrhu a dle standardních použitých tagů (From, To, Subject, Date) má přežít forwarding. Na druhou stranu to nejsou zrovna tagy, které by zajišťovaly důvěryhodnost. To je konec konců důvodem, proč se v současnosti navrhuje jako cesta technologie ARC, která má zajišťovat integritu i v průběhu předávání.

DMARC následně vyhodnocuje, zda platí:
Strict alignment = (From:domain and DKIM d=domain )
Relax alighment = (From: subdomain.domain and DKIM d=domain ) OR (From: domain and DKIM d=domain )

Problém je náročnost oddělení dopadů technologií SPF/DKIM/DMARC v některých oblastech a dopady jejich customizace na provoz. Oro obecná tvrzení to je již hodě tenký led.

Nepadla zde zmínka o technologii SRS (Sender Rewriting Scheme), která byla svého času považována za způsob, jak se vypořádat s přeposíláním mailů a zachováním platnosti SPF.

Technika SRS ale není použitelná v kombinaci s DMARC. Ano, je tu ještě pojistka v podobě DKIMu, jenže není to jistota.