Dotaz: email problem

[Roman]

Mam dotaz ohledne nastaveni mail serveru. Vsiml jsem si ze emaily posilane ze serveru maji jako odesilatele oznaceno "unknown."

Presne to v hlavicce emailu vypada takto:

Received: from server.name.cz (unknown [xx.xx.xx.xx])

V tomto prikladu server.name.cz je spravny nazev mail serveru a xx.xx.xx.xx je spravna IP adresa smtp serveru. IP adresa xx.xx.xx.xx ma spravne nastaveny reverzni dns zaznam ukazujici na server.name.cz. Proc se tedy mail server identifikuje jako "unknown" ?

Mail server je exim. Je tam snad nejaka variable ktera je treba nastavit v exim.conf ?

Jet tam zaremovana variable primary_hostname, nastavil jsem ji ale beze zmeny.,. stale se mail server hlasi jako unknown. Vedel by nekdo ?

Odpovědi

[Jendа]

Posílá to na začátku komunikace HELO blabla?

[Kriegel]

Received header tam placne server, ktery ten mail prijmul.

podle toho, co jsi sem pastnul, se tvuj server identifikuje jako server.name.cz v HELO/EHLO.

Na remote server se connectuje z xx.xx.xx.xx, ktery neni ten remote server schopny resolvovat.

Zavada neni na tvoji strane (jako klienta) ale na strane serveru.

[Filip Jirsák]

Mail server se správně identifikuje jako server.name.cz. Cílový server se ale pokouší IP adresu vašeho serveru přeložit zpět na jméno (přes reverzní DNS záznam). Překlad se mu nepodaří, proto místo reverzního záznamu vypíše unknown. Teoreticky by to ničemu nemělo vadit, dnes si ale spousta "správců" mail serverů myslí, že reverzní záznam nemají jen spameři, takže e-maily od takových buď rovnou odmítají, nebo je označují za spam. Doporučuji tedy reverzní záznam k IP adrese nastavit -- udělá to vlastník/správce příslušné IP adresy, tedy váš ISP.

["Spravce"]

A dobre delaji. Posilat postu z adresy bez reverzniho zaznamu nebo dokonce s nesedicim reverznim zaznamem je stejne jako zkouset nekoho poblit. Taky to neni zakazano zakonem, ze

[Jendа]

Proč?

[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. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.

[Filip Jirsák]

To RFC pochází z doby, kdy při žádosti o IP adresu jste dostali nejméně celou C síť, a nikdo se na nic neptal. Samozřejmě to byly v dnešní terminologii veřejné IP adresy, privátní nebyl důvod používat. Virtualhost v HTTP ještě nebyl ve standardu a bůhví, zda už o něm někdo aspoň přemýšlel. No a takovýhle stav Internetu to RFC předpokládá a s takovým dává smysl. Jenomže dnes Internet vypadá dost jinak - a jaký má smysl třeba mít stovky PTR záznamů na jeden webserver?

[potato]

Inicioval jsi tedy změnu standardu?

‚Nebudeme se řídit RFC, protože se nám nelíbí/nehodí‘ je přesně přístup, který potřebujeme...

[Filip Jirsák]

Já ten standard neporušuju. Není v něm must ale should.

[lertimir]

Nicméně přesně o tomto je Postelovo pravidlo:

Be conservative in what you do, be liberal in what you accept from others.

Konzervativní princip je přesně mít PRT záznamy v pořádku. A také není žádný důvod totiž je v pořádku nemít. Pak to funguje jen proto, že někdo, kdo data přijímá, je méně liberální než by měl či mohl.

A je sice pravda, že v roce 96 nebyla zdaleka taková tlačenice o IP adresy, ale právě tedy se začaly projevovat praktické snahy na krátkodobé řešení adresního prostoru (CIDR, NAT jsou 1519, 1597 zroku 94).

• RFC - 1917. An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA
• RFC - 1918. Address Allocation for Private Internets
• RFC - 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS).

A mimochodem i možnost virtuálních hostů byla normotvorně zakotvena o 3 měsíce později v RFC - 1945 Hypertext Transfer Protocol -- HTTP/1.0. i když zatím ne povinně.

A proč PTR odkazy na stovky virtuálních hostů. Ty jsou v DNS jako CNAME a PTR je jen na A záznam.

[Filip Jirsák]

Odhadem alespoň polovina virtuálních hostů nemůže být v DNS uvedena jako CNAME – při typické kombinaci www.example.com + example.com můžete CNAME použít jen pro www.example.com, a i to může být dost často špatně. Takovéhle chyby jsou podle mne mnohem podstatnější, než neexistující reverzní záznam, který je prakticky stejně k ničemu.

[kdo je bazar]

Web me vubec nezajima, to je dnes uz jen reklamni kanal horsi nez televize, ale ten priklad s chybejicim reverzem u mail serveru sedi, to si musim zapamatovat. Jeste bych to mozna drze zkusil vylepsit: neprijetim posty z takove adresy prijdu presne o tolik, o kolik prijde restaurace, kdyz tam nevpusti smradlave pochcane bezdomovce.

[j]

+1

[pavlix]

Že jsou v návrhu DNS chyby, to je úplně jiná věc.

[Filip Jirsák]

Nikoli, jiná věc je to, kdo považuje kterou část za chybu. Někdo považuje za chybu CNAME záznam, někdo PTR záznam, někdo všechno kromě SRV…

[lertimir]

Pak to jsou lidé, kteří kašlou na ducha a myšlenku DNS a jen si pokouší zflikovat, co potřebují. DNS myšlenka je samozřejmě v tom, že DNS struktura adres je čistý strom, jehož jednotlivé listy se mapují 1:1 na IP adresy. To co je nedostatek, je že v době tvorby nikdo neuvažoval o tom, že může být i požadavek mít na IP adresu namapovaný i uzel toho stromu nejen list. A nad touto primární strukturou je synonymiální struktura přes CNAME.

[pavlix]

DNS myšlenka je samozřejmě v tom, že DNS struktura adres je čistý strom, jehož jednotlivé listy se mapují 1:1 na IP adresy

Nepřijde mi to vůbec samozřejmé. Popravdě řečeno nevidím důvod, proč by ostatní měli tvou myšlenku přijmout za myšlenku DNS a už vůbec mi nepřijde technologicky rozumné DNS na něco takového degradovat.

[lertimir]

No mýlit se jistě mohu, ale jaká je podle tebe hlavní idea DNS? Nebo co té myšlence 1:1 mapování listů odporuje?

[pavlix]

Já chápu DNS jako distribuovanou databázi, která umožňuje přiřadit datové objekty uzlům distribuovaného stromu, přičemž se uzly řídí nějakou organizační strukturou a listy typicky odpovídaly strojům, jichž se data v databázi měla především týkat. Adresu stroje vnímám jako klíčový údaj, který umožňuje se s daným strojem spojit, nicméně ne jediný údaj.

Dnes začíná převažovat podle mě nepříliš vhodné použití DNS, kdy se adresy přiřazují i uzlům, které vůbec fyzickým strojům neodpovídají a spíše odpovídají té organizační struktuře (například „pavlix.net“ není stroj, ale organizační doména, která sdružuje sadu osobních služeb či strojů).

To je bohužel vynuceno standardy jako je HTTP, které ztotožňují doménu služby se serverem, který službu poskytuje. Tohle skutečně řeší záznamy služeb (SRV, MX, ...), které by se jediné (pokud nepočítám SOA a NS) měly vyskytovat u domén jednotlivců a firem, kteří nechtějí provozvat žádné servery. Ze stejných důvodů se zneužívá i CNAME záznam, který je jediný v resolverech podporovaný.

Pak by bylo vcelku logické, že by se A/AAAA záznamy používal pouze pro uzly, které odpovídají nějaké entitě (stroji), která na daných adresách skutečně odpovídá. K nim by nebyl velký problém zavést smysluplné PTR záznamy třeba i automaticky (v případě využívání stejných nameserverů pro obojí).

[lertimir]

Ok, napsal jsem to příliš zjednodušeně na to, aby to bylo srozumitelné.

[Filip Jirsák]

Byly by takovéhle A/AAAA záznamy natolik užitečné, aby se vyplatilo dělat pro ně podporu a udržovat je? Podle mne by to bylo jen jméno užitečné pro lidi zabývající se infrastrukturou, přičemž ale pouze jméno moc informací neřekne. Takže bych místo PTR používal rovnou třeba whois, bez áček bych se obešel úplně.

[pavlix]

Byly by takovéhle A/AAAA záznamy natolik užitečné, aby se vyplatilo dělat pro ně podporu a udržovat je?

A/AAAA záznamy pro stroje se používaly vždy a používají se dosud. Tudíž je otázka buď hloupá nebo naopak příliš chytrá, abych docenil její význam.

[Filip Jirsák]

Otázka je, zda dnes opravdu potřebujeme v DNS pojmenovávat stroje, jestli spíš nechceme pojmenovávat jen služby. Samozřejmě pokud odhlédneme od toho, že drtivá většina standardů dnes počítá s dotazy na jméno stroje a ne na jméno služby.

[j]

Jirsak, ty ses vazne dement, naco stovky reverzu? Staci jeden.

[Jendа]

Make sure your PTR and A records match.

[sigma]

A to se týká každého A záznamu, který směřuje na nějakou IP? Vždycky jsem si myslel, že to platí pro "Also, PTR records must point back to a valid A record" -- tedy že "hodnota" PTR musí mít A záznam směřující zpět na tu samou IP. Tohle kontroluje řada nástrojů, se kterými jsem se setkal. A taky jsem se už setkal s řadou sítí, kde mají sice vygenerované PTR na celý subnet (ve stylu host-32-45.network.net) ale na příslušné A se zapomnělo, časem zmizely, nebo ukazují na jiné IP.

[Jendа]

A to se týká každého A záznamu, který směřuje na nějakou IP?

Nejspíš jo, to match bych viděl obousměrné.

[MMMMMMMMM]

Osobně si myslím, že to není myšleno obousměrně, že jde jen o shodu PTR a příslušného A záznamu. Ale s jistotou to tvrdit nemohu.

[Filip Jirsák]

Podle mne to nebylo myšleno ani tak ani tak. Prostě se při psaní nepočítalo s tím, že DNS jmen bude výrazně víc, než IP adres.

Nicméně pokud někdo RFC vykládá striktně tak, že každé používané IP adrese musí být přidělen PTR záznam, měl by stejně striktně vykládat i zbytek. Tedy Make sure your PTR and A records match nebo PTR's should use official names and not aliases a Adding a host ... Add the reverse IN-ADDR entry for each host address in the appropriate zone files for each network the host in on z RFC 1033. Tam se nikde nepředpokládá, že zařízení má nějaký hlavní název, na který má odkazovat PTR -- všechny A záznamy jsou stejně důležité, všechny jsou oficiálním jménem daného stroje.

Taky se tam mimochodem všude předpokládá, že máte doménu a také minimálně C síť, pro kterou ty reverzní záznamy spravujete. Tady se ale bavíme o případu, kdy máte jednu IP adresu půjčenou od ISP, který také spravuje reverzní záznamy. I když připustíme, že některé A záznamy jsou privilegované a označují "skutečné" jméno stroje, které jméno je to pravé -- jak jsem si stroj pojmenoval já nebo jak si IP adresu pojmenoval ISP?

[alkoholik]

DNS jmen je tuhle chvili jen zlomek poctu adres - tech IPv6.
;)
A vzhledem k existenci privacy extension - rozumej generovani nahodnych adres - je dnes takovy striktni vyklad absolutni nesmysl.
Howg.

[j]

Pokud si prectes prislusna RFC, tak u IPcek generovanych pomoci privacy ext se reverz nepozaduje - ony se totiz ty adresy (prakvapko) nedaji pouzit pro pristup zvenku (nebo jen docasne), takze jaksi pro ne nema smysl ani AAAA zaznam. Bavime se ovsem o serveru, ktery ma stabilni A/AAAA zaznam a ta IP na kterou to ukazuje by mela mit reverz, pricemz ten reverz by samozrejme mel byt prelozitelny zpet na tu IP.

Pr: mail.domena.cz => 1.2.3.4

1.2.3.4 => hokus.pokus.cz

hokus.pokus.cz => 1.2.3.4

Tahle nejak by to melo vypadat. Uz sem ale videl nejen to, ze reverz zpetne prelozitelny nebyl, ale klidne ze vracel uplne jinou IP ...

[pavlix]

Však on i ten stroj s privacy extensions by měl mít i adresu vytvořenou pomocí MAC adresy. Otázka je kolik takových adres má odpovídající PTR a AAAA záznamy.

[j]

On ji trebas i ma, jen ji zvenku jaksi (pokud veci funguji spravne) nevidno. Tusim ze kuprikladu filezilla klient pouzivala (spatne) tu fixni, jestli to uz opravili, vi buh.

BTW: Nemusi to byt MAC adresa ... bohuzel existuje i druha varianta ... a tudiz stejny stroj ve stejny siti bude mit pod widlema jinou IP nez pod tuxem (pokud neni dhcp).

[pavlix]

On ji trebas i ma, jen ji zvenku jaksi (pokud veci funguji spravne) nevidno.

Pokud vše funguje správně, tak ji z venku nevidno asi jako každou jinou IP adresu. Pokud tomu nebrání firewall, stroj na adrese normálně přijímá spojení, jen není výchozí adresou pro spojení strojem zakládaná.

Filezilla by hlavně neměla zdrojovou adresu vybírat vůbec. Je to klientský software. Od výběru zdrojové adresy je tu za normálních okolností operační systém.

BTW: Nemusi to byt MAC adresa ... bohuzel existuje i druha varianta ...

Variant existuje samozřejmě mnoho, ale neviděl bych to až tak jako bohužel. Navíc jsem měl za to, že Windows tu základní adresu nevytvářejí a používají jen dočasné adresy, což není kdovíjak skvělý nápad. A pokud si dobře pamatuju, tak blbnou i s linkovými adresami a to je nápad vyloženě jalový.

[alkoholik]

Dost ohybas vyraz "každé používané IP adrese".
Pouzil jsem nahodne vygenerovanou adresu pro odchozi pripojeni? Pouzil.

[GNU datel]

Spravovat mail server a neumet donutit ISP nastavit spravne reverz je prave priznakem totalniho idiota, ktery by mel z oboru vyficet a jit prodavat ponozky. Kvuli takovym lidem tady mame spam, protoze stejne pristupuji ke vsemu.

PS Byl bych dokonce rad, kbyby vsichni ISP implicitne blokovali tcp25 a teprve na zadost klienta by to odblokovavali, protoze to stejne normalni uzivatel potrebuje pouze kdyz pouziva mail server nejakeho podobneho chytrolina.

[lertimir]

Je velmi zajímavé, že k probíhají diskusi se vlastně vyjádřila IETF v RFC 7001 vydaném minulý měsíc. Podstatná je z A/PTR rekordů část 3 reverse IP address name validation "iprev". A vzhledem k tomu že dokument není Category jen "Informational", ale "Standards Track" pokládám ho za autoritativní současný názor.

[petr_p]

A část 3 pokračuje takto:

There is some contention regarding the wisdom and reliability of this test. For example, in some regions, it can be difficult for this test ever to pass because the practice of arranging to match the forward and reverse DNS is infrequently observed. Therefore, the precise implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report.

Extensive discussion of reverse DNS mapping and its implications can be found in "Considerations for the use of DNS Reverse Mapping" ([DNSOP-REVERSE]). In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this document is not an endorsement but is merely acknowledgement that the method remains common and provides the means to relay the results of that test.

[sigma]

Obousměrně jo, ale i když si to přečtu v kontextu, tak mi to není úplně jasné a spíš si myslím, že to platí "obousměrně mezi IP>PTR a PTR>A>IP" - tedy že se to nijak nevztahuje na A záznam, který byl prvotně resolvovaný na IP.

[MMMMMMMMM]

To si myslím také.

[petr_p]

Zcela určitě. Jinak by DNS multihoming byl nemožný. Nebo v případě násobných PTR záznamů by celé pravidlo „match“ bylo takové gumové.

Navíc z praktického hlediska proces spoléhající se na stub resolver není schopen rozlišit A od CNAME. A pro CNAME diskutované pravidlo pochopitelně platit nemůže.

[petr_p]

Zamyslel jste se k někdy, proč se tam tohle vůbec píše?

Odstavec nad tím je totiž pokus o vysvětlení:

Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.

To jen přináší jinou otázku: Proč se s klientem bez DNS záznamu nikdo nechce bavit?

Představme si ideální situaci, že každá adresa každého stroje je správně zavedená v DNS. K čemu to pak bude dobré? Pak totiž onen pokus o vysvětlení a především pravidla, na kterých staví své filtry provozovatelé odmítajících služeb, budou zcela idempotentní.

A přenesme z roku 1996 do současnosti: Máme IPv6 s automaticky nebo dokonce náhodně přiřazovanými adresami. Budeme skutečně registrovat každou adresu? Máme adresy, i v IPv4, které nejsou globální. Budeme vytvářet DNS stromy s neglobální platností?

Lpění na pravidle ze 17 let starého informačního RFC, které vzniklo jen kvůli tomu, že programátoři protokolovacích mechanismů byli líní zpracovávat vedle doménového jména i IP adresu, mi přijde pošetilé.

Ostatně nedávno jsem viděl e-mail s doménou in-addr.arpa. To je ale šalamounské řešení.

[j]

Proc te na dalnici nepusti v tanku? Je to dopravni prostredek? Je. Ale presto te tam napusti. Jednoduse proto, ze nesplnujes nejaka dalsi pravidla. Ze stejnyho duvodu te kazdy rozumny MTA vyfuckuje, pokud nemas funkcni reverz - proste nesplnujes zakladni pravidlo proto, aby se stebou vubec bavil.

A navic to fuguje - zijeme v realite, nikoli v idealnim svete. A realita je takova, ze 3/4 pokusu o doruceni mailu konci prave na reverzu. A ze z toho je mozna 1% nespamu? No a? At se dotycny maily nauci posilat, nebo at vyuzije nejakej freemail, kterej to ma nastaveny spravne.

Nehlede na to, ze zcela zejevne nechapes, jak vubec internet funguje. Internet je nejaky soubor nejakych siti a uzlu, jejiz provozovatele/majitele si urcuji zcela ve vlastni rezii veskera pravidla jejich uzivani. Na nekterych tech pravidlech pak panuje rekneme "vseobecna" shoda - a takova jsou uvedena v RFC. Ovsem i v takovem pripade je treba si uvedomit, co ta zkratka RFC znamena. Ve vsech pripadech jde pouze o doporuceni.

A tudiz, kdo vyfuckuje maily bez reverzu, tak se jednoduse ridi doporucenim, ze protistrana by mela mit reverz. Pokud se to protistrane nelibi, je to jeji problem.

[Jendа]

A navic to fuguje - zijeme v realite, nikoli v idealnim svete. A realita je takova, ze 3/4 pokusu o doruceni mailu konci prave na reverzu. A ze z toho je mozna 1% nespamu?

Toto tvrzení by si zasloužilo podložit - alespoň metodikou.

A tudiz, kdo vyfuckuje maily bez reverzu, tak se jednoduse ridi doporucenim, ze protistrana by mela mit reverz.

Překvapuje mě, že se některými doporučeními řídíš a některými ne. Máš pro posuzování toho, kterými se řídit, nějaká pravidla?

[j]

Co chces dokladat medodykou? Pred zavedenim kontroly na reverz (a nekolika dalsich opatreni - kontroluje se jeste smysluplne predstaveni serveru ... ) 5 000 spamu/den, po zavedeni radove 100/den (pocitam ty, ktery jsou prijaty, ale skoncej na filtrech)

Pripadne vypis z logu - 3/4 konexi konci na reject kvuli reverzu. Cast z toho zbytku konci samo jeste na dalsich pravidlech.

Jednou za 1/4 roku nekdo resi, ze mu neprisel nejaky mail.

[sigma]

Musím potvrdit obdobnou zkušenost, i když v našem případě to 75% asi nebylo, ale bylo to hodně. Samozřejmě tenhle argument lze validně zpochybnit tím, že nevím kolik z těch odmítnutých mailů nejsou spamy. Sice mám též podobnou zkušenost ze 2 nasazení - firma se 100 mailboxy, problém tak jednou za 3 měsíce; mailserver pro asi 50 domén, asi 500 schránek - problém tak jednou za 2 měsíce, ale někteří měli potíže častěji, tak jsme to pak předělali na jiné řešení. Řekl bych, že hodně záleží na prostředí, jestli si tohle člověk může dovolit nebo ne.

[j]

Dovolit si to clovek muze kdekoli, za nejakych 5 let mam ve vyjimkach asi 30 radku dmntu, kteri si neumi nstavit DNS, je mezi nimi i nejvetsi ceske IT vydavatelstvi ... ovsem i nejvetsi ceske banky, si to nastavit umi, stacila lehka komunikace na tema "nejste sami komu nase maily nechodi" ... a za tyden to meli nastaveno.

Vem si, ze mam zaroven na spravovanych domenach nastaveny spf ... a nektery lidi si stezujou, ze jim "nechodi maily" ... ony jim ty maily chodi, na firemni schranku, ale oni maj (blbe) nastaveny presmerovani ... trebas na seznam, kterej je stim vyfuckuje, protoze jejich srv samo v spf neni.

[pavlix]

Já měl za to, že SPF tímto prostě trpí a že je to hlavní důvod, proč ho nepoužít.

[j]

Ja mel za to, ze pokud si mail presmeruju, tak uz neni from:zdroj.cz, ale from:cil.cz to:novy.cil.cz .... a kazdej normalni mail to presne takto udela => v mailu vidim, ze mi prisel od franty, reply-to je nastaveny na frantu, ale from, je muj.presmerovany.mail@cosi.

A ucelem je kupodivu prave to, aby jen tak nekdo nemoh poslat mail typu from:premier@vlada.cz ...

Nehlede na to, ze jako vsechno, SPF je informace kterou zverejnuje drzitel/admin domeny, a je ciste na okoli, jak s tou informaci nalozi. Seznam s ni naklada tak, ze maily proste neprijme. Z myho pohledu naprosto koser, protoze ja jako admin domeny sem prohlasil, ze existuji pouze dva stroje, ktere jsou autorizovany k odesilani mailu z teto domeny. Cimz zaroven rikam, ze pokud prijde mail z jineho serveru, tak proste o nem nic nevim a tudiz necht si snim kazdy nalozi jak uzna.

BTW: Sem kamosce onehda predvadel, jak ji poslu mail z jejiho mailu ;D, samo, v hlavickach byl videt muj srv, ale dost ji to tenkrat vyplasilo, a hlavicky BFU samo nekontroluje ...

[pavlix]

No ne, pokud porovnáš SPF a DKIM, tak z toho u mě SPF vychází jako hodně chudý bratranec. Jak s tím kdo má naložit je víceméně definováno standardem. Odchýlit se od standardu či ho neimplementovat je sice možné, ale alespoň to první málokdy něco přinese.

[Kriegel]

Ne tak docela -- "presmerovani" na urovni aliasu (at uz lokalniho, nebo virtualniho) normalne nemeni 'mail from' -- pokud to@cil.cz je alias pro to@novy.cil.cz tak je na "problem" zadelano, protoze connect pujde z @cil.cz s originalnim 'mail from'... Na free/normal mailu bych takove reseni necekal (tam se cela zprava re-submit-ne s novym 'mail from' a pripadne prepsanou 'From:' hlavickou), ale jinak se to vyskytuje v praxi bezne; panove jsou si toho vedomi a proto take vznikl SRS (to zase zavadi nekolik dalsich ale a pridava na komplexnosti)...

Tim nijak nechci polemizovat nad tim, jestli je to tak dobre nebo ne, ale prave moznost (pro nektera prostredi krajne hypoteticka) toho, ze "se to da rozbit", lidi, jak pise pavlix, od nasazeni spf zrazuje...

[petr_p]

Ze stejnyho duvodu te kazdy rozumny MTA vyfuckuje, pokud nemas funkcni reverz - proste nesplnujes zakladni pravidlo proto, aby se stebou vubec bavil.

Já žádné základní pravidlo, že TCP klient, který se chce bavit s MTA serverem, musí mít reverzní záznam, neznám. To, co je citováno nahoře, nemá s MTA nic společného (máte stejně nastavený HTTP server?) a není to základní pravidlo (je to should v něčem, co není ani standard).

A nakonec jsem se ještě nikde nedozvěděl, k čemu MTA funkční reverz klienta potřebuje. Maže si ho na chleba?

[Jendа]

To, co je citováno nahoře, nemá s MTA nic společného (máte stejně nastavený HTTP server?)

Co, HTTP server. Ale taky klient!

[petr_p]

Už se takové jelito našlo :)

[j]

On ti http server posila desitky tisis spamu denne? Bez toho abys na nej sam lez? Hm ... samozrejme ze reverz ocekavam od kazdyho serveru, a jakykoli problem stim serverem = jdu se na prave toto (mimo jine) podivat. Pokud nema, je to prvni indikace dementa na druhy strane.

[j]

Apropos, ber to trebas jako test inteligence. Predstav si to tak, ze mas vratka, pred nima je krabice plna cervenych cepic a na vratech napis, ze vstup povolen jen v cervene cepici. Pokud nekdo prijde bez cepice, tak ho proste vykopnes. Presne stejne funguje kontola reverzu. Pokud nekdo seriozne provozuje libovolny server, tak nemuze mit zadny problem si tu cepici nasadit. Kazdy normalni ISP mi nastavi reverz dle prani.

[petr_p]

Ale tak to máš napsat rovnou, že to je tvoje metodika rozpoznávání spamu, a ne nám tvrdit, že tě k tomu nutí IETF.

[menphis]

+1

[j]

A spousta jirsaku si neumi ani precist RFC, kde je reverz povinou soucasti.