DMARC/SFP a hlavička Return-Path

DMARC/SFP a hlavička Return-Path
« kdy: 30. 10. 2025, 15:51:12 »
Zakaznikum zrejme budeme zpracovavat bounce emaily, ale potrebuji si overit, ze to chapu spravne, standardne se generuje Return-Path z MailFrom:

0] RFC 5322.From: zakaznik@example.org
1] RFC 5321.MailFrom: zakaznik@example.org
2] vlozime extra hlavicku Return-Path: bounce@some-example.org

SPF zaznamy jsou pro domeny v 0]1] a 2] nastaveny korektne.

Co jsem cetl blogy z ruznych ESP, jsem to pochopil tak, ze aby bylo "SPF aligment to pass DMARC", musi domena v 2] byt shodna v 0]. Nebo se pletu a ma to byt pri pridane 2] zarovnane v 0] a 1]?

Diky.


McFly

  • *****
  • 638
    • Zobrazit profil
    • E-mail
Re:DMARC/SFP a hlavička Return-Path
« Odpověď #1 kdy: 30. 10. 2025, 18:27:47 »

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #2 kdy: 03. 11. 2025, 09:17:37 »
Pěkně to má popsáno Seznam.cz - https://o-seznam.cz/napoveda/email/profi/zaznamy-pro-autentifikaci-posty/dmarc/

Ten clanek neresi samostatnou hlavicku Return-Path.

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #3 kdy: 03. 11. 2025, 09:59:27 »
DKIM i SPF porovnává doménu vždy s doménou v hlavičce e-mailu (From dle RFC 5322). Protože From je to, co uživatel vidí ve svém e-mailovém klientovi.

Return-Path má obsahovat e-mailovou adresu, na kterou se mají posílat případné chyby při doručování.

SPF sváže From z hlavičky e-mailu s Return-Path, tím pádem se pak takový e-mail nedá přeposílat (při přeposlání se mění return-Path ale nemění se From). Proto doporučuju raději používat při odesílání DKIM – to zaručuje, že e-mail odeslal někdo z té domény, která je uvedená ve From, bez ohledu na to, kolikrát byl e-mail následně přeposlán.

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #4 kdy: 03. 11. 2025, 11:10:06 »
DKIM i SPF porovnává doménu vždy s doménou v hlavičce e-mailu (From dle RFC 5322). Protože From je to, co uživatel vidí ve svém e-mailovém klientovi.

Return-Path má obsahovat e-mailovou adresu, na kterou se mají posílat případné chyby při doručování.

SPF sváže From z hlavičky e-mailu s Return-Path, tím pádem se pak takový e-mail nedá přeposílat (při přeposlání se mění return-Path ale nemění se From). Proto doporučuju raději používat při odesílání DKIM – to zaručuje, že e-mail odeslal někdo z té domény, která je uvedená ve From, bez ohledu na to, kolikrát byl e-mail následně přeposlán.
Přeposílat se dá, k tomu účelu se používá SRS (Sender Rewrite System), kde se v return-path zachová původní hodnota, ale doména souhlasí s doménou serveru, který přeposílá, takže SPF souhlasí.
SRS používá Microsoft, Google i Seznam.
Pak to vypadá takto nějak:
Return-Path: <SRS0=1PwV=5L=allser.skin=edkuvnk@preposilajici.cz>


Re:DMARC/SFP a hlavička Return-Path
« Odpověď #5 kdy: 03. 11. 2025, 11:58:53 »
Testoval jsem to s jednim sikovnym dmarc analyzatorem  a muzu potvrdit, ze pokud v hlavicce Return-Path bude jina domena nez v hlavicce From, tak spf sice autorizuje ip adresu, ale dmarc alignment neni validni.
Celkovy vysledek pak je: spf fail, dkim pass, dmarc pass (spf a dkim relax mode).

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #6 kdy: 03. 11. 2025, 12:14:41 »
DKIM i SPF porovnává doménu vždy s doménou v hlavičce e-mailu (From dle RFC 5322). Protože From je to, co uživatel vidí ve svém e-mailovém klientovi.

Return-Path má obsahovat e-mailovou adresu, na kterou se mají posílat případné chyby při doručování.

SPF sváže From z hlavičky e-mailu s Return-Path, tím pádem se pak takový e-mail nedá přeposílat (při přeposlání se mění return-Path ale nemění se From). Proto doporučuju raději používat při odesílání DKIM – to zaručuje, že e-mail odeslal někdo z té domény, která je uvedená ve From, bez ohledu na to, kolikrát byl e-mail následně přeposlán.
Přeposílat se dá, k tomu účelu se používá SRS (Sender Rewrite System), kde se v return-path zachová původní hodnota, ale doména souhlasí s doménou serveru, který přeposílá, takže SPF souhlasí.
SRS používá Microsoft, Google i Seznam.
Pak to vypadá takto nějak:
Return-Path: <SRS0=1PwV=5L=allser.skin=edkuvnk@preposilajici.cz>

Jenže v takovém případě právě u DMARC selže SPF Alignment validace, protože v Return-Path máte doménu preposilajici.cz, ale ve From e-mailu bude původní odesílatel.

SRS řeší to, aby přeposílající měl zachovanou informaci, pro koho daný e-mail přeposlal. Přeposílající je tak schopen případnou chybovou zprávu přeposlat původnímu odesílateli. Ale i když existují obvyklé formáty, jak SRS zapisovat, neexistuje žádný standard, který by museli všichni dodržovat – takže adrese v Return-Path přepsané pomocí SRS rozumí jenom ten, kdo daný e-mail přeposlal. Ostatní mohou jen hádat, jaká asi byla původní adresa. Což ale ničemu nevadí, protože ostatní se na to stejně nemohou spolehnout – já klidně můžu vytvořit e-mail, který bude mít v Return-Path adresu, která se bude tvářit, jako že jste ten e-mail vytvořil vy a já ho jen přeposlal. Takže na to se při validaci odesílatele nelze spoléhat. Pro validaci odesílatele potřebujete něco, co spojí původního odesílatele s e-mailem, bez ohledu na to, kolikrát se e-mail přepošle – a k tomu slouží DKIM.

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #7 kdy: 03. 11. 2025, 23:49:56 »
Zazněly zde některé nepřesnosti, zkusím tu problematiku shrnout:

Řádek Return-Path: vzniká až v okamžiku, kdy mail na své cestě k adresátovi dorazí na poslední MTA v cestě a je předán pro lokální doručení.  Do Return-Path: je v tomto okamžiku vložena adresa odesilatele obvykle označovaná jako mail sender, obálková nebo protokolová adresa, adresa ze smtp příkazu MAIL FROM atp. Ve zde nepřímo zmíněném RFC 5321 vizte sekci 4.4.

Na mail sender adresu se posílají zprávy o nedoručitelnosti a tato adresa se používá při kontrole dodržení SPF.
Po doručení mailu do mailboxu by ta adresa mail sender vlastně zanikla. Aby ji příjemce mailu měl možnost někde spatřit a aby ji správce mail serveru eventuelně nemusel hledat v poštovním logu, je použita tato berlička v podobě zapsání adresy do hlavičky Return-Path.

SPF kontrola nepracuje s hlavičkou From:, ale s adresou mail sender.

SRS je pomocný trik sloužící k tomu, aby bylo možno mail přeposílat (prostřednictvím aliasů, souboru .forward apod.). Při klasickém přeposlání by zůstala adresa mail sender zachována, čímž by ale při kontrole u příjemce bylo (velmi pravděpodobně) zjištěno porušení SPF. Proto je použit trik s přepisováním této adresy pomocí SRS.

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í. S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.

Ve vztahu k DMARC existují různá doporučení pro přeposílání nebo pro provozování mailových konferencí. Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM. 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.

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #8 kdy: Dnes v 08:58:40 »
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.

Představte si, že budu mít třeba adresu josef@example.org, a všechny e-maily na ní směrované budu přeposílat na josef@example.com. Když nebudu přepisovat obálkového odesílatele, přepošle se e-mail na josef@example.com s původním odesílatelem, třeba alice@example.net. Když bude problém s doručením do cílové schránky, třeba bude plná, pošle se na alice@example.net chyba o nedoručení na josef@example.com. Ale co má Alice s tou chybou dělat? Ona žádný e-mail na adresu josef@example.com neposílala, nemusí vědět, komu ten e-mail patří.

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.

SPF je přežitek z doby, kdy byla snaha vyhnout se kryptografii a validovat e-maily podle toho, kdo je odesílá. Naráželo to na dva problémy – jednak spousta serverů při přeposílání neměnila odesílatele v obálce e-mailu. To se dá spravit třeba právě přes SRS. Ale hlavně tím byla validovaná obálková e-mailová adresa, kterou uživatel nevidí. Uživatele zajímá From z e-mailu. Mohlo to teoreticky fungovat tak, že důvěřujete tomu, kdo e-mail přeposílá, a že on validoval SPF. Jenže někdy chcete přeposílat všechno, i spam a e-maily s nevalidním SPF, takže by to přeposílající musel nějak signalizovat. A na to standardní mechanismus není.

Tohle se snažil napravit DMARC alignment, který ovšem při použití se SPF zase rozbil přeposílání, při kterém From z e-mailu neodpovídá obálkovému odesílateli.

Používejte při vytváření e-mailu DKIM, pak s e-maily nebudou problémy při DMARC validaci ani při přeposílání.

Re:DMARC/SFP a hlavička Return-Path
« Odpověď #9 kdy: Dnes v 10:40:25 »
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? ...
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.

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.


Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM.
Ona to ani vyžadovat nemůže.
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.