Opravdu správně nastavený mailserver?

13.5.2011 14:53 | Linux | poslední úprava: 15.5.2011 13:57

Ani nevím proč, ale tak namátkově jsem si vyparsoval log jednoho mého mailserveru abych si prošel nejčastější chyby, proč jsou některé příchozí maily Postfixem odmítnuty. Pro jednoduchost jsem se omezil pouze na české servery, kterých je u mne většina (když pominu spam). Nebudu jmenoval žádné konkrétní ISP, hostingy ani firmy. Ale byl jsem překvapen, kolik všemožných "vesnických providerů", eshopů, firem, autoservisů a jiných má špatně nastavený svůj mailserver a příslušné DNS.

Chtěl bych apelovat na každého "správce", aby se zamyslel a podíval se do konfigurace svého serveru stroje a ověřil si, že opravdu jeho stroj se prezentuje tím jménem, které vrací MX záznam jeho domény a že reverzní DNS IP adresy serveru se resolvuje na jeho FQDN. Můj error log by tak byl kratší a počet doručených mailů vyšší. :)        

Komentáře

[Filip Jirsák]

V HELO má být celé doménové jméno klienta, pokud klient takové smysluplné jméno má. S MX záznamem to nesouvisí.

[pavlix]

V HELO má být celé doménové jméno klienta, pokud klient takové smysluplné jméno má. S MX záznamem to nesouvisí.

Můžeš obejít všechny adminy, kteří používají DNS jako první stupeň antispamového řešení a ukecat je ke změně :).

[msk]

S reverzami som mal permanentne problemy, nakoniec som to "vyriesil" migraciou do google apps.

[pavlix]

Reverzy stačí jednoduše nastavit a problémy zmizí.

[azurIt]

Mozno by si sa mal prave ty pozriet na nastavenie svojho serveru, pretoze ziadne RFC pre SMTP nehovori nic o reverznych zaznamoch. Admini, ktori na zaklade tohto odmietaju e-maily, su prave ti, ktori vytvaraju chaos a problemy. A nasledne aj najviac vykrikuju a ukazuju na ostatnych ;)

[pavlix]

Mozno by si sa mal prave ty pozriet na nastavenie svojho serveru, pretoze ziadne RFC pre SMTP nehovori nic o reverznych zaznamoch.

Možná byses měl podívat na okolní svět a smířit se s tím, že RFC v antispamových technikách jaksi nestíhají.

Admini, ktori na zaklade tohto odmietaju e-maily, su prave ti, ktori vytvaraju chaos a problemy.

Admini, kteří nemají nastavené DNS podle současných zvyklostí (ano, bohužel to nelze vyřešit pouze pomocí RFC), jsou ti jediní, kteří ty problémy mají :).

A nasledne aj najviac vykrikuju a ukazuju na ostatnych ;)

Mno, oni to většinou nemají zapotřebí. Ostatní se prostě přizpůsobí. Naposled jsem v doporučění jedné stránky hodnotící mailservery (shodou okolností má něco společného s ciskem), našel, že vyžadují, aby na mailserveru byla platná webová stránka odlišná od výchozí stránky Apache a jinách.

To mi řekni, co pak říkáš na takovýto požadavek? :)

[xkucf03]

že vyžadují, aby na mailserveru byla platná webová stránka odlišná od výchozí stránky Apache a jinách.

WTF? A k čemu je to dobré?

Vyžadovat mohou*, ale to je jejich problém. IMHO akorát další zbytečná buzerace, která ničemu nepomůže (aneb spameři se rychle přizpůsobí, bude-li třeba, a ostatní s tím budou mít akorát zbytečnou práci navíc).

Ono když má někde jeden server a na něm všechno, tak je celkem samozřejmě tento požadavek splněn. Ale ve větších konfiguracích to naopak většinou neplatí – poštovní server se stará o poštu a není důvod na něm pouštět ještě http démona.

*) prostě jejich uživatelé budou mít smůlu a nebude jim chodit důležitá pošta (pravda, spam, alespoň zpočátku, taky chodit nebude). Asi jako když se mi před časem vrátil nějaký mail, prý že jsem na blacklistu nějaké stupidní firmičky – to mne ale vůbec nezajímá, nic s nimi řešit nebudu – jejich škoda, že si nepřečtou moji poštu. (kdyby se jednalo o nějaký obecně uznávaný blacklist a byla by to moje vina, tak to samozřejmě řešit budu)

[trekker.dk]

IMHO akorát další zbytečná buzerace, která ničemu nepomůže

Náhodou by to mohlo odfiltrovat spamovací boty na uživatelských stanicích - většinou jsou za nějakým FW nebo mají rovnou nesměrovatelnou IP, takže bot prostě nemá šanci tu stránku vyrobit. Nicméně ani tak to nepovažuju za dobrý požadavek.

prý že jsem na blacklistu nějaké stupidní firmičky

Je dobré se aspoň podívat za co...

[pavlix]

Vyžadovat mohou*, ale to je jejich problém.

Jo, až ti budou psát zákazníci, že jim nechodí maily, ještě pořád si budeš myslet, že to není tvůj probém?

IMHO akorát další zbytečná buzerace, která ničemu nepomůže

S tím souhlasím. Ale popravdě řečeno to ještě spadá do kategorie věcí, kterým jsem ochoten se přizpůsobit, než abych proti nim aktivně bojoval.

Ono když má někde jeden server a na něm všechno, tak je celkem samozřejmě tento požadavek splněn.

To musí daná adresa na něco ukazovat (obvykle webmail).

Ale ve větších konfiguracích to naopak většinou neplatí – poštovní server se stará o poštu a není důvod na něm pouštět ještě http démona.

No vzhledem k tomu, že se podle dostupných informací jedná i o Cisco, se spousta větších konfigurací prostě přizpůsobí.

(kdyby se jednalo o nějaký obecně uznávaný blacklist a byla by to moje vina, tak to samozřejmě řešit budu)

Pokud jsou produkty Cisco z tvého pohledu dostatečně významné...

(aneb spameři se rychle přizpůsobí, bude-li třeba, a ostatní s tím budou mít akorát zbytečnou práci navíc)

Mimochodem tohle je mylný předpoklad. Spameři se obvykle zaměřují na kvantitu, takže se přizpůsobují tak nějak selektivně. I obyčejný greylisting je v současné době překážkou pro většinu spamu.

[azurIt]

Možná byses měl podívat na okolní svět a smířit se s tím, že RFC v antispamových technikách jaksi nestíhají.

jasne, tak si vsetci naimplementujme a vyzadujme akesi pseudo-standardne pravidla, co na tom, ze polka sveta o nich ani nebude vediet ;) vsetky RFC mozeme teda uplne vyhodit, ved si vystacime bez nich - uzasna logika.

[pavlix]

jasne, tak si vsetci naimplementujme a vyzadujme akesi pseudo-standardne pravidla, co na tom, ze polka sveta o nich ani nebude vediet ;) vsetky RFC mozeme teda uplne vyhodit, ved si vystacime bez nich - uzasna logika

A chceš si o té své úžasné logice povídat?

[Heron]

To mi řekni, co pak říkáš na takovýto požadavek? :)

Pičovina nejvyššího kalibru

Z jakého důvodu bych měl na mail serveru (nebo na jeho adrese) provozovat web server, když jej k provozu poštovních služeb vůbec není potřeba?

[pavlix]

Pičovina nejvyššího kalibru

Z jakého důvodu bych měl na mail serveru (nebo na jeho adrese) provozovat web server, když jej k provozu poštovních služeb vůbec není potřeba?

Tak až se ti podaří jim to vysvětlit a tenhle požadavek vyřadí, dej mi vědět.

[Heron]

Typické. Odpovíš na ten dotaz?

Ty si vážně myslíš, že ten požadavek je legitimní a má šanci na úspěch? Všechno to, o čem se hádáme v tom druhém flame nějak souvisí s nastavením samotného mailserveru (odmítání na základě různého chování vzdáleného smtp). Ovšem požadavek, že na ip mailserveru musí běžet ještě zcela jiná služba (která ani teoreticky nesouvisí s provozem emailů) a dokonce nějak konkrétně nastavená už je zcela mimo mísu. To je prostě cílená snaha odstavit smtp provoz jako takový (místo nastavování popičistických požadavků se prostě bude používat něco jiného, nebo jim na to každý bude srát).

[pavlix]

Typické. Odpovíš na ten dotaz?

Proč já?

Ty si vážně myslíš, že ten požadavek je legitimní a má šanci na úspěch?

Na první otázku odpovídám ne (není legitimní), na druhou otázku ano (má šanci na úspěch).

[SPM]

Skoro mam pocit, jestli někde nebylo nějaký RFC říkající, že servery by ty DNS jména s reverzama měli mít nastavené... ale ruku do ohně za to nedám a hledat to jsem líný, tak radši nic tvrdit nebudu :)

[vlastik]

Přesně tak, teď se mi to nechce hledat, ale v RFC to je. MTR musí mít PTR záznam na IP.

[azurIt]

kravina :)

[SAM:]

V RFC 1912: Common DNS Operational and Configuration Errors v oddíle 2.1 se píše následující: "Make sure your PTR and A records match.". Uvedeno je to v obecné rovině, ale mně z toho pro SMTP MTA tedy vyplývá: A <> PTR => error.

[Luk]

Tohle se velmi zhusta porušuje. Dá se říct, že mu nevyhovuje prakticky žádný webhostingový server, protože jedna IP adresa má hromadu A záznamů a proti tomu jediný (případně žádný) PTR záznam, který se mnohdy neshoduje s žádným A záznamem. Jenže zase pokud by měl být pro každý A záznam odpovídající PTR protějšek, tak budou odpovědi na PTR dotazy obludně velké. Jinak mimochodem RFC 1912 je z kategorie Informational, takže ho nelze brát za standard.

[SPM]

Ono to jenom říká, že PTR musí odpovídat A záznamu... tedy vemu si IP toho serveru, podívám se na revers a k reversu zpět IP adresu a mám dostat to samé. To kolik dalších záznamů ukazuje na jednu IP adresu je jedno..

[SAM:]

Hovoří se tam pouze o A záznamech a pro ně jsou definovány. Pro virtualhosting se většinou používají CNAME záznamy, které ukazují na konkrétní A záznam (s příslušným PTR).

[Luk]

Pro virtualhosting se většinou používají CNAME záznamy, které ukazují na konkrétní A záznam (s příslušným PTR).

To je pravda jen částečně - v podstatě jde o situace, kdy webhoster spravuje i DNS pro dané domény, a to ještě ne vždycky. V případech (kterých není vůbec málo), kdy je DNS u někoho jiného, se pro L2 domény standardně používají A záznamy.

[pavlix]

Hovoří se tam pouze o A záznamech a pro ně jsou definovány. Pro virtualhosting se většinou používají CNAME záznamy, které ukazují na konkrétní A záznam (s příslušným PTR).

To by fungovalo, pokud by neplatil zákaz CNAME pro samotnou zónu.

[azurIt]

a ako to suvisi so SMTP ? :) ukaz mi RFC pre SMTP, ktore hovori, ze pre korektne dorucenie posty je vyzadovany reverzny zaznam. nemiesaj, prosim, hrusky a jablka, ty si si proste naseil nejake RFC, kde to doporucuju (nie vyzaduju, vid. nizsie) a spojil si si to so svojimi tvrdeniami ;)

For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

[SPM]

To je právě to - se SMTP to nemá nic společného - takovej stroj by prostě v DNS vůbec bejt neměl :) slovo should be mi opravdu nepřijde jako udělejte si to jak chcete... to pak rovnou můžete přijít s tim, že vlastně oni sami RFC jsou jenom nějaké doporučení jak to dělat...

[azurIt]

to pak rovnou můžete přijít s tim, že vlastně oni sami RFC jsou jenom nějaké doporučení jak to dělat...

S tymto nesuhlasim, cital si niekedy nejake ? V takmer kazdom RFC su veci, ktore su vyslovene vyzadovane (must be) a veci, ktore su len doporucovane (should be).

[wtfjakovocode]

precti si znovu na co reagujes a nemel picoviny od veci

[Kvakor]

Také mám silný pocit, že existence reverzního DNS záznamu shodného s dopředným je doporučována, i když ne vyžadována (tj. "should", ne "must").

[Petr Bravenec]

Tenhle zápisek je zmatený blábol.

Většina mých mail serverů vyřizuje poštu pro několik různých domén. To se má server představovat podle toho, jakou poštu zrovna doručuje?

[SAM:]

S tím HELO jsem byl poněkud nepřesný. Měl jsem namysli situaci kdy server hlásí: mailer.mojefirma.cz.local, ale ve skutečnosti je to mailer.mojefirma.cz. Rozhodně jsem tím nechtěl říct, aby měnil svoje jméno podle toho z jaké domény zrovna doručuje mail. Za nedorozumění se omlouvám.

[Petr Bravenec]

Ano, mailer.mojefirma.cz.local je blbina. Ale trvat na shodě reverzního záznamu a jména v HELO je taky blbina. Příklad z praxe:

Na IPv4 obhospodařuje reverzní záznam IPS, se kterým není domluva - jednou možná technika přemluvíte, aby vám nastavil reverzní záznam, ale dalšímu se to nezdá, tak vám to za pár dní přepíše tak, jak to mají všichni ostatní. Zopakujete to párkrát... a pak už to vzdáte.

Dopředný záznam si obhospodařuji sám, takže ten je ok. Server se představuje ok.

Na IPv6 mi obhospodařuje reverzní záznam jiný ISP (tunel), se kterým je domluva lepší, takže tam si můžu nastavit záznam vlastní.

Server má stejné jméno v SMTP, ve forward DNS na IPv4 i IPv6 i v reverzním DNS na IPv6... jenom reverzní IPv4 je nastavené na ip-230.921.22.clients.extra-super-isp.cz - fakt se mám přizpůsobit reverznímu záznamu a zmršit si tak ten zbytek?

Jiný příklad - na notebooku mám nastavený pro doručování vlastní MTA. Na IPv6 v pohodě, na IPv4 jsem obvykle za NATem - a nejsem tam sám. Je-li za NATem více MTA, který je ten pravý? Mají se jmenovat všechny stejně? Měl bych v každé síti přestavět svůj MTA nebo snad zjistit, jaký smtp server konkrétní ISP doporučuje svým zákazníkům a používat ten (přestavět poštovního klienta)?

[R]

Kazdy seriozny ISP ti (spravidla zadarmo a bezodkladne) nastavi reverzny DNS zaznam. Ak to nevie/nechce, tak to nie je ISP vhodny pre prevadzku serverov.

Z notebooku mas posielat mail cez SMTP server, ktory prislucha k danej mailovej adrese (samozrejme s autentifikaciou a sifrovanim). Maily posielane priamo z roznych dial-up a dynamickych ADSL pripojeni casto skoncia nedorucene alebo v spame (vid. spamhaus PBL).

[Petr Bravenec]

Praktici poštu posílají a přijímají. Teoretici píšou zápisky do blogu, proč to tak nemá fungovat...

[SPM]

No, ISP který neumožní změnu reverzních záznamů a hostuje servery by se měl někam nakopat. A ad 2) ono dneska provozovat na desktopu (navíc mobilním) MTA, který doručuje zprávy rovnou je dost nereálné... ať se to může komu chce (ne)líbit jakkoliv, realita je že ze spousty sítí se nedá připojit na jiný, než ten jeden lokální SMTP server (teda alespoň ne na port 25...)

[SAM:]

Já používám pro odesílání pošty z notebooku odkudkoliv SMTP+SSL+AUTH na portu 465. Zatím jsem nenarazil na to, že by někde byl port 465 blokován. Kdyby takto situace nastala, tak mám ještě v záloze OpenVPN.

[pavlix]

A když je blokováno úplně všechno, funguje jen DNS, tak zbývá ještě DNS tunelování :).

[SAM:]

jasně, zrovna před týdnem jsem řešil IPv4 over DNS, zkoušel někdo IPv4 over ICMP?

[pavlix]

DNS funguje na víc místech než ICMP.

[pavlix]

Praktici poštu posílají a přijímají. Teoretici píšou zápisky do blogu, proč to tak nemá fungovat...

Podle předchozího zápisku tě tipuju na těžkého teoretika.

[rADOn]

S timhle musim souhlasit – pokud budeme ignorovat vsechno co nekdo, nekde, dokaze zkurvit, tak zadny internet nebude. Pokud je nekdo ochotny nakupovat od takovych zkurvitelu sluzby, pak musi byt ochotny nest riziko ze se s nim slusne vychovany zbytek netu nebude bavit.

[pavlix]

Asi tak.

[pavlix]

Na IPv4 obhospodařuje reverzní záznam IPS, se kterým není domluva - jednou možná technika přemluvíte, aby vám nastavil reverzní záznam, ale dalšímu se to nezdá, tak vám to za pár dní přepíše tak, jak to mají všichni ostatní. Zopakujete to párkrát... a pak už to vzdáte.

To vzdávání nedoporučuju. Naopak, tyhle takyadminy prudit, prudit a prudit... až se to naučí dělat správně. Pokud to nepomůže, tak jít o úroveň výš, a šéfové třeba naberou kompetentní lidi.

Server má stejné jméno v SMTP, ve forward DNS na IPv4 i IPv6 i v reverzním DNS na IPv6... jenom reverzní IPv4 je nastavené na ip-230.921.22.clients.extra-super-isp.cz - fakt se mám přizpůsobit reverznímu záznamu a zmršit si tak ten zbytek?

Některé blacklisty si všímají těchto zmršených reverzních záznamů, takže nedoporučuju. Spíš doporučuju opravit reverz a správnost reverzu přidat do monitoringu a při každé změně okamžitě volat providerovi.

Jiný příklad - na notebooku mám nastavený pro doručování vlastní MTA. Na IPv6 v pohodě, na IPv4 jsem obvykle za NATem - a nejsem tam sám. Je-li za NATem více MTA, který je ten pravý?

Neautentizované MTA za NATem jsou první adepti na blokaci, naprostá většina z nich jsou SPAMboti.

Takže toto už vůbec nedopoučuju a místo toho je lepší použít veřejnou IPv4.

[Kvakor]

Je omluvitelné, když mailserver nemá shodný dopředný a reverzní DNS záznam, protože jsou poskytovagtelé, kteří vám ho správně nenastaví, i kdyby čert na koze jezdil. Ale hodnota HELO je plně nastavitelná v konfiguraci mailserveru a pokud se tam vrací nějaké blbost, která nejenže neodpovídá DNS záznamům, ale ani to není FQDN, tak je to chyba pouze přslušného admina.

A ano, setkal jsem se se servery, které vracejí hlouposti (často jméno serveru nebo firmy), včetně několika, které vraceli cosi, co vypadalo spíš jako výsledek kočičí procházky po klávesnici, v jednom případě by dokonce ona kočka musela mít elpsoň osm nohou a/nebo tanec svatého Víta, protože nesmyslný řetězec byl nejméně třicet znaků dlouhý

[MMMMMMMMM]

Podobné zkušenosti mám i já. Nejvíce zmršených nastavení (mail)serverů jsem viděl na platformě Windows, možná jen náhoda?

[SAM:]

Ano, přesně to .local je záležitostí MS Exchang. ADS totiž vyžaduje při vytváření domény, aby byla zadána ve tvaru "neco.tld". Pokud admin zadá jen "neco", tak ADS asi automaticky přilepí ".local". Musel jsem se v tom vrtat asi jen 2x, když tak mne někdo prosím upřesněte. Dobré zmatky, pak musejí nastat, když má firma hostováno "neco.tld" někde venku a nechá si nasadit ADS také s doménou "neco.tld".

[davadu]

Pokud si dobře pamatuji z nějakých příruček, tak doporučovaný postup pro AD je opravdu zadávat vnitřní doménu neco.local.

Většina firem pak používá vnitřní doménu jako firma.local a na venek se tváří jako firma.tld (cz, com, atd). Ono je to poměrně jednoduše nastavitelné na Exchange serveru, že se hlásí jako mail.firma.cz zvenku a zevnitř jako mail.firma.local.

V AD pak firma.local dělá menší bordel než když se nastaví AD jako firma.cz.

[pavlix]

Moje doporučení je nepoužívat (nezneužívat) .local nikdy na nic jiného než multicast DNS, jinak mDNS nepůjde na těch počítačích používat.

V AD pak firma.local dělá menší bordel než když se nastaví AD jako firma.cz.

Pro některé vývojáře/manažery by bylo vhodné znovuzavést fyzické tresty.

[pavlix]

Většina mých mail serverů vyřizuje poštu pro několik různých domén. To se má server představovat podle toho, jakou poštu zrovna doručuje?

Směšuješ dvě nesouvisející věci. DNS jméno nameserveru se nemusí shodovat (a obvykle neshoduje) s doménou pro poštu.

[SAM:]

Jeden by neřekl, jak nevinný blogpost rozpoutá skoro světovou válku Myslím, že kdo chce s vlky býti, musí s nimi výti - aneb silnější pes mrdá. Takže, bez ohledu na should be/must be v RFC, když okolní svět používá kontrolu A a PTR při navazování SMTP spojení jako docela efektivní metodu proti šiřitelům spamu, tak by bylo dobré se toho držet a pomoct tak v boji se spamem. - IMHO - nikomu to ale nenutím.

[azurIt]

Ak to nechces nikomu nutit (tak, ako pises), nemal by si e-maily z takych IPciek odmietat ale napriklad len im prihodit par bodov v spam filtroch. Bude to urcite podstatne korektnejsie riesenie.

[SPM]

To je otázka... pokud je odmítne, odesílatel se o tom dozví a má co hodit svému ISP na hlavu a ten to může opravit... pokud bude jen přidávat skóre, při nevhodných dalších věcech skončí spousta mailů od těchto lidí tiše v /dev/null a nikdo se to už nedoví... koneckonců, PTR by si vážně mohl nastavit každý (kdo provozuje server)...

[azurIt]

Ale tu predsa nejde o to, ze by si to mal alebo mohol nastavit kazdy, nejde tu ani o to, ze jeho nastavenie je malickost a praca na par minut. Proste odmietanie e-mailov na zaklade chybajuceho reverzneho zaznamu nema absolutne ziadnu logicku. DNS predsa vobec nesuvisi so SMTP, su to dva uplne rozdielne protokoly a naozaj nechapem, preco pouzivat jeden na filtrovanie druheho. Mozes mi povedat jediny dovod, preco by mal byt z pohladu SMTP nastaveny reverzny zaznam ? Aky to ma pre SMTP zmysel ?

[SAM:]

Porovnání A a PTR záznamu stroje dovoluje s velkou důvěryhodností ověřit identitu stroje, který se mi snaží doručit mail. A právě proto, že DNS vyžaduje registrovanou doménu, existující 2 DNS serveru (ideálně s DNSSEC), zavedený A záznam a od ISP nastavený reverzní záznam k onomu A záznamu, tak je to dost podmínek, které je potřeba splnit. Proto může být důvěra v tuto identitu poměrně vysoká. I když pominu toto, tak prosté zavedení tohoto testu sníží objem doručovaného spamu cca o 60% - a to se vyplatí - protože jinak všechny tyto spamy musí řešit spamassassin a to je docela náročné na procesorový čas. A nehledě na to, že dle RFC je doporučeno mít k A záznamu PTR záznam.

[xkucf03]

1. Co když někdo chce provozovat poštovní server, ale jeho ISP je neschopný/neochotný reverzní záznam zařídit?
2. Spam sice většinou pochází ze zavirovaných windows desktopů, ale často nebývá odesílán přímo, ale přes jiný SMTP server, který daný uživatel používá (spamer mu ukradne jméno a heslo).

Nakonec je stejně potřeba analyzovat obsah zprávy, protože jinak odřízneš legitimní odesílatele a zároveň ti stejně spousta spamu projde.

Další možností je DKIM/ADSP (v horším případě SPF) – tam je akorát potřeba spolupráce správců domén – aby si tuto politiku zavedli a zprávy podepisovali. Ovšem v případě, že se posílá spam přes jméno a heslo uživatele, tak to stejně nepomůže – ale aspoň to odřízne spamery, kteří by chtěli odesílat úplně odjinud.

A co se týče jména uváděného v HELO/EHLO – je normální a slušné dodržovat RFC/doporučení a nikoho neubude, když se jimi bude řídit. Ale upřímně: takovéhle „představování se“ je pěkná ptákovina a v tom protokolu by to vůbec nemuselo být – SMTP server zná IP adresu klienta a ta je podstatně zajímavější než nějaká posloupnost znaků za EHLO – protože tam si může kdokoli napsat cokoli, ta informace má nulovou hodnotu. Naopak nenulovou informační hodnotu má ta IP adresa nebo elektronický podpis (DKIM, S/MIME, GPG, klientský certifikát…). Takže dodržovat tohle doporučení a uvádět správné jméno: ano – je to slušnost. Ale vyžadovat jeho dodržování od ostatních je celkem na nic, protože každý si tam může napsat, co chce. Je to jako kdybych do obchodu pouštěl jen lidi, kteří řeknou: „Dobrý den“ a doufal, že se tak zbavím zlodějů (zloději jsou přece neslušní a nepozdraví), jenže to povede akorát k tomu, že zloděj slušně pozdraví a pak mě stejně vykrade – takže žádný přínos. Kontrola a řešení takových ptákovin akorát odvádí pozornost od jádra věci.

[trekker.dk]

Co když někdo chce provozovat poštovní server, ale jeho ISP je neschopný/neochotný reverzní záznam zařídit?

Změnit ISP. A btw. který poskytovatel VPS/housingu ti nenastaví reverzní záznam?

Spam sice většinou pochází ze zavirovaných windows desktopů, ale často nebývá odesílán přímo

Ne tak často.

Je to jako kdybych do obchodu pouštěl jen lidi, kteří řeknou: „Dobrý den“ a doufal, že se tak zbavím zlodějů (zloději jsou přece neslušní a nepozdraví), jenže to povede akorát k tomu, že zloděj slušně pozdraví a pak mě stejně vykrade

Tady je důležitý ten budoucí čas. Nebo jinými slovy - v podstatě říkáš, že nemá cenu zamykat auta, protože jednou někdo vynalezne přístroj na bezdotykovou manipulaci se stavítky zámku.

[xkucf03]

Změnit ISP. A btw. který poskytovatel VPS/housingu ti nenastaví reverzní záznam?

V praxi to tak dopadne, protože nemáš na výběr… Ale je mi to proti srsti – Internet má být síť rovnocenných uzlů – a jestli budou vystupovat v roli serveru nebo klienta je jen věcí konfigurace daného stroje.

Nebo jinými slovy - v podstatě říkáš, že nemá cenu zamykat auta, protože jednou někdo vynalezne přístroj na bezdotykovou manipulaci se stavítky zámku.

K tomu je ale potřeba nějaký důmyslný „šperhák“, nějaká práce. Jenže napsat EHLO xyz-123.example.com žádná práce není, není potřeba nic vymýšlet, nic to nestojí. Je to stejně na nic, jako kdybys před odemčením auta musel říct „Ahoj“ a pak teprve odemykat. „Ahoj“ může říct každý, tak nemá cenu se tím vůbec zabývat – místo toho je lepší řešit věci, které nějakou roli hrají – analýza obsahu, kontrola podpisů atd. – ne bezvýznamné ptákoviny.

[pavlix]

V praxi to tak dopadne, protože nemáš na výběr… Ale je mi to proti srsti – Internet má být síť rovnocenných uzlů – a jestli budou vystupovat v roli serveru nebo klienta je jen věcí konfigurace daného stroje.

Na akademické síti proč ne. Ale v komerční sféře holt musíš vybírat z nabídky.

[pavlix]

Další možností je DKIM/ADSP (v horším případě SPF) – tam je akorát potřeba spolupráce správců domén – aby si tuto politiku zavedli a zprávy podepisovali. Ovšem v případě, že se posílá spam přes jméno a heslo uživatele, tak to stejně nepomůže – ale aspoň to odřízne spamery, kteří by chtěli odesílat úplně odjinud.

DKIM je dobré právě v případě agresivního filtrování, kdy se odmítají (nebo ztrácí) maily. To je totiž velká motivace pro odesilatele zavést technologii, která jim přilepšuje.

DKIM navíc umožňuje psát whitelisty na domény (místo na servery), ale zase ho musí podporovat odesilatel.

[azurIt]

Nic z toho, co si napisal, nesuvisi so SMTP ako takym. Navyse odmietas e-maily bezdovodne na zaklade akychsi vymyslenych pravidiel. Velmi silno mi to pripomina rozne HTML/CSS 'vychytavky' v IE, ktore su pekne a ludom sa pacia ale nie su sucastou ziadneho standardu takze to v konecnom dosledku robi dost velky chaos (kedze ine prehliadace to, logicky, nepodporuju). Ale je to samozrejme tvoja vec, kludne prevadzkuj 'rozbity' SMTP server, mne je to sumafuk :)

[SPM]

Tak takovej protokol IP taky nemá se SMTP vůbec nic společného, tak doufám že na svym serveru nemáš nějaký firewall, který by ten provoz filtroval :))

[SPM]

Ne, souvisí to s tím, že každý slušný server na síti by ty DNS záznamy mít měl, nezávisle na tom, jaká na něm běží služba... a pak podobně jako zastánci greylistingu se můžeme bavit o tom, že to odrazí velké procento spamů (pač právě spameři si to kolikrát nastavit nemůžou). Akorát narozdíl od greylistingu tohle nebrzdí provoz slušných mailů a narozdíl od tebou navrhovaného řešení (přihodit pár bodů navíc) se o tomhle admin mailserveru, který spam nerozesílá, dozví a může to napravit (zatímco když maily se budou tiše mazat, přijde se na to dost těžko...)

[azurIt]

A co ma admin napravovat ? Chybajuci reverzny zaznam predsa nie je chyba, to sme tu uz prebrali - je to doporucovane, nie vyzadovane. Navyse to vobec nesuvisi so SMTP a ziadne RFC nehovori, ze e-maily z takej IP mas odmietat. Preco nutis ludi nastavovat si nieco, co nastavene byt nemusi ? Pretoze sa to tebe paci ? :)

[SAM:]

Není to chyba, ale z pohledu "současné nekodifikované kultury na síti" je to nedostatek. Myslím, že nastavení PTR nikomu, kdo to s doručováním pošty myslí vážně, nezpůsobí finanční/psychickou ani jinou újmu a na druhé straně výrazně pomůže globálnímu boji proti spamu. Nejde o to, že to nařizuje nebo vynucuje nějaké RFC, ale že to to tak lepší (úmyslně neříkám správné).

ISP typu Fanda Vesnický - MultiNAt s.r.o. je kapitola sama o sobě a výrazné české specifikum, ale myslím, že i tam jde domluvit nastavení PTR. Zatím jsem si nikdy nesetkal s tím, že by to nešlo. Třeba to chvíli trvá, ale vždy se po předložení rozumných argumentů dá domluvit. Samozřejmě, že s přístupem: "Hele, koukej navalit PTR záznam.", asi moc nepořídíme. Řešením je urychlit přechod na IPv6.

[xkucf03]

ISP typu Fanda Vesnický - MultiNAt s.r.o. je kapitola sama o sobě a výrazné české specifikum, ale myslím, že i tam jde domluvit nastavení PTR. Zatím jsem si nikdy nesetkal s tím, že by to nešlo. Třeba to chvíli trvá, ale vždy se po předložení rozumných argumentů dá domluvit.

Ono spíš u těch „vesnických ISP“ to jde, ale u velkých ISP ne – protože jsi pro ně prostě moc malý zákazník, aby s tebou ztráceli čas, případně se tě snaží natlačit do nějakého dražšího tarifu, kde tyhle „pokročilé“ funkce budou.

[SPM]

Což přiznejme si, že ADSL od O2 stejně není spolehlivá linka pro server :) Na druhou stranu, tihle velký ISP mají aspoň nějaký ten defaultní reverz (xyz.customers.company...) - žádná sláva, ale pokud se kontroluje jenom ten reverz, tak se s tím dá žít...

[pavlix]

Přimomínám, že některé blacklisty řeší právě známé automatické reverzy.

[pavlix]

Ono spíš u těch „vesnických ISP“ to jde, ale u velkých ISP ne – protože jsi pro ně prostě moc malý zákazník, aby s tebou ztráceli čas, případně se tě snaží natlačit do nějakého dražšího tarifu, kde tyhle „pokročilé“ funkce budou.

Proto máš nakupovat od dodavatelů, na které máš... a kteří jsou ochotni se ti věnovat. Proto i v Praze dávám přednost těm „vesnickým“ firmám, kterých je tu víc než dost.

[xkucf03]

Však já u nich nakupuji a jsem relativně spokojený , co jsem psal se týká lidí, kteří zůstávají u různých telekomů a podobně.

[pavlix]

Dobře, ale oni u těch telecomů zůstávají dobrovolně, i když tam nedostávájí odpovícající službu. A ty malé firmy působí i ve velkých městech, navíc některé velké firmy zvládají i práci s malými zákazníky.

[SPM]

Nj, takže když se někde píše "mělo by", tak je to dostatečný důvod, proč se na to vykašlat, pač je to práce, co? :) Osobně radši budu zahazovat maily a informovat o tom od lidí, kteří nedbají doporučení, než brzdit maily úplně všechny (GL) či zaměstnávat procesor neustále tím, že bude analyzovat hromady mailů, které by jinak ty jednodušší metody odmítli hned... Nevím, mysli si co chceš, ale přijímat maily od někoho, kdo si neumí ani nastavit DNS vážně nechci :))

[SAM:]

+1

[azurIt]

Uz som to tu pisal - ked chces mat sluzby, ktore su uplne mimo standardov, tak si rob co chces a chod si cestou MS a jemu podobnych 'babrakov' co sa RFC tyka. Prosim ta ale nesnaz sa svoje chyby ucit inych, pretoze v tomto proste pravdu nemas ani ked sa na hlavu postavis.

[SPM]

Zajímavé - takže teď mě přirovnáváš k MS, který na RFC úplně kašle a zároveň když připomenu, že RFC alespoň říká, že by něco tak být mělo, tak je ti to k smíchu, protože tam není slovíčko musí... A ano - lidem doporučuju, aby jejich server měl nastaven reverz (přestože je tu spousta lidí, které to ani nenapadne, když jim nikdo nenapíše "have to") a nehodlám v tom přestávat...

[azurIt]

Zjavne vobec nechapes terminologii pouzivanej v RFC a tiez vyznamom jednotlivych slov / fraz. Veci, ktore su doporucene, su tak oznacene preto, aby na nich nezaviseli dalsie klucove veci (to si si mohol aj logicky domysliet). Odmietat e-maily (tzn. znepristupnit sluzbu) kvoli polozke, ktora je doporucena, je zle. Navyse, znovu uz po X-ty krat opakujem, miesas dokopy rozne protokoly a od seba uplne nazavisle RFC.

[SPM]

Schválně by mě teda zajímalo, které RFC mi nakazuje, podle čeho smím nebo nesmím přijímat poštu... Když půjdeme do důsledku, tak ona v podstatě každá antispamová ochrana bude RFC porušovat, pač může mail odmítnout/smazat (a koneckonců on i ten spam je vlastně regulérně doručený mail). Zajímavé je, že temporary chyby na každý mail kvůli GL skoro nikomu nevadí, ale jakmile si někdo dokáže předpokládat, že každej slušnej člověk provozující server si nastaví korektně DNS záznamy, tak je hned za toho největšího zločince :)

[azurIt]

Spam filtre vacsinou postu triedia, nepoznam ziadneho seriozneho poskytovatela, ktory na zaklade filtrov spravy odmieta alebo priamo vymazava (takeho by som ani nechcel pouzivat). Docasne SMTP chyby su predsa 100% v sulade s RFC a SMTP protokol je na ne pripraveny tym sposbom, ze sluba zostane v sulade so standardom a plne funkcna (docasne chyby, ako aj spravanie SMTP servera, su presne popisane v danych RFC). Co sa ti na tomto akoze nezda ? :) Ty fakt vobec nechapes, o com cele RFC je, tato debata nema zmysel.

[trekker.dk]

Spam filtre vacsinou postu triedia, nepoznam ziadneho seriozneho poskytovatela, ktory na zaklade filtrov spravy odmieta alebo priamo vymazava

Prakticky všechny freemaily. Zprávy se sice nesmažou hned, ale za nějaký čas jo. A neřekl bych, že na to existuje nějaké RFC...

[SPM]

Otázka je, jak moc je košér, že to ty temporary chyby v podstatě hází za normálního stavu na úplně každej mail :) Nicméně těch poskytovatelů, kde se maily rovnou smažou (nebo až po nějakém čase) je IMHO docela dost... a konfigurací, kde když je odesilatel uveden na nějakém BL a mail je rovnou odmítnut bude taky docela dost...

[pavlix]

Zajímavé je, že temporary chyby na každý mail kvůli GL skoro nikomu nevadí, ale jakmile si někdo dokáže předpokládat, že každej slušnej člověk provozující server si nastaví korektně DNS záznamy, tak je hned za toho největšího zločince :)

Tady ses podle mě spletl. Podle mě jsou z naprosté většiny odpůrcy GL a odpůrci kontroly DNS jedni a titéž.

[SPM]

Tak minimálně já... GL nemám rád, nicméně kontrolu reverzu mám (odrazí mi to skoro všechen spam co do mé schránky chodí a psát si s někým, kdo si není schopný ani nastavit reverz stejně nechci :)

[pavlix]

Dovolím si tě považovat za výjimku. Z ostatních tradičních diskutujících na tyto témata už mě nikdo další nenapadá.

Jinak já používám kontroly prvků protokolu rád (třeba právě HELO včetně DNS kontroly) a jdu pragmatickou cestou. Nejdřív danou techniku nastavím, aby se jen logovala, pak se podívám, kolik spamů by to zastavilo a kolik regulérních mailů by to zastavilo, a teprv potom zvolím řešení.

Pravda je, že nenastavuju dvacet mailových serverů měsíčně.

Greylisting mám taky docela rád, takže na svém vlastním ho používám. U instalací pro cizí s ním dost váhám, ale skoro vždycky ho nabídnu (s vysvětlením výhod i nevýhod).

Pak jsou tu ty věčně kontroverzní RBL, ze kterých několik používám taky, čímž vykreju takovéty stabilnější spammery, kteří spíš projdou přes GL.

Jako jasně, jsem rozhořčený, když někdo používá antispam, který zachytí zprávy z mailserveru, co jsem konfiguroval já, ale nakonec mi nezbyde než problém řešit a reputaci zlepšovat v první řadě na svojí straně. Totéž doporučuju ostatním :).

[MMMMMMMMM]

RFC 1912

Make sure your PTR and A records match.  For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

[Filip Jirsák]

Ne, souvisí to s tím, že každý slušný server na síti by ty DNS záznamy mít měl, nezávisle na tom, jaká na něm běží služba...

Tady se ale řeší klienti…

[SAM:]

Celou dobu se snažím diskutovat o vhodnosti nastavení PTR u serverů!?

[SPM]

Klienti se tu IMHO neřeší vůbec - vzhledem k tomu, že dneska ve většině sítí je zakázána komunikace s jiným SMTP serverem, než tím jedním vyvoleným, tak to nemá smysl řešit - ten klient si stejně nepošle mail kam chce... Jiná diskuze je, jestli je to tak správně nebo ne - o tom se tu ale nebavíme...

[pavlix]

Tady se ale řeší klienti…

Vy vždycky řešíte něco jiného než ostatní :).

[Filip Jirsák]

Pro všechny tři – ten, kdo e-mail odesílá, kdo navazuje spojení, je v případě SMTP vždy klient. Nezáleží na tom, že je to služba, která se slangově označuje jako poštovní nebo e-mailový server. Třeba Postfix, když přijímá poštu od Thunderbirdu nebo Evolution, vystupuje v roli SMTP serveru, uloží e-mail do fronty, a když jej pak odesílá na cílový server, je SMTP klientem. Takže to, co se tady řeší, je nastavení SMTP klienta.

[pavlix]

Mám za to, že technickou stránku síťové komunikace všichni tři známe. Nicméně už se dávno nejedná o slang, v praxi se dnes rozlišuje i klientský a serverový počítač nejen navazující a poslouchající proces.

Váš problém je ten, že se za každou cenu snažíte si s ostatními nerozumět. A celkem se vám to i daří.

[xkucf03]

Ale vždyť má pravdu – jde o toho klienta. V danou chvíli je přece jedno, jestli ten stejný stroj (nebo proces démona, IP adresa, cluster atd.) vystupuje současně i v roli serveru (naslouchající na SMTP portu).

Ve větších konfiguracích to můžeš mít rozdělené – některé stroje slouží jako úložiště a IMAP/POP pro uživatele (IMAP/POP servery), na několik jiných serverů slouží pro příjem (SMTP servery, pro příjem zvenčí budou pravděpodobně jiné než pro interní uživatele), jinde běží webmail (HTTP server) a úplně jiné stroje můžou být vyhrazené pro odesílání pošty (SMTP klienti) a mezitím ještě stroje odvirovávače, spamfiltry, směrovače, archivátoři atd. Někdy je to jen víc procesů na jednom stroji, jindy to budou samostatné mašiny.

[pavlix]

Ale vždyť má pravdu – jde o toho klienta. V danou chvíli je přece jedno, jestli ten stejný stroj (nebo proces démona, IP adresa, cluster atd.) vystupuje současně i v roli serveru (naslouchající na SMTP portu).

Právě jde o to, jestli se bavíš o socketové úrovni nebo administrační úrovni.

úplně jiné stroje můžou být vyhrazené pro odesílání pošty (SMTP klienti)

Kdyby to byly výhradně SMTP klienti, tak bys přes to asi ze svého mailového programu neodeslal vůbec nic. Takže pokud už k tomu chceš přistupovat striktně podle soketů, tak důsledně a ne že si vybereš jenom druhou půlku než ostatní.

[xkucf03]

Už jsme hodně daleko od původního tématu a je to trochu slovíčkaření, ale stejně mi to nedá

Kdyby to byly výhradně SMTP klienti, tak bys přes to asi ze svého mailového programu neodeslal vůbec nic.

Ten stroj může sloužit výhradně k odesílání ven. Jako SMTP server pro poštovní klienty interních uživatelů bude vyhrazený zase nějaký jiný. Mezi tím může být jakkoli složitá infrastruktura, ale to je čistě věc dané firmy – vzhledem k Internetu je to čistě SMTP klient. Jak se na něj ty zprávy dostanou, je celkem jedno – může to být třeba přes MQ, databázi, souborový systém, nějaký jiný protokol… cokoli – ani to nemusí být SMTP, takže skutečně ten počítač (i démon/software na něm běžící) bude jen v roli SMTP klienta.

Stejně tak SMTP klientem může být webový server, diskové pole, jakékoli zařízení, které o sobě podává hlášení formou e-mailů…

[pavlix]

Právě to slovíčkaření dělá ten problém. Jedni používají termíny jako mailserver tak, aby si rozuměli, druzí trvají pouze na hlubokých technických detailech a pak jim uniká praktické fungování celé služby.

[Filip Jirsák]

Právě naopak. Jedni neznají pořádně ani termíny ani způsob fungování, a vyrábějí pak konfigurace, které dělají v doručování e-mailů nepořádek – jednak nedoručují spoustu normálních e-mailů, jednak často jejich servery rozesílají nevyžádané e-maily. Vzhledem k tomu chaosu si ani nevšimnou, že vlastně každý mluví o něčem jiném. Druzí pak chápou principy a nestává se jim, že by si pletli klienta a server.

[pavlix]

Budu považovat tvé argumenty za laciné ad hominem.

[Filip Jirsák]

Neznáte. Vy možná ano, ale zase se vymlouváte na to, že je v pořádku ty pojmy zamlžovat. Ne, v pořádku to není – podívejte se na vaše dva kolegy (a mnohé další), jaký v tom pak mají zmatek.

[pavlix]

Neznáte. Vy možná ano, ale zase se vymlouváte na to, že je v pořádku ty pojmy zamlžovat. Ne, v pořádku to není – podívejte se na vaše dva kolegy (a mnohé další), jaký v tom pak mají zmatek.

Vy mlžíte pořád a stejně vás máme rádi.

[SAM:]

Pokud zavedeme tuto terminologii, tak s tím souhlasím.

[SAM:]

Shodneme se:

že na úrovni socketu: MTA doručující email jinému MTA navazuje z libovolného portu TCP spojení pomocí volání connect() a tudíž je klient, zatímco MTA přijímající email poslouchá na portu 25, volání accept() a tudíž je serverem?

na úrovni služby email služby: MTA je serverem (accept() na portu 25) a MUA je klientem (connect() # => port 25)?

[Filip Jirsák]

To je terminologie zavedená v RFC 2821. Pokud se bavíme o SMTP, je logické používat právě tuto terminologii.

[Filip]

Zdravim,

ja a jiste i mnozi v tom nastaveni mailserveru adres a spojitosti s DNS nemaji uplne jasno. Pokud se v tom vyznate napiste prosim clanek v nemz by bylo uvedeno *primitivne* a strucne co a jak musi byt nastavene aby vse fungovalo.

Diky

[Luk]

Té otázce příliš nerozumím, jde o shodu příkazu HELO/EHLO se skutečnou adresou? Pokud ano, článek zabývající se mj. i tímto v souvislosti se serverem Postfix, jsem již napsal v rámci svého seriálu.