Správně nakonfigurované DNS u mailserveru podruhé

2.5.2012 11:28 | Přečteno: 3304× | Gentoo

Po roce se vracím k tématu, které si posledně v diskuzi vyžádalo přes 100 příspěvků, jeden flame, a hodnocení 33% - přesto si myslím, že nejde o nic kontroverzního. Znovu jsem si prošel logy z mailserveru, abych se podíval, jak jsou na tom doručující mailservery s DNS záznamy. Můžu říct, že situace je oproti loňsku horší. Serverů, kterých úplně chybí A nebo PTR záznam, nebo chybí oba, nebo se neshodují a zároveň jsou to legitimní servery je více. Alarmující je, že jde o servery "velkých firem" jako je např. TESCO, Komerční banka, AssaAbloy a pod. Druhou kategorií jsou různé malé hostingy, atd. V době, kdy na našich serverech je více než 98% mailových zpráv spam, je kontrola A a PTR záznamu spolu s graylistingem první a legitimní ochranným elementem. Nedovedu si představit, že bych ty statisící mailů měl všechny prohánět skrz spamassasin a pod.

Př. AssaAbloy

Apr 25 03:11:48 tiberius postfix/smtpd[7722]: warning: 213.195.209.30: hostname mail2.assaabloy.cz.209.195.213.in-addr.arpa verification failed: Name or service not known Apr 25 03:11:48 tiberius postfix/smtpd[7722]: connect from unknown[213.195.209.30] Apr 25 03:11:48 tiberius postfix/smtpd[7722]: NOQUEUE: reject: RCPT from unknown[213.195.209.30]: 450 4.7.1 Client host rejected: cannot find your hostname, [213.195.209.30]; from=<*****> to=<*****> proto=ESMTP helo="mail.assaabloy.cz| Apr 25 03:11:48 tiberius postfix/smtpd[7722]: disconnect from unknown[213.195.209.30]

Př. TESCO

May 2 06:20:22 tiberius postfix/smtpd[3655]: warning: 212.140.187.24: hostname UKTIL02MAILF01V.tilukdmz.til.dotcom.tesco.org verification failed: Name or service not known May 2 06:20:22 tiberius postfix/smtpd[3655]: connect from unknown[212.140.187.24] May 2 06:20:22 tiberius postfix/smtpd[3655]: NOQUEUE: reject: RCPT from unknown[212.140.187.24]: 450 4.7.1 Client host rejected: cannot find your hostname, [212.140.187.24]; from=<*****> to=<*****> proto=ESM TP helo="UKTIL02MAILF01V.tilukdmz.til.dotcom.tesco.org" May 2 06:20:22 tiberius postfix/smtpd[3655]: disconnect from unknown[212.140.187.24]

Př. KB

May 1 02:07:00 tiberius postfix/smtpd[26017]: warning: 194.228.113.250: hostname mail4.kb.cz verification failed: Name or service not known May 1 02:07:00 tiberius postfix/smtpd[26017]: connect from unknown[194.228.113.250] May 1 02:07:00 tiberius postfix/smtpd[26017]: NOQUEUE: reject: RCPT from unknown[194.228.113.250]: 450 4.7.1 Client host rejected: cannot find your hostname, [194.228.113.250]; from=<*****> to=<*****> proto=ESMTP h elo="mail4.kb.cz" May 1 02:07:05 tiberius postfix/smtpd[26017]: disconnect from unknown[194.228.113.250]

Př. AngelHosting

Apr 29 03:52:13 tiberius postfix/smtpd[22097]: warning: 146.255.30.202: hostname 146.255.30.202.angel-hosting.cz verification failed: Name or service not known Apr 29 03:52:13 tiberius postfix/smtpd[22097]: connect from unknown[146.255.30.202] Apr 29 03:52:13 tiberius postfix/smtpd[22097]: NOQUEUE: reject: RCPT from unknown[146.255.30.202]: 450 4.7.1 Client host rejected: cannot find your hostname, [146.255.30.202]; from=<*****> to=<*****> proto=ESMTP he lo="vs6660.angel-hosting.cz" Apr 29 03:52:13 tiberius postfix/smtpd[22097]: disconnect from unknown[146.255.30.202]


Dalším problémem je, že u většiny "velkých firem" se absolutně nedá spojit s nějakým jejich administrátorem. A jak jste na tom vy?        

Anketa

Komentáře

[Roman]

U velkých firem bych to řešil s kontakty uvedenými na webu, případně šéfíkama. Sepsat to, že tam mají chybu a ať si co nejdříve opraví, jinak jim nebudou chodit maily.

[Max]

Doporučení ohledně PTR je na nic. Tuto problematiku řeší SPF, ale četnost tohoto nastavení je taktéž žalostná.
Zdar Max

[Käyttäjä 11133]

Tak jo, ukecal si mě, nastavil jsem SPF pro všechny domény pod mou kontrolou :D

[Jendа]

Takže když u tebe mám mail, tak si ho přes svůj MTA nepošlu?

// Co si myslíte o řešení spamu tím, že fyzická identita bude mít prostě limit 50 mailů za hodinu?

[Max]

Tento limit je na nic.
Jinak to, že si v DNS správně nastaví SPF neznamená, že si nepošleš maila. Jen se nedoručí mailserverům, které SPF používají/kontrolují. V takovém případě by se ti o tom měla vrátit hláška.
Zdar Max
PS: nejlepším řešením stejně je, používat smtp pro tvojí doménu, tzn., SSL+ověřování a hotovo. Port 465 se u ISP neblokuje jako 25

[cynic_asshole]

Stejně tak i tcp/587 je málokde zablokované…

[Käyttäjä 11133]

No znamená to, že ho možná některé mailservery od tebe nevezmou. Ale vzhledem k tomu, že u mě mají mail účty jen lidi kteří používají webmail, nebo mají tlusté klienty nastavené tak, aby používali můj SMTP server, tak to dopad na uživatele mít nebude.

[xkucf03]

Může to mít dopad např. když si příjemce nechá přeposílat zprávy jinam (a to webmailem nebo vlastním SMTP na straně odesílatele nevyřešíš). Ale když tam máš ~all, tak by to mělo projít i tak (jen s varováním v logu a hlavičkách).

[xkucf03]

Dal jsi -all?

[Käyttäjä 11133]

~all

[trekker.dk]

Alarmující je, že jde o servery "velkých firem"

Důvod je jednoduchý: too big to fail. Když tvoji zákazníci zjistí, že jim nechodí zprávy od někoho významného, budou chtít po tobě, abys to vyřešil, jinak odejdou.

[menphis]

Bud si kokot, nebo to nemyslis vazne.

http://www.ietf.org/rfc/rfc2821.txt

[rastos]

Nenechte prchlivost cloumat svým majestátem.

SMTP server nie je povinný prijať správu. Prene podľa tebou citovaného RFC. Takže ak ti nezáleží na tom, či tvoj mail dorazí, tak kľudne ignoruj nastavenia DNS.

[SAM:]

A příště mluv slušně.

[Martin Mareš]

Trvat na přesném doručování poštovních standardů dává smysl, ale vyžadovat pro přijetí pošty něco, co s ní vůbec nesouvisí (totiž PTR záznam), je jenom zbytečná buzerace, která navíc zablokuje netriviální množství legitimních mailů a spamy zase tak moc neomezí. Kontrola PTR mi dává smysl maximálně jako jeden z mnoha faktorů, které přispívají k celkovému hodnocení míry spamovitosti zprávy.

[SAM:]

Dovolím si nesouhlasit, podle našich statistik, kontrola A a PTR likviduje okolo 92% až 96% spamu. Což znamená významné šetření výpočetním výkonem. Jinak existuje jiné RFC (omlouvám se, nevzpomínám si teď na číslo), které specifikuje, že ke každé používané IP adrese by měl existovat A a PTR záznam. (Tuším, že použité anglické slovo tam je ... should be). Vím, že tím nelze přímo vyžadovat existenci validního PTR a A záznamu pro mailserver. Ale dle mého názoru v době kdy masivní většina elektronické pošty je spam, je to legitimní.

[Jakub Lucký]

vypnutí mailserveru zastaví 100% spamu a přesto to nelze považovat za dobrý nápad...

[xkucf03]

Dovolím si nesouhlasit, podle našich statistik, kontrola A a PTR likviduje okolo 92% až 96% spamu.

Každý máme jiné statistiky – např. v mém případě by to zablokovalo zhruba 0% spamu, protože většina mi ho chodí ze serverů jako je Hotmail* (ne jen podvržená e-mailová adresa, ale skutečně z jejich serverů) nebo od českých firem (→ nahlásit ÚOOÚ) nebo od ksindlu typu Vistaprint (→ individuální přidání na černou listinu). Nebo mi nějací Maďaři posílali „newsletter“ s nabídkou jejich hotelu → opět černá listina.

*) už jsem si říkal, že bych je mohl zablokovat, protože tohle nikdo normální asi nepoužívá

[SAM:]

To jsou zajímavé postřehy. U nás jde většinou o pitomé nabídky kde čeho a většinou to pochází z nějakého botnetu, IP adresy jsou zcela náhodné ale převážně jde o různé kabelové a adsl operátory. Tyto IPčka nemívají správně nastavené záznamy, takže moje politika je účinná. Cíleného spamu z nějaké firmy, nebo služby typu hotmail, toho nám chodí minimálně.

[Ondrej 'SanTiago' Zajicek]

Jinak existuje jiné RFC (omlouvám se, nevzpomínám si teď na číslo), které specifikuje, že ke každé používané IP adrese by měl existovat A a PTR záznam.

Coz ovsem znamena, ze by mely mit PTR zaznamy i ty klientske pocitace obsazene botnety, ze kterych se rozesila spam.

[Martin Mareš]

Tuším, že použité anglické slovo tam je ... should be

No právě – tedy ne povinnost, ale pouze doporučení.

Osobně mi přijde jako daleko větší zlo propustit 10 spamů než odmítnout jeden legitimní mail.

[xHire]

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [RFC2119]

Já to v zásadě chápu jako povinnost, pokud k jiné variantě nemá člověk pádný důvod.

[Martin Mareš]

Zajisté. Ovšem to, že autoři standardu použili SHOULD, a nikoliv MUST, nejspíš značí, že věřili, že ten pádný důvod mít lze.

[xHire]

Zajisté. Ale pak ovšem ti, co ten pádný důvod mají, také jistě ví, jaké z toho pro ně mohou plynout důsledky (protože je to jejich povinnost – RFC (viz citace výše) uvádí must).

[menphis]

Otazkou je, kolik to likviduje hamu. Nedovedu si predstavit, co by se mi stalo, kdybych takovy peklo jako pozadavek na A=PTR nasadil na firemni mail server.

Grelisting + SPF take likviduje pres 95% spamu a je to podstatne lepsi. Kdyz se u GL zvoli vhodna implementace, tak ani nezpusobuje problem s dorucovanim od uzivatelu s vice mail servery ( gmail, ... ) a zpozduje minimum zprav.

Cely tenhle zapis mi to prijde, jen vymluva, proc si poradne nenastavit mail server.

PS: Misto chyby 4xx, bys v tomhle pripade mel vracet 5xx.

[MMMMMMMMM]

Shodu A a PTR nekontroluju (obávám se, že by hodně serverů prostě neobstálo), ale existenci PTR záznamu ano a pokud chybí, mail není přijat. Bohužel musím souhlasit, že některé i větší organizace zaměstnávají lemry líné (nebo neschopné, např. Ministerstvo zdravotnictví), které ani na přátelsky laděný e-mail s upozorněním nijak nereagují. Drtivá většina e-mailů z IP bez PTR je spam, o tom žádná. :)

[cezz]

Shodu A a PTR nekontroluju, ale existenci PTR záznamu ano a pokud chybí, mail není přijat.

+

ani na přátelsky laděný e-mail s upozorněním nijak nereagují.

..mozno reaguju, ale skonci v spamboxe

[xHire]

Dalším problémem je, že u většiny "velkých firem" se absolutně nedá spojit s nějakým jejich administrátorem.

postmaster@domena.tld? Ale celkem bych i věřil tomu, že ani v tomto nedodržují RFC. ;c)

Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name. [RFC5321]

[Heron]

No já nevím, ale A a PTR záznamy se obvykle kontrolují tak, že PTR musí vrátit jméno, které vede na tutéž IP, jako původní kontrolovaný A záznam. Požadovat shodu A a PTR je už dost silné kafe. Jsou hosti, kteří mají opravdu hodně A záznamů a jen jeden, validní PTR a jsou to slušné email servery a ne spameři.

[petr_p]

Tak tak. Pisatel si kontrolu obrátil, což možná vyhovuje jemu, ale ne RFC, na které se tu odkazuje.