dotaz ohledne postfix a DNS

[Zdeněk Kolařík]

Dan Lukes napsal(a):
> Zdeněk Kolařík napsal/wrote, On 04/18/08 15:21:
>   
>> V DNS je okmail.oksystem.cz na adrese 193.222.130.65.
>> Reverzni dotaz dig-em jim sice "nejak" funfuje pro obe adresy, tedy 
>> 193.222.130.1  i  193.222.130.65
>> na jeden nazev "okmail.oksystem.cz", ale spravne by se jejich odesilaci 
>> server mel hlasit
>> v HELO jako "ns.oksystem.cz". Pak by to zrejme bylo v poradku.
>>     
>
> 	No to by, samozrejme, v poradku nebylo. HELO nema s problemem cokoliv 
> spolecneho.
Pokud postfix nema zapnutou volbu
reject_invalid_helo_hostname nebo nejaky podobny test, ktery prave udaj 
z HELO vyhodnocuje.
To puvodni tazatel neuvedl.
>  Problem je v tom, ze IP adresa 193.222.130.1 ma jmeno 
> okmail.oksystem.cz, ale zadna z adres jmena okmail.oksystem.cz neni 
> 193.222.130.1. Coz je spatne zs principu a nezavisle na tom pro co se ta 
> IP pouziva.
>   
Pak jsem tedy spatne pochopil hlasky postfixu v logu.

Apr 18 10:30:50 postak postfix/smtpd[76414]: warning: 193.222.130.1: 
address not listed for hostname okmail.oksystem.cz
Apr 18 10:30:50 postak postfix/smtpd[76414]: NOQUEUE: reject: RCPT from 
unknown[193.222.130.1]: 450 Client host rejected: cannot find your 
hostname, [193.222.130.1]; from=<nejakejpan at oksystem.cz> 
to=<kemenaserver at keytec.cz> proto=ESMTP helo=<okmail.oksystem.cz>

Pochopil jsem to cele tak, ze "ns.oksystem.cz" je v DNS radne 
registrovan dopredne, ale ne zpetne.
ns.oksystem.cz.         3600    IN      A       193.222.130.1

# dig -x 193.222.130.1
1.130.222.193.in-addr.arpa. 3600 IN     PTR     okmail.oksystem.cz.

Kdyz tedy zpetny dotaz vrati to "spravne" jmeno, kterym se server hlasi, 
a prece se to
postfixu nelibi, nenapadlo me nic jineho, nez zkusit pouzit jeho 
skutecne jmeno.
> 	To je cele. Pravdepodobna chyba je to prvni - ve skutecnnosti dotycny 
> spravce nechce, aby se 193.222.130.1 jmenovala okmail.oksystem.cz, 
> protoze to je jiny stroj poskytujici jine sluzby (a neni tedy se strojem 
> na adrese 193.222.130.65 zamenny).
>   
Pak by bylo lepsi, aby oksystem pouzival svuj prijimaci server i k 
odesilani.
>> vzhledem ke mnozstvi problemu s takto "nedokonfigurovanymi" mailservery a telefonaty prijemcu 
>> jsem to vzdal a je klid.
>> Po techto zkusenostech doporucuji kontrolu reverznich zaznamu vypnout.
>>     
>
> 	No, tak ja zase ne. Chybne nakonfigurovanych nameserveru je pomerne 
> malo a kdyz uz se takovy najde, vetsinou staci jeden mail jeho spravci, 
> ktery chybu opravi. Nema ji tam totiz zamerne a nakonec je rad, ze ho 
> nekdo upozornil. Jde o jeden az dva pripady mesicne.
>   
V nekterych pripadech se zadne zmeny nedovolate. Adresa uvedena v SOA 
zaznamu proste neexistuje.
Take jsem se u jedne velke ceske firmy nedomluvil, protoze jejich 
spravce DNS nereflektoval na specificke potreby
jedne z firem, kterym spravuji postovni server. Prestoze maji v 
republice stovky dealeru pripojenych pres VPN,
na svych DNS serverech, dostupnych uvnitr teto VPN maji nekdy jine udaje 
(napr. prave o postovnich serverech)
nez na verejne DNS v Internetu.
Vlastni verejnou DNS a vlastni postovni server zatim skoro nikdo z 
techto dealeru nema, takze to tu velkou firmu zatim moc netizi.
Pokud ale potrebuje byt server napojen zaroven do VPN i do Internetu, 
vznikaji zbytecne problemy. Napriklad nemohu
uvnitr LAN zridit jednu DNS cache, ktera se dotazuje napred do VPN a pak 
do Internetu, protoze udaje z VPN
nejsou vzdy spravne. Zvlaste, kdyby tu DNS cache pouzival i ten verejny 
mailserver, atd.
>> Vase stroje se pak trochu vic "nadrou", ale od toho tady koneckoncu jsou 
>>     
>
> 	No, takhle je to zase trochu vic prace pro me, ale od toho tu jsem. A 
> vysledek za to stoji.
>   
Ne vzdycky (viz vyse). Zapnuti kontroly reverznich zaznamu doporucuji 
dobre uvazit i autori manualu
a tvurci postovnich programu. Je to doposud (a vypada to, ze jeste 
chvili bude) problem na celem svete.
Dobre nakonfigurovany system (tam je treba si dat vic prace) se bez 
tohoto jedineho testu urcite dobre obejde.
> 	Your mileage may vary.
>
> 						Dan
>
>   
-- 

Zdeněk