Vlákno názorů k článku Stavíme vlastní e-mailový server: nastavení serveru, spam a IMAP od Pali - SPF + DMARC dokopy znemožnujú posielať emaily do...

ad 1) V pořádku. Neexistuje žádný důvod, proč někde hromadit skutečné adresy a přímo je nabízet k vyspamování. Autor se podepsal svým jménem (přezdívkou), je možné s ním v rámci mailing listu komunikovat a nevidím jediný důvod, proč by měl řvát do světa svoji adresu. Pokud ji sdělit chce, může ji uvést do těla zprávy.
ad 2) To samý, co 1
ad 3) To samý, co 1 a 2
ad 4) Veřejný mailing list, kde může kdokoliv neregistrovaný vyspamovat klidně tisíce registrovaných uživatelů je prasečina
Možná to není zcela dle původních záměrů mailing listů, ale doba je prostě taková. Je to velmi malá daň za to, co nabízí SPF a DKIM. Věčná škoda je, že se neujalo místo DMARC raději ADSP, které může být ještě restriktivnější.

SFP rozbíjí jedině rozbité forwardování pošty. Pokud server při forwardování změní obálkového odesílatele (což udělat musí, pokud má být v obálkové hlavičce e-mail, kam posílat případné chyby), SFP funguje správně. Při hromadném rozesílání e-mailů se to tak dělá odjakživa (např. e-mailové konference), při individuálním přeposílání se na to leta kašlalo, protože to nikomu nevadilo – SFP holt vyžaduje, aby to bylo nastavené správně.

Tak samozřejmě, Message-Id a In-Reply-To tam vrátíš :)

Aha, takže z DMARC není nesmyslná jenom to polovina, která umožňuje nechat si hlásit, kolik virů zrovna používá adresy z mé domény, ale i ta druhá polovina, která validuje adresu From místo obálkové adresy. To by mne nenapadlo, že někdo vezme údajnou chybu SPF, a reálně jí implementuje do nového doporučení.

Ale stále je tu problém, keď doména obálkového odosielateľa a doména vo From nesedia.
Problém s tím mají maximálně správci chybně nastavených serverů. Vůbec bych se nedivil, kdyby mezi e-maily, které nejsou spamem, byla nadpoloviční většina těch, které mají From a obálkového odesílatele různé. Je to totiž typické pro hromadně zasílané e-maily (ať už e-mailové konference, automaticky generované transakční e-maily nebo různé newslettery).

Pri validovaní DMARC je nutné aby boli domény zhodné.
Na to jste přišel jak?

Jak je libo. Jestli se vám líbí, že kdokoliv může vaším jménem (jménem vaší firmy) kohokoliv e-mailem oslovit a napsat mu cokoliv, potom je v pořádku to všechno povypínat. Existuje celá řada způsobů, jak udělat mailing list kompatibilní s DMARCem , což je to momentálně jediná použitelná metoda pro boj s podvodnými e-maily, která nám umožní protistraně sdělit, že opravdu trváme na tom, že naše maily mají být naše a nemá je cestou nikdo měnit. Realita je taková, že mailing list do e-mailu zasahuje a proto je JEHO zodpovědnost, jak JÍM odeslaný mail vypadá. Podívejte se na to taky z hlediska typického zaměstnavatele... řekněte mu, že sice existují technologie, které částečně dokáží zabránit podvodným e-mailům, ale že to nebudete zapínat, protože to rozbije pár mailing listů, které mu, na rozdíl od těch potencionálně podvedených zákazníků, nevydělají ani korunu. Jestli máte lepší řešení, sem s ním, rád se poučím.

Jestli se vám líbí, že kdokoliv může vaším jménem (jménem vaší firmy) kohokoliv e-mailem oslovit a napsat mu cokoliv,
K tomuhle ale slouží elektronický podpis, nikoli SPF nebo DKIM. SPF a DKIM jsou záležitosti poštovních serverů, takže to není „jménem mým“ nebo „jménem firmy“, ale „jménem poštovního serveru“.

Existuje celá řada způsobů, jak udělat mailing list kompatibilní s DMARCem
Já ale nechci nic dělat kompatibilní s DMARCem. E-mail tady byl dávno před DMARCem, pokud chce někdo přijít s něčím novým, ať to udělá buď zpětně kompatibilní, nebo ať udělá novou verzi e-mailu. DMARC porušuje pravidlo č. 1 e-mailu, totiž že poštovní server se řídí jen obálkovými adresami a tělo e-mailu je pro něj blackbox. Proto jsou ty dvě adresy zdánlivě „zduplikované“ na obálce, proto se používá ta analogie s pozemní poštou, která taky doručuje podle obálky a nestará se o vnitřek.

Vzhledem k tomu, že e-mail může být podepsaný, server nemůže měnit jeho obsah. Takže z té celé řady způsobů zbývá asi jen vložení e-mailu jako přílohy do nového e-mailu, což je opravdu úžasné řešení.

což je to momentálně jediná použitelná metoda pro boj s podvodnými e-maily, která nám umožní protistraně sdělit, že opravdu trváme na tom, že naše maily mají být naše
Já znám jiné použitelné metody – třeba DKIM nebo SPF. DMARC je zbytečnost navíc, a ještě ke všemu škodlivá.

nemá je cestou nikdo měnit
Právě, nemá je nikdo měnit, takže těžko můžu měnit hlavičku From, aby vyhověla DMARC. A nejenom, že je nemá cestou nikdo měnit, nemá je nikdo ani číst.

Realita je taková, že mailing list do e-mailu zasahuje a proto je JEHO zodpovědnost, jak JÍM odeslaný mail vypadá.
Mailing list do obsahu e-mailu žádným způsobem zasahovat nemusí. Mailing list je odpovědný za obálku, ne za obsah. Je to jako když necháte rozeslat poštou letáky. Vy ručíte za obsah, pošta ručí za obálky a za doručení. Pošta vám nebude upravovat obsah letáku, a vy zase nebudete poště kecat do toho, že se někdo přestěhoval a chce to doručit na novou adresu.

Podvodným e-mailům brání elektronický podpis. Podvodnému rozesílání brání SPF a/nebo DKIM.

Ono by to bylo všechno krásný, kdyby to tak bylo. Jenomže ono to tak není a proto se to musí řešit jinak.

Jinak, SPF a DKIM by stačilo, kdyby byla možnost na jejich vysledcích stavět, ale tato možnost byla už ve specifikacích omezená. Proto vzniklo ADSP a DMARC.

Píše sa to priamo v štandarde DMARC. Preto vravím, že to spôsobí problémy v kombinácií so SPF a .forward.
Nikoli, problém není v kombinaci SPF a přeposílání e-mailů, to funguje perfektně. Problém je v kombinaci DMARC a SPF a obecně v tom, že se DMARC stará o obsah e-mailu. Poštovní server si obsahu e-mailu nemá vůbec všímat, v ideálním případě by byl celý obsah e-mailu zašifrován a poštovní server by si všímal jen obálky a hlaviček Received a DKIM (které fakticky vzato nepatří do těla e-mailu ale na obálku).

Odesilatel se především dozví, že některému z příjemců zpráva nedorazila.
Což se dozví i při přepisu obálkové hlavičky. Je to zodpovědnost přeposílajícího serveru přeposlat mu chybovou zprávu.

I kdyby nevěděl kterému, je to pořád lepší, než když bude mail servery udržován v bláhové naději, že mail všem došel (což je přesně to, k čemu Váš návrh vede).
Když neví, kterému adresátovi e-mail nedošel, je ta informace úplně k ničemu. Můj návrh k ničemu takovému nevede. Podle RFC má být v obálkovém odesílateli adresa, na kterou se mají zasílat chyby. Což je v případě přeposílání přeposílající server, protože ten jediný ví, komu má tu chybu doručit. Ostatně e-mailové konference to takhle dělají odjakživa – přeci jen těch e-mailů doručují trochu víc, než jeden přeposílač, takže si nemohou dovolit mít to nakonfigurované špatně.

RFC5321 v části 3.3 říká, co má být v obálkové adrese odesílatele:

The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting).

Pokud tam server nechá původní adresu, je to špatně, protože o té adrese neví vůbec nic, neví jestli existuje, jestli je dostupná pro cílový server. Nebo snad někde ve standardu vidíte, že v obálkové hlavičce odesílatele může být jakákoli náhodná adresa, kterou si klient zrovna vymyslí?

V sekci 3.6.3 je pak napsáno, že server, který akceptoval e-mail k doručení, a dodatečně zjistí, že jej doručit nemůže, musí sestavit zprávu o nemožnosti e-mail doručit a tu zaslat právě na onu adresu obálkového odesílatele, kterou se dozvěděl od klienta.

If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path).

Mimochodem, také je v této části napsáno, že přeposílající server nesmí čmuchat v obsahu e-mailu (mimo hlaviček Received kvůli detekci smyčky) a už vůbec je nesmí měnit, takže přepisování hlavičky From v e-mailu přeposílajícím serverem odporuje RFC.

Na přeposílání chybových zpráv není potřeba si udržovat vnitřní stav, je to jen otázka implementace. Server může použít SRS, může zpáteční adresu vložit do nějaké hlavičky.

Má tam být mailbox which can be used to report errors. To těžko může být nějaká náhodná adresa, o které nevím vůbec nic (a na neověřenou obálkovou adresu se jinak než jako na náhodnou adresu dívat nemůžu). Má tam být adresa, na kterou je možné hlásit chybu – pochybuju o tom, že to je v RFC myšleno ironicky stylem „chyby můžete hlásit na lampárně“.

Nechovají se tak všechny servery, ale jenom ty jednodušší. Servery, které musely řešit složitější věci ohledně doručování e-mailů (např. servery e-mailových konferencí), obálkového odesílatele přepisují. To, že dříve nikomu nevadilo, že se do obálkové adresy odesílatele dávala nesmyslná adresa, neznamená, že to ničemu nevadí i dnes. Ostatně zprávy o nedoručení už se dnes neposílají, právě proto, že v té adrese je ve většině případů nějaká náhodná adresa a ne skutečný odesílatel. Zprávy o nedoručení je dnes možné odesílat jedině tehdy, pokud máte adresu odesílatele ověřenou, tedy pokud ji odesílající klient nastavil na nějakou adresu, za kterou je zodpovědný, a ověřilo se to přes SPF.

Při použití SRS se chyby hlásí na adresu, kterou SRS uvedlo jako MAIL FROM při navázání komunikace (oproti tomu je zároveň ověřeno SPF, pokud se používá). SRS se potom v případě chyby postará o odeslání zpět na původní adresu, která se dá ze SRS adresy vyčíst a navíc se kontroluje hash, aby nebylo možné díky SRS posílat e-maily kamkoliv. Mimochodem, u konferencí je většinou potřeba zpětné chyby odfiltrovat, protože když někdo něco pošle do konference, určitě ho nezajímá, kolik nefunkčních adres je aktuálně registrováno, jediné, co ho zajímá, pokud e-mail z nějakého důvodu konference odmítne ještě před distribucí dalším účastníkům.

Tahle opičárna se vyplatí pro konferenci, ale na běžném serveru nemá cenu. DMARC projde tak dlouho, dokud je v pořádku alespoň DKIM a jestli neprojde SPF není zase tak moc podstatné. Takže kdo si na domácím serveru provozuje nějaký mailing list, nic mu nebrání v instalaci třeba postsrsd.

Takže znovu, dokud konference nehrabe do obsahu, DMARC PROJDE!!! s platným DKIM a failnutým SPF (pokud nepoužívá SRS). Pokud konference do obsahu hrabe, DMARC stále může projít s failnutým DKIMem, ale platným SPF, pokud se použije SRS, ale podle mě by konference v takovém případě měla e-mail převzít (tělo) a poslat jej pod svými hlavičkami.

Takže stále nevidím žádný problém s nastavením konference tak, aby s DMARCem fungovala a nevidím ani problém v DMARCu. Naopak, pokud budu email zahazovat jen kvůli failnutému SPF, jak tu kdosi inteligentně navrhoval (což bych ani neměl, protože trvám na tom, že SPF nám jen sděluje, jestli podepisujeme, nebo ne, ale neuvádí žádnou politiku, jak se chovat v případě chyby), tak bude situace horší, než s DMARCem, protože přijdu o možnost doručení na základě korektního DKIMu.

DMARC projde s platným DKIM jedině tehdy, pokud se DKIM používá. Pokud se použije jen SPF (protože je to jednodušší, nebo protože e-maily odesílá cizí server), a přeposílající server nepřepíše obálkového odesílatele, tak DMARC neprojde.

DMARC stále může projít s failnutým DKIMem, ale platným SPF, pokud se použije SRS, ale podle mě by konference v takovém případě měla e-mail převzít (tělo) a poslat jej pod svými hlavičkami.
Ke změně hlaviček e-mailu není žádný důvod. Naopak u přeposílání je to špatně, protože přeposílající server nemá hlavičky e-mailu vůbec řešit a už vůbec je nemá měnit. U konference by se změna hlaviček ještě dala obhájit, že to není jen SMTP relay.

nevidím ani problém v DMARCu
Problém DMARCu je v tom, že se váže na hlavičku From v e-mailu, do které e-mailovému serveru nic není. Ta hlavička může být klidně šifrovaná… Před několika lety proběhla českým internetem aféra, kdy jeden velký český poskytovatel freemailu doručoval e-maily podle hlavičky To místo obálkové hlavičky. Tenkrát se to řešilo jako nepředstavitelná chyba serveru, dnes se z doručování podle hlaviček e-mailu místo obálkových hlaviček dělá standard…

(což bych ani neměl, protože trvám na tom, že SPF nám jen sděluje, jestli podepisujeme, nebo ne, ale neuvádí žádnou politiku, jak se chovat v případě chyby
A kvalifikátory (+, ?, ~, -) jsou podle vás v SPF k čemu? V příloze G RFC7208 máte doporučení ohledně politik.

Použít DMARC bez DKIM absolutně nemá význam a rovnou se můžu (ne)spolehnout jen na SPF.

Mimo jiné

SPF "fail" results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF "fail" results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means).

Jsou tam doporučení, co je možné udělat, ale nikde není napsáno nic o tom, že nám odesílatel říká konkrétním nastavením konkrétní postup. Pokud budu e-maily zahazovat kvůli SPF, jak radíte, rozbiju tím víc věcí, než DMARCem.

Takže jediná relevantní věc, která vám evidentně vadí, je to, že DMARC kouká na From:. Já tomu sice rozumím, že to od něj není hezké, na druhou stranu to jinak prostě nejde. DMARC je třeba vnímat tak, že dělá práci za uživatele, kteří se ji za desítky let dělat nenaučili. Ano, uživatel by měl vyžadovat nějakou formu průkazného podpisu a jeho průkaznost by si měl i ověřovat, ale on to nedělal, nedělá a dělat asi ani nebude. Proto je tu DKIM s DMARCem, které dohromady ověřují, že je podpis jako takový správný a že je opravdu od odesílatele, respektive alespoň jeho domény, což je lepší, než nic. Berte to asi tak, že když si na schránku nalepíte "nevhazovat reklamní letáky", tak delegujete na pošťáka, který by měl bez keců doručit cokoliv od kohokoliv, možnost rozhodnout, co vám tam hodí a co ne.

Mimochodem, zrovna mě napadla zajímavá myšlenka, vytvořit každému uživateli vlastní DKIM klíč se selektorem podle username a tím si u ŘÁDNĚ INFORMOVANÉ protistrany zvýšit důvěru z "je to od nás" na "je to od nás a od konkrétního člověka".

Ano, DMARC ověří, že doména uvedená v hlavičce e-mailu není podvrh, načež e-mailový klient tu adresu vůbec nezobrazí. Takže jinak to samozřejmě dělat jde – například to nedělat vůbec, Což je pořád lepší, než to dělat špatně a dostat výsledek, který je k ničemu.

Filip Jirsák: aha... a spam filtry a antiviry taky nebudeme používat, protože nejsou stoprocentní... a navíc... ty mrchy běží na serveru, čtou tělo zprávy a na základě toho dělají nějaké závěry... TO JE SKANDÁL!!! Můžu se stavit na návštěvu? Předpokládám, že doma zásadně nezamykáte a možná nemáte ani dveře, protože ještě nikdo nevyrobil žádné dokonalé...

a spam filtry a antiviry taky nebudeme používat, protože nejsou stoprocentní...
To s něčím polemizujete?

ty mrchy běží na serveru, čtou tělo zprávy a na základě toho dělají nějaké závěry...
Antipsam a antivir neběží na SMTP relay, fungují na MDA nebo-li na serveru, který doručuje do schránek. Můžete je chápat jako součást klienta poštovní schránky, jako uživatelský filtr ve schránce.

Za prvé, antivir i antispam klidně na relay běžet můžou, stejně jako SPF, DKIM a DMARC a ať se vám to líbí, nebo ne, je to volba majitele relay serveru, kterou nijak neovlivníte. Jestli máte problém s DMARCem na relay, tak si jej tam neinstalujte, na zprávy nesahejte, SRS si používejte nebo nepoužívejte dle libosti, maximálně rozbijete SPF (což asi nechcete, když ho doporučujete místo DMARC) a do zprávy v rámci svých pevných zásad nesahejte, čímž necháte funkční alespoň DKIM a tím pádem i DMARC. Pro vás to není problém, pro mě to není problém, DMARC u odesílatele i jeho kontrola u příjemce vám může být zcela ukradená a dodržíte tím i to, že DMARC ověření proběhne až u MDA, což je dle vás zcela v pořádku. Ale teď už opravdu nevím, na co si stěžujete... Na špatně nastavené relay servery? Ale to jsem říkal už na začátku. Pokud je nastaven korektně, nic nerozbije a DMARC vůbec řešit nemusí.

j: Já taky netvrdím, že SPF něco podepisuje, od toho je tam DKIM, ale SPF jenom říká, odkud by tak mohl email přijít. A i když SPF zfailuje (-all), tak není nikde napsáno, ani jednoznačně doporučeno, že kvůli tomu MUSÍM, nebo bych alespoň MĚL mail zahodit. Je tam napsáno, že ho MOHU zahodit, nebo to MOHU použít jako jedno z kritérií pro další posuzování. Toto je dle RFC moje rozhodnutí a protistrana mi k tomu nic nenařizuje. (na rozdíl od DMARC, který obsahuje jasnou politiku). Mně osobně by se líbilo ho radši zahodit a to jak kvůli fail SPF, tak DKIM, ale už bylo pár takových, co to zkoušeli a zase si to většinou rozmysleli. Já spíš nechápu ten velmi speciální postoj, kdy zahodit něco kvůli SPF je v pořádku, ale zahodit to kvůli DMARC je strašnej problém a to asi jen proto, že DMARC kouká na From.

DMARC také nic nenařizuje, u použití politiky zveřejněné vlastníkem domény je SHOULD.

zahodit to kvůli DMARC je strašnej problém a to asi jen proto, že DMARC kouká na From
To, že DMARC kouká na hlavičku, do které serveru vůbec nic není a kde může být cokoli, samozřejmě je podstatný problém. Kdyby se DMARC rozhodoval podle prvního slova e-mailu nebo podle (textového) podpisu v e-mailu, připadalo by vám to normální?

RFC 7208 (SPF):
SPF "fail" results CAN be used to reject messages during the SMTP transaction
SPF "fail" results CAN alternately be used as one input into a larger set of evaluations

RFC 7489 (DMARC):
Domain Owners publish policy assertions about domains via the DNS.
These receivers CAN use these results to determine how the mail SHOULD be handled.

takže dle RFC:
MOHU zamítnout zprávu kvůli SPF
MOHU výsledek SPF použít jako součást vyhodnocování
MOHU použít politiku vlastníka k vyhodnocení, jak BYCH MĚL maily zpracovat.

No tak pardon, nemam v tom hokej, jenom už jsem z té debaty unavenej. Už jsem to nasel kde jsem to napsal a je to samozřejmě blbost.

To, že si odesílatel přál odesílat na danou adresu zprávy o nedoručitelnosti, ještě neznamená, že je dobrý nápad na tu adresu zprávy posílat. Dnes chodí spousta spamu a virů, které mají adresy odesílatele falešné – a majitel té e-mailové adresy si rozhodně nepřál dostávat nějaké zprávy o nedoručitelnosti spamu nebo viru. Na tu adresu můžu doručovat chyby jedině tehdy, pokud jsem si ověřil, že ta adresa (nebo aspoň ta doména) je v pořádku. Jinak tu adresu musím považovat za náhodnou.

Nikde jsem nepsal, že po přeposlání původního odesílatele nedoručitelnost nezajímá. Ale když přeposílající server přijal e-mail k doručení, je jeho zodpovědnost, aby byla zpráva o nedoručitelnosti doručena odesílateli.