Už je to tu zas - "nejde vám mail" (diskuse)

[Zdenek]

Mno ja mam to stesti, ze jsem v te velke spolecnosti a muzu diktovat tem malym jak maji mit nastavene mailservery

[tezkatlipoka]

velke spolecosti jsou pakaz, jedna velka mezinarodni nam  zacala kdysi zahazovat emaily, po nekolika dennim prudění jsme přisli na to, ze je to proto, ze si nastavili tak přisnou kontrolu obsahu, ze slovo podpis povazovali za sproste, a ani chybejici s je nepřesvědčilo o opaku. Nastesti jsem tam pak narazil na jednoho admina puvodem polaka, ktery jim to potvrdil. Ale uzili jsme si to, už proto ze tato firma maily rovnou zahazovala, takze jsme zprvu vubec nevedeli ze se neco deje.

[Zdenek]

Jo zahazovani bez informovani je hnus, nejlepsi je odmitnout mail jiz behem SMTP spojeni.

[Zdeněk Burda]

Některé velké společnosti na to nehezky serou:

Received: from mtagate8.de.ibm.com (mtagate8.de.ibm.com [195.212.29.157])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.xxx.xxx (Postfix) with ESMTP id B725A4B268
 for <xxx@xxx>; Tue, 28 Apr 2009 22:48:40 +0200 (CEST)
Received: from d12nrmr1607.megacenter.de.ibm.com
 (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
 by mtagate8.de.ibm.com (8.14.3/8.13.8) with ESMTP id n2OEakTW228592
 for <xxx@xxx>; Tue, 24 Mar 2009 14:36:46 GMT

[Kvakor]

Dle RFC 2821 by se měl mailserver v HELO/EHLO představit kanonickým a resolvovatelným (nejlépe i zpětně resovovatelným) jménem stroje a pokud není dostupné, tak má alespoň použít svou aktuální adresu a ne nějaký nesmysl typu NAVUQLM. Pokud máte tu smůlu, že zrovna z takovéhoto humpolácky nastaveného mailserveru musíte přijímat poštu, tak je lepší ho dát do whitelistu než všechno globálně povolit, ušetříte si spoustu starostí se spamem.

[Chulda]

Ale uzije si spoustu "srandy" s obchodniky. Kolegove by moyhli vypravet :(

[Kvakor]

Vetšinou stačí přes dotčného vzkázat administrátorovy mailserveru, že má chybně nakonfigurovaný server.

[Marv-CZ]

Na to vám zaručeně příjde odpověď:

"Ostatním to od nás chodí, takže chyba je u Vás."

[Filip Jirsák]

Ovšem bylo by dobré to poslat především tomu, kdo ho má nakonfigurovaný opravdu chybně, tedy v rozporu s RFC -- v tom to případě tedy nejprve autorovi blogu.

[Filip Jirsák]

Správně píšete „má“ (lépe řečeno „měl by“). V originále SHOULD, což znamená doporučení, přičemž existují případy, kdy je přípustné takové doporučení ignorovat. Pokud tedy někdo v HELO/EHLO požaduje kvalifikované doménové jméno odesílajícího stroje, má chybně nakonfigurovaný server především on. Hlavně že se tou chybnou konfigurací nezapomene pochlubit v blogu…

[Kvakor]

Kdepak, pokud SMTP server odmítne komunikovat s jiným serverem, který porušuje nepoviné částí (SHOULD) rozličných RFC, tak se to dá považovat za všechno možné, jen ne chybnou konfiguraci. Obecně totiž server může odmítnou komunikaci z libovolného důvodu, ale pokud to udělá dle pravidel SMTP protokolu, je to stále v pořádku.

Jinak kontrolu kvalifikovaného doménového jména (FQDN) odesílajícího serveru (ještě spojenou s kontrolo existence reverzního DNS záznamu) považuju za velmi účinnou zbraň, kterou se zastaví takových 95% spamu pocházejícího z botnetů.

Korekntí servery, které nemají FQDN, nebo vrací v HELO/EHLO blbosti (naprosté minimu), sice také neprojdou, ale zkusí další MX záznam, kde je server providera a ten už žádné kontroly nemá. Takže legitimní e-mail dorazí (protože u SMTP server MUSÍ zkusit další MX záznam), ale spam neprojde.

[Filip Jirsák]

Kdepak, pokud SMTP server odmítne komunikovat s jiným serverem, který porušuje nepoviné částí (SHOULD) rozličných RFC, tak se to dá považovat za všechno možné, jen ne chybnou konfiguraci. Obecně totiž server může odmítnou komunikaci z libovolného důvodu, ale pokud to udělá dle pravidel SMTP protokolu, je to stále v pořádku.

Jistě, server může odmítat e-maily třeba od lidí, kteří se na jeho správce špatně podívali. Ale pak neplní správně svou funkci -- poštovní server má za úkol doručit maximum e-mailů, nikdo od něj nechce, aby některé e-maily náhodně zahazoval.

Jinak kontrolu kvalifikovaného doménového jména (FQDN) odesílajícího serveru (ještě spojenou s kontrolo existence reverzního DNS záznamu) považuju za velmi účinnou zbraň, kterou se zastaví takových 95% spamu pocházejícího z botnetů.

Další, kdo řekne polovinu informace, a skončí. Účinnost spam filtru můžete posuzovat jedině podle poměru (správně) odmítnutých spamů a (nesprávně) odmítnutých hamů. Pokud to posuzujete jen podle odmítnutého spamu, vypněte si mailserver -- to je ten nejlepší způsob boje proti spamu, zastaví to zaručeně 100 % spamu.

[Zdenek]

Ja mam jednodusi metodu posuzovani. Podle reakci uzivatelu pro ktere mailserver spravuji

[pht]

poštovní server má za úkol doručit maximum e-mailů, nikdo od něj nechce, aby některé e-maily náhodně zahazoval

Poštovní server má za úkol udělat to, k čemu je nastaven. Pokud ho nastavím aby něco zahazoval, tak to bude zahazovat.

Účinnost spam filtru můžete posuzovat jedině podle poměru (správně) odmítnutých spamů a (nesprávně) odmítnutých hamů.

K tomu mohu říci, že po uvolnění restrikce abych přijmul ten jeden celkem důležitý ham mail, jsem zároveň obdržel řádově 20 spamů.

[Filip Jirsák]

Poštovní server má za úkol udělat to, k čemu je nastaven. Pokud ho nastavím aby něco zahazoval, tak to bude zahazovat.

Ale pokud si server nastavíte tak, aby odmítal komunikaci, kterou RFC připouští, nesvádějte pak odmítání e-mailů na to, že RFC porušuje druhá strana.

[trekker.dk]

K tomu mohu říci, že po uvolnění restrikce abych přijmul ten jeden celkem důležitý ham mail, jsem zároveň obdržel řádově 20 spamů.

OK, takže jsou dvě varianty - buď zavedu restrikci a uživatelům nebude přicházet pošta, nebo ji uvolním a naložím o trochu víc práce spamfiltru... hm

Ale fajn, s tebou jsou přeci uživatelé spokojení - asi proto, že neví (stejně jako ty), o kolik mailů vlastně přišli.

[pht]

Já mám jen jednoho uživatele - sebe - a spokojený jsem. Navíc spam filtr nemám, protože když ten něco vyřadí tak o tom nevíte úplně stejně. To je lepší těch 30 spamů denně smazat, než denně hledat ve složce s 30 spamama jestli tam není nějaký normální mail.

[trekker.dk]

Navíc spam filtr nemám, protože když ten něco vyřadí tak o tom nevíte úplně stejně.

Jo, proto má spamassassin možnost jenom přepsat subject...

[pht]

A když se nad tím zamyslíte podrobněji, tak to vyrobí tentýž problém.

[pht]

Takže legitimní e-mail dorazí (protože u SMTP server MUSÍ zkusit další MX záznam), ale spam neprojde.

To je docela dobrý nápad, asi to nastavím takto. Budu to ale ještě muset sladit s nolistingem, jelikož se zase dostanu do konfliktu s tím, že nějaké dementní SMTP servery zkusí jen dva a né tři MX.

[pht]

V originále SHOULD

Opravdu?

-  The domain name given in the EHLO command MUST BE either a primary
   host name (a domain name that resolves to an A RR) or, if the host
   has no name, an address literal as described in section 4.1.1.1.

existují případy, kdy je přípustné takové doporučení ignorovat

Tak mi prosím nějaký uveďte a obhajte ho jako případ kdy server připojený k síti s veřejnou adresou, společnost má kontrolu nad svým DNS atd., prostě normálně, má důvod něco takového dělat.

[Filip Jirsák]

V originále SHOULD

Opravdu?

Opravdu. Přímo u příkazu EHLO je totiž toto:

These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is

available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.

existují případy, kdy je přípustné takové doporučení ignorovat

Tak mi prosím nějaký uveďte a obhajte ho

Moje úloha jako příjemce není zkoumat, jaké má odesílatel důvody. RFC tuhle variantu připouští, tak s ní musím počítat. Nebo řekněte, že na RFC kašlete a uděláte si to po svém -- pak ale netvrďte, že RFC porušuje ten druhý.

[pht]

Přímo u příkazu EHLO je totiž toto: ...

Vždyť to je totéž co jsem psal já! Musí tam být buď smysluplné jméno nebo IP adresa. To Vaše RFC nepřipouští situaci že tam je jméno které nejde resolvovat - což je případ kdy to pak mail server odmítne, je-li nastaven "striktně".

A navíc jsem nikde o žádném porušování RFC nic nepsal. Já jsem psal jen to, že mě štve, že SMTP komunikace neprochází základními "sanity" kontrolami, zkrátka že mi ty servery posílají blbosti, přitom není problém pro daného správce to nastavit dobře (navíc by to měla být jeho psí povinnost). Nějakým RFC jste tu začal šermovat až Vy a navíc nepravdivě.

[Dračík]

Souhlasím s Filipem Jirsákem. V RFC 5321 se říká toto:

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis.

Každý si samozřejmě může nastavit MTA jak chce, ale chtěl bych vás vidět, jak ve firmě před managementem obhajujete, že zahazujete maily od zákazníků, ať máte sebevětší pravdu, že jsou prasata a neumí (nebo nemůžou) si to nastavit

[pht]

V tom 5321 je ale tatáž pasáž o tom jak to EHLO má vypadat (viz výše). A já se nebavím o souhlasu s IP adresou klienta ale o tom, že hostname uvedený v HELO/EHLO nemá žádnou adresu. A opět opakuji: můj blog post je o tom, že to je bordel a nezkoumám to verzus nějaké RFC. Ono to ani není potřeba, protože normální poučka zní, že server by měl akceptovat všelicos, dokud to ještě dává smysl.

ve firmě před managementem

Opět opakuji: je to můj soukromý server s jedním uživatelem (mnou). A jinak si dovedu představit i firmu, která by to v rámci možností oficiálně prosazovala - je to podobné jako prosazovat aby Vám nechodily v přílohách docy apod.

[Filip Jirsák]

Ono to ani není potřeba, protože normální poučka zní, že server by měl akceptovat všelicos, dokud to ještě dává smysl.

Což je v rozporu s vaším „nastavením serveru na striktní režim“. Takže by se ten váš zápisek taky dal výstižněji formulovat jako: „Porušil jsem známé pravidlo, že odesílatel má být přísný v tom, co odesílá, a příjemce tolerantní v tom, co přijímá – a narazil jsem.“ Jenže pak by musel následovat zcela opačný závěr – ne rýpnutí do „velké společnosti se solidním zázemím“, ale upozornění pro ostatní „neopakujte stenou hloupost, kterou jsem udělal já“.

[pht]

No, ještě jste to úplně nepochopil ale jste na správné cestě. Zkuste si znovu ten zápisek přečíst.

[Filip Jirsák]

Přečetl jsem si to znova a chápu to pořád stejně – vy jste si na svém serveru nastavil nějaká pravidla, která jsou přísnější než RFC, a stěžujete si, že někdo jiný se těmito vašimi pravidly neřídí.

[pht]

Nechme stranou RFC - stěžuju si na to, že když to tak nastavím, tak zjistím že existují entity, které nemají zjevný důvod ke špatnému nastavení a přesto špatným nastavením trpí. Navíc se domnívám, že nějaké RFC mají u něčeho, leda že byste u toho serveru seděl Vy osobně

[xkucf03]

A já se nebavím o souhlasu s IP adresou klienta…

Pak to ale nemá cenu řešit, alespoň z dlouhodobějšího hlediska – pokud nebudeš kontrolovat IP, je to na nic, protože spameři tam začnou cpát třeba seznam.cz.

[pht]

To je takové coby kdyby: oni by samozřejmě udělali úplně nejlépe, kdyby měli normální SMTP server, který by se nelišil od jiných. Ale to nemají, a seznam.cz tam také necpou, takže to zatím funguje. Až to přestane fungovat, sáhneme po něčem jiném.

[Filip Jirsák]

V RFC je napsáno, že za HELO/EHLO je název (všimněte si nepřítomnosti MUST). A pokud takový název nelze smysluplně vytvořit, měla by by tam být IP adresa (SHOULD). Stále ale existuje možnost, že název nelze smysluplně vytvořit a správce serveru se nebude řídit doporučení mít tam IP adresu (protože SHOULD je jen doporučení) – v takovém případě pak může být v EHLO cokoli (co splní syntaktická pravidla), žádné další pravidlo, co použít, když se nepoužije ani IP adresa, v RFC není.

A navíc jsem nikde o žádném porušování RFC nic nepsal. Já jsem psal jen to, že mě štve, že SMTP komunikace neprochází základními "sanity" kontrolami, zkrátka že mi ty servery posílají blbosti, přitom není problém pro daného správce to nastavit dobře (navíc by to měla být jeho psí povinnost). Nějakým RFC jste tu začal šermovat až Vy a navíc nepravdivě.

Psal jste, že jste blokoval komunikaci se servery, které mají podle vás chybné nastavení, ale to nastavení je v souladu s RFC. A vadilo vám, že tahle vaše pravidla nad rámec RFC někdo jiný nedodržuje. Jenže kdyby si každý vymýšlel svoje pravidla pro e-mailovou komunikaci, nebo to samozřejmě nikdy fungovat. Právě proto je tu RFC, kterým se mají řídit všichni – pokud se jím řídí obě strany komunikace, nenastává žádný problém.

[pht]

všimněte si nepřítomnosti MUST

Buď těch RFC je tolik a navzájem si odporují, a nebo nevím co jiného je špatně ale já tam to MUST vidím.

Jenže kdyby si každý vymýšlel svoje pravidla pro e-mailovou komunikaci

Já si nic nevymýšlím, prostě jstem použil nějaké standardně dodávané nastavení a sledoval jsem, co se stane. Vymýšlí si spíše odesilatel, když si myslí, že smyslem parametru EHLO je něco, co neexistuje.

[Filip Jirsák]

všimněte si nepřítomnosti MUST

Buď těch RFC je tolik a navzájem si odporují, a nebo nevím co jiného je špatně ale já tam to MUST vidím.

Já teda ne:

These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.

Já si nic nevymýšlím, prostě jstem použil nějaké standardně dodávané nastavení a sledoval jsem, co se stane. Vymýšlí si spíše odesilatel, když si myslí, že smyslem parametru EHLO je něco, co neexistuje.

Vymyslel jste si pravidlo, že parametr HELO/EHLO musí nějak vypadat. A on tak podle RFC vypadat nemusí, a vaše pravidla asi nikdo nezná.

[pht]

Tak si zascrolujte výš, ta mnou citovaná pasáž je ze stejného dokumentu.

[Filip Jirsák]

Myslíte tohle?

The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.

To se ale týká pouze toho, jak má vypadat doménové jméno předávané v příkazu EHLO. Neříká to nic o tom, zda v tom příkazu může nebo nemůže být nic jiného.

[pht]

A co jiného by tam mělo být?

[Filip Jirsák]

Popis toho, jak má vypadat parametr EHLO v případě, kdy tam není ani doménové jméno ani IP adresa.

[pht]

Nechápu. Co jiného než tyto dvě věci by mělo být parametrem EHLO?

[Filip Jirsák]

Definice EHLO říká, že jeho parametrem může být 1. doménový název, 2. IP adresa, 3. něco jiného. Vámi uvedená definice řeší, jak má ten název vypadat, pokud je zvolena varianta č. 1, případně jak má vypadat IP adresa, pokud je zvolena varianta č. 2. Co se má dít v případě varianty č. 3 se tam neřeší.

[pht]

Co se má dít v případě varianty č. 3 se tam neřeší.

A kde se to řeší?

[Filip Jirsák]

Nikde, je to na volné tvorbě – samozřejmě při zachování syntaktických pravidel.

[pht]

No, a jaká jsou ta pravidla? Že to je FQDN nebo IP? :) Nic jiného z RFC nevyplývá, žádný jiný smysl ani ten příkaz nemá, a určitě by tam o tom nebyla celá pasáž, kdyby to bylo na libosti implementace. Pokud se chcete opírat o argument, že "contains" není "MUST", tak to nemá smysl dále rozebírat...

[Filip Jirsák]

No, a jaká jsou ta pravidla?

Že ta řádka neobsahuje CR nebo LF, je zakončena CRLF a má nejvýš 512 znaků.

„Contains“ skutečně není „MUST“, „SHOULD“ také není „MUST“. Celá pasáž je tam o případu, kdy obsahuje doménové jméno – ale definice EHLO připouští tři varianty: doménové jméno, pokud neexistuje rozumné doménové jméno, pak „SHOULD“ IP adresa, a z toho implicitně plyne, že existuje možnost „neexistuje rozumné doménové jméno a zároveň se nevyhoví tomu ‚SHOULD‘“. Pokud vy si myslíte, že autoři RFC chtěli napsat „MUST“ ale omylem napsali „SHOULD“, je to dost zvláštní výklad RFC…

[pht]

Takže když dostanu EHLO s něčím, co má tvar FQDN, ale nemá adresu (A záznam), což je v rozporu s mnou citovanou pasáží, tak bych si měl říct: aha! on chtěl poslat správné FQDN, ale zrovna asi žádné neměl, tak si řekl, že IP adresu by poslat měl, ale vlastně nemusí, tak se na to rovnou vykašlal a neposlal FQDN ale náhodně vygenerovaný řetězec, který má nanejvýš 512 znaků, atd. a zrovna náhodou vypadá jako FQDN, které nemá A záznam. Tak to je také trochu svérázný výklad, nemyslíte?

Myslím si, že pokud by RFC nějakou třetí možnost připouštělo, tak by tam byla jednoznačně popsána. Implicitní možnosti, hlavně takové, které popírají smysl téže pasáže, se v takových dokumentech moc nenosí. Pokud chcete, zeptám se na to přímo autora nebo lidí co to RFC implementují.

A už vůbec nevidím důvod k tomu, aby k té nejednoznačné implicitní třetí variantě někdo nastavil svůj server.

[melkors]

"... společnost má kontrolu nad svým DNS ..."

A kdyz nema? Resp. ISP na nejake DNS z vysoka ...?

Znam takove priklady z vlastni praxe a vim, ze je potom docela problem s dorucovanim mailu - a to jsem si jen chtel nechat posilat denni vysledky watchlogu.

[petr_p]

HELO má sloužit k identifikaci stran. Pokud tam klient pošle nějakou blbost, tak sice můžete spojení odmítnout (jako kdykoliv jindy), ale je to čistě z vaší zvůle, nikoliv kvůli porušení protokolu.

Že to někdo používá jako charakteristiku spammera, je fakt jeho nesprávná úvaha, která s sebou vezme i kvanta ostatní regulérní pošty.

Kdyby se ukázalo, že spammer posílá „helo“, kdežto stabilní stroje obvykle „HELO“, tak byste se tím taky řídil?

Co uděláte, když vám padne DNS resolver? Budete veškerou poštu odmítat?

[pht]

která s sebou vezme i kvanta ostatní regulérní pošty.

Mám zkušenost opačnou. Hromada zamítnutého spamu (celkem zadarmo) ale občas i ten nějaký mail. Bohužel kvůli tomu jednomu, co si neumí nastavit server, musím přijímat i ty spamy.

Co uděláte, když vám padne DNS resolver? Budete veškerou poštu odmítat?

Tak jelikož je DNS součástí normálního fungování internetu, tak bude pošta jen jeden z mnoha problémů které nastanou. Nemluvě o tom, že pošta nepůjde zejména odesílat, tak korektní SMTP server při chybě DNS příchozí zprávy odmítá s kódem dočasné chyby, tj. přijde to později, až bude DNS fungovat.

[xkucf03]

Na druhou stranu by to prakticky vyřešilo problém se spamem:

1. vyžádat si plně kvalifikované jméno v EHLO
2. najít si k němu MX záznamy
3. pokud mezi nimi není IP adresa, ze které mail přichází, tak ho nepřijmeme

Spammeři by si museli pořizovat vlastní domény a posílat z IP adres ke kterým existují MX záznamy… neříkám, že by to nedělali, ale do blacklistů by se pak dostávaly rovnou celé jejich domény (ne jen IP adresy) a to by spam dost omezilo.

[Dračík]

No, a co když je odesílatel host a ne doména? Takový žádné MX záznamy mít nebude a zahazovat je přece taky nemůžete...

[pht]

To asi není úplně dobrý nápad, protože mail lze posílat přes různé relay, kde obecně nemusí sedět IP adresa odesílajícího serveru s IP adresou přijímajícího serveru.

[Filip Jirsák]

V diskusi o spamu přijde pokaždé někdo s tímhle nápadem, a pokaždé je mu třeba vysvětlovat, že odesílání e-mailů s adresou odesílatele z nějaké domény nemusí mít zhola nic společného se serverem přijímajícím poštu pro tutéž doménu.

[xkucf03]

1. Což ale nebrání tomu, aby odesílací server (brána) měl také MX záznam, ale s tak nízkou prioritou, že na něj nikdy nedojde řada (a kdyby přece jen došla, mail může odmítnout a pak se za chvíli zkusí zase servery s vyšší prioritou).
2. Není to systémově moc hezké řešení → takže by bylo dobré přidat typ DNS záznamu, který by říkal, že daná IP je oprávněna použít toto doménové jméno v HELO/EHLO
3. Pokud bychom chtěli být opravdu radikální, mohli bychom vyžadovat shodu mezi doménou v e-mailové adrese odesílatele a doménou použitou v EHLO (nepřímo tedy i s IP adresou odesílajícího serveru). S tím samozřejmě narazíme v takových případech, kdy lidé běžně odesílají maily např. ze své školní adresy přes SMTP svého poskytovatele, kde se domény samozřejmě neshodují. Řešením by bylo, udělat tuto kontrolu volitelnou – ze strany majitele domény – to by se opět dalo řešit přes DNS – pokud by zde byl určitý záznam, přijímající server by měl (nebo musel) odmítnout zprávy z jiných než (v DNS) vyjmenovaných IP adres.
   Pak by např. banky nebo ministerstva mohly říct, že zprávy s jejich doménou v e-mailové adrese se smí posílat pouze z vyjmenovaných IP adres (jejich brány) a jiné organizace by zase tuhle kontrolu nemusely vynucovat a umožnili by svým uživatelům posílat e-maily s danou doménou v adrese i z jiných SMTP serverů (poskytovatele, doma, na cestách).

[Filip Jirsák]

Což ale nebrání tomu, aby odesílací server (brána) měl také MX záznam, ale s tak nízkou prioritou, že na něj nikdy nedojde řada (a kdyby přece jen došla, mail může odmítnout a pak se za chvíli zkusí zase servery s vyšší prioritou).

Ten váš „odesílací server“ může být klidně Thunderbird nebo jiný klient schovaný za několikanásobným NATem. A může být v síti nějakého „WiFi ISP“, a vy z něj přitom budete posílat e-mail jako zaměstnanec nějaké mezinárodní společnosti s její doménou v adrese odesílatele.

Není to systémově moc hezké řešení → takže by bylo dobré přidat typ DNS záznamu, který by říkal, že daná IP je oprávněna použít toto doménové jméno v HELO/EHLO

Můžete popostoupit ještě o krok dál a uvědomit si, že nějaká doména uváděná v HELO/EHLO je úplně k ničemu, že důležitá je adresa odesílatele. Takže spojte doménu odesílatele, IP adresu odesílatele a kontrolu proti odpovídajícímu speciálnímu záznamu v DNS – a právě jste vymyslel SPF, i se všemi jeho neduhy.

Pak by např. banky nebo ministerstva mohly říct, že zprávy s jejich doménou v e-mailové adrese se smí posílat pouze z vyjmenovaných IP adres (jejich brány)

No vida, tak jste SPF nakonec vymyslel…

S tím samozřejmě narazíme v takových případech, kdy lidé běžně odesílají maily např. ze své školní adresy přes SMTP svého poskytovatele, kde se domény samozřejmě neshodují.

…a zároveň popsal i jeden z vážných problémů SPF. Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.

[xkucf03]

Ten váš „odesílací server“ může být klidně Thunderbird nebo jiný klient schovaný za několikanásobným NATem.

V takových případech se ale používá autentizované SMTP – povolit odesílání pošty komukoli (otevřená brána) bez ověření jména a hesla je sebevražda. SMTP serveru svého poskytovatele se tedy prokáži jménem a heslem a mail pak odchází ze serverů poskytovatele, které samozřejmě správné DNS záznamy mít budou.

A může být v síti nějakého „WiFi ISP“, a vy z něj přitom budete posílat e-mail jako zaměstnanec nějaké mezinárodní společnosti s její doménou v adrese odesílatele.

Pokud firma bude chtít povolit zaměstnancům posílat firemní maily i mimo firmu, zřídí jim (heslem chráněný) přístup k firemnímu SMTP serveru.

Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.

jj, DKIM vypadá zajímavě

[Filip Jirsák]

V takových případech se ale používá autentizované SMTP – povolit odesílání pošty komukoli (otevřená brána) bez ověření jména a hesla je sebevražda. SMTP serveru svého poskytovatele se tedy prokáži jménem a heslem a mail pak odchází ze serverů poskytovatele, které samozřejmě správné DNS záznamy mít budou.

Vy můžete ze svého klienta poslat e-mail rovnou cílovému serveru. To, že většina klientů je „hloupých“ a raději předají e-mail nějakému chytřejšímu serveru, který jej zase v roli klienta doručí na cílový server, neznamená, že to tak musí být vždy.

[xkucf03]

Tohle je věc dohody – podle mě by nebyla vůbec špatná konvence, že e-maily smí odesílat jen klient s příslušnými DNS záznamy. Výrazně by to omezilo problém botnetů odesílajících spamy. Cenou za to by bylo že bych si musel nastavit DNS záznam pro svůj notebook (když posílám přes svůj* postfix), což by nebyl problém, protože mám veřejnou IPv6 adresu, nebo bych použil SMTP server – buď svůj, nebo školní, nebo poskytovatele…Pořád mi to přijde jako přijatelná daň za ten boj proti spamu.

Pak jsou samozřejmě možné výjimky, kdy si např. ve své organizaci nastavím pravidla, že je možné posílat maily z jednoho stroje na druhý bez jakýchkoli omezení – je to moje síť, tak si tam ta pravidla určím já. Ale obecně na veřejném internetu by lepší mít striktnější pravidla. Chtělo by to ochranu proti spamu, která zprávu buď odmítne (vrátí) nebo doručí, ne jako teď, kdy se některé zprávy mohou ztratit, aniž by se o tom příjemce nebo odesílatel dozvěděl.

*) což je podobné, jako když někdo posílá mail rovnou z klienta na cílový server.

[Filip Jirsák]

Tohle je věc dohody – podle mě by nebyla vůbec špatná konvence, že e-maily smí odesílat jen klient s příslušnými DNS záznamy. Výrazně by to omezilo problém botnetů odesílajících spamy. Cenou za to by bylo že bych si musel nastavit DNS záznam pro svůj notebook (když posílám přes svůj* postfix), což by nebyl problém, protože mám veřejnou IPv6 adresu, nebo bych použil SMTP server – buď svůj, nebo školní, nebo poskytovatele…Pořád mi to přijde jako přijatelná daň za ten boj proti spamu.

To už by ale bylo něco zcela jiného, než je SMTP. Protože SMTP je založené právě na tom, že e-mail můžu odeslat odkudkoli a e-mail se bude doručovat co nejkratší možnou cestou k cíli. Protokol je možné samozřejmě změnit, ale v tom případě už by bylo lepší navrhnout pořádný nový protokol reflektující, kam se internet vyvinul, a ne jen do původního SMTP připlácnout nějakou další nelogickou změnu.

ne jako teď, kdy se některé zprávy mohou ztratit, aniž by se o tom příjemce nebo odesílatel dozvěděl.

Takové chování je v rozporu s RFC. Ale na rozdíl od mnoha jiných porušení RFC je tohle logické, protože pokud si server nemůže být jist, že odesílatel je pravý, je vysoká pravděpodobnost, že odesláním chybového e-mailu pošle ve skutečnosti spam. Logické by bylo třeba posílat chybové zprávy jako odpověď na e-maily, jejichž odesílatele se podařilo ověřit přes SPF nebo DKIM, ale to znamená zásah do organizace fronty zpráv v současných e-mailových systémech, takže to není tak jednoduché.

Navíc ale příslušné RFC požaduje, aby se všechny články po cestě maximálně snažily e-mail doručit a pokud to není možné informovali o nedoručení odesílatele, na druhou stranu e-mail nikdy nebyl koncipován jako služba se zaručeným doručením nebo zprávou o nedoručení, takže by na spolehlivost e-mailu neměl nikdo spoléhat.

[xkucf03]

na druhou stranu e-mail nikdy nebyl koncipován jako služba se zaručeným doručením nebo zprávou o nedoručení, takže by na spolehlivost e-mailu neměl nikdo spoléhat.

Ale vysvětluj to uživatelům, že se jejich e-mail zpozdil nebo nedejbože ztratil. Uživatelé si zvykli, že e-maily chodí spolehlivě a téměř okamžitě a jakoukoli odchylku od tohoto stavu berou jako chybu (přestože může být v souladu s původní zamýšlenou povahou SMTP). Takže by to chtělo buď nový protokol nebo přehodnotit pohled na SMTP.

Tím nezahazováním myslím hlavně to, že bychom měli maximum kontrol udělat během SMTP relace, kdy přijímáme mail od klienta nebo potencionálního spamera – v tu chvíli ho jde totiž bezpečně vrátit tomu, kdo ho posílá (ne někomu, kdo je jen uveden v hlavičce jako odesílatel). Ale když už ho přijmeme, tak ho doručit i přes podezření, že je to spam. Jasně, je tu problém, pokud jde mail přes více serverů, ale to už je pak problém těch serverů před námi, že např. mají špatně nastavené DNS.

[Birkof]

Ja to uzivatelum vysvetluji tak, ze to prirovnam k pozemni poste, kde take neni zaruceno ze se dopis doruci a take je o tom nikdo neinformuje. Nakonec SMTP protokol byl odvozen od pozemni posty a podobne jako dopis je mozne poslat s dorucenkou, jde to i s e-mailem.

[xkucf03]

…a zároveň popsal i jeden z vážných problémů SPF. Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.

Tak jsem se na to trochu kouknul a alternativou k SPF je DKIM Author Domain Signing Practices – ten umožňuje ostatním říct, že maily z mojí domény musí být podepsané, což je jako kdybych řekl, že maily z mojí domény musí pocházet z vybraných adres. Každé má svoje – DKIM mi přijde pružnější (jednou nastavím DNS a pak si jen nahrávám klíče na potřebné servery) a u SPF je zase mnohem jednodušší zkontrolovat, z jaké IP adresy mail přichází (než ověřovat elektronický podpis).

Osobně se mi ale dost líbí přístup, kdy majitel domény definuje pravidla, odkud* mohou být maily z jeho domény posílány – a pak je na něm, aby svým uživatelům poskytl např. vhodný SMTP server nebo webmail.

*) ať už IP adresy nebo podpisy.