sendmail a DNS - PTR vs. A

[Lubos Kaspar]

> From: Petr Vejsada <daemon na svoboda.nevotravovat.cz>
> To: sendmail na linux.cz
> Subject: Re: sendmail a DNS - PTR vs. A
> Date: Fri, 25 Jun 2004 07:54:00 +0200

Jeste bych rad neco dodal - chtel jsem pokracovat mimo konferenci, ale
domena z adresy ve From: je neplatna a SMTP-obalkova adresa prispevatele
se pres listserver nepropaguje.

> Dne čt 24. června 2004 16:57 Lubos Kaspar napsal(a):
> 
> LK> Prave ze nebudete muset delat nic. Jmena byvaji stalejsi nez IP-adresy.
> 
> Neumim posoudit nakolik, uz jsem zazil, kdy spamer menil PTR kazdou chvili. 
> Pamatuji na pripad, kdy se nekdo snazil ke mne protlacit spam z IP a.b.c.d 
> bez PTR a par minut nato ho protlacil, protoze si PTR udelal. Pravda, asi to 
> nebude (zatim) prilis obvykle.

Neceho podobneho jsem si jeste nevsiml, ale asi to take muze nastat. Pochybuji
ovsem, ze by spamovadla byla tak chytra a jeste propojena se spravou DNS, aby
neco takoveho probihalo automatizovane. :-)

> LK> Blokovane hosty (resp. domeny) i IP-adresy (resp. "tridy" siti) mohou byt
> LK> s vyhodou  v jednom souboru - dejme tomu, ze se jmenuje
> LK> /etc/mail/denied-client a ma obsah typu:
> 
> [...]
> 
> LK> Umi neco takoveho i access.db?
> 
> je to v podstate uplne stejne jako access.db. Jen se do access pise jeste 
> navic zda RELAY, OK, REJECT apod.

Jeste by tam mela byt moznost DISCARD (v .cf odpovida "$#discard"). Jeste chapu,
ze REJECT vede v .cf na "$#error", ale neni mi jasne, jaky je rozdil mezi
RELAY a OK.

> Priznavam, ze sendmail.cf moc nerozumim 
> (holt jeste nejsem ten spravny administrator, nemam za sebou napsani 
> vlastniho sendmail.cf), jen sendmail.mc :)

Uplne cely vlastni .cf by byl uplne nejlepsi, ale to uz by to clovek musel
opravdu dobre znat. Pro me je zatim realna uprava takovych tech
defaultnich (maximalnich) verzi, ale pri trose snahy je zjednoduseni
opravdu znatelne a jsem presvedcen, ze souvisejici optimalizace behu
sendmailu je nezanedbatelna. Bohuzel sendmail.org uz dost davno podporuje
jen .mc a z toho pak lezou obludnosti. Napr. v kazdem vzoru je obsluha
:include: (v aliasech), ktera neni na urovni .mc dekonfigurovatelna, jenze
kdo asi tak dela aliasy rucne? Kdyz se generuji, tak uz je lepsi dat do
tvoritka i spojeni souboru a sendmail pak uz nemusi otvirat tolik souboru.

> LK> Nedavno jsem sem o
> LK> tom psal a take to, ze je podivny fakt, ze absence A pro jmeno z
> LK> PTR mu nevadi (pouze poznamena do logu  "may be forged"). Jelikoz
> LK> na to tehdy nikdo nezareagoval, dovoluji si znovu nadhodit dotaz,
> LK> jestli se da nejak sendmail donutit, aby absenci A pro jmeno z PTR
> LK> tez povazoval za chybu resoluce, konkretne jak tuto podminku
> [...]
> LK> Hm, jenze lepsi by bylo, kdyby to slo bez tcpwrappers, protoze takto asi
> LK> sendmail vubec nedostane spojeni a nemuze generovat vlastni chybovou
> LK> hlasku, takze klient muze nabyt nespravneho dojmu zavady na urovni site.
> 
> nene, nejde to pres in.tcpd, to by se musel sendmail poustet z inetd a do 
> hosts.* psat smtp: a ne sendmail:. Takto se sendmail dostane ke slovu a pouze 
> pouzije volani do knihovny tcpwrappera, aby zjistil, zda se s klientem ma 
> bavit nebo ne. Pravda, hlaska jakou da pri odmitnuti je natvrdo nakodovana 
> v /usr/src/sendmail-$VERSION/sendmail/conf.c pro sendmail-8.12.11 je to radek 
> 4009.

Diky za nakopnuti, bohuzel me to napadlo az pozdeji. Ma potiz je v tom, ze
tcpwrappers neni uplne organickou soucasti systemu, na kterem zde MTA
provozujeme, a take je pak konfigurace uz moc "rozeseta".

> Zda to jde jinak a lepe nevim :(

Asi budu muset nastudovat nejaka makra sendmailu. Uplne prinejhorsim by to
urcite slo volanim vlastniho programu (v .cf "$<"), coz ale bohuzel ma bud
dost velkou rezii (shell-skript) nebo je to pracnejsi (kompilovany program).

> LK> Uplne vsem ne; potiz je v tom, ze na PTR se zhusta kasle a nejhorsi je
> LK> to, ze kdyz se to nekomu vytkne, tak je jeste casto urazen, prestoze je
> LK> to evidentne jeho neporadek.
> 
> Mate pravdu, uplne vsem ne. Je to stejne, jako kdyz se rika "vsichni pouzivaji 
> MSIE tak proc my ho tady nemame?" Nas obchodni partner (tedy spis partneri) 
> proste reknou, ze _vsem_ mohou posilat postu jen nam ne (a muze byt pravdou 
> to, ze se s odmitanim setkali poprve u nas) a proto my to mame spatne. O tom 
> co je PTR ti lide nemaji tuseni. Tyka se to zejmena klientu firmy Contactel, 
> nebot Contactel na PTR kasle snad ze zasady (zdravim zodpovedne lidi z 
> Contactelu). Ale to uz neni o sendmailu.

Mam stejnou zkusenost. Prestoze pri absenci PTR nas MX-server vraci "unresolved"
spolu s odkazem na web, kde je podrobny popis, casto se admini divi a tvrdi,
ze "problem" je u nas. Nakonec je vzdy u nich (chybna delegace reverzni domeny,
zmena IP nameserveru bez upravy glue-A v nadrizene domene a jine "speky").

S administraci PTR byvaji nejvetsi problemy tam, kde DNS pro reverz obsluhuje
ISP, kdezto primou domenu si administruje vlastnik. Vlastnik si zmeni
nebo prida IP v prime domene a na PTR u providera "zapomene". Zlate casy
nekdejsiho "akademickeho" Internetu, to to jeste delali odbornici. :-(
--
Lubos Kaspar