Comments

1. BobanV
   February 7th, 2010 | 09:56 PM

   Hm,

   tukaj vidim dva vidika problema:

   -MX. SMTP RFC namrec zlo dvounmno doloca kdaj naj MTA poskusi vzpostaviti povezavo na MX z nizjo preferenco. Se vec, ceprav doloca (RFC5321 s. 5.1) da se morajo MXi kontaktirati po vrsti po preferenci. Vendar, zadnji 2 leti se pogosto dogaja, da se mail dostavi na MX z nizjo preferenco, kjub temu, da je SMTP dostopen na MXu z visjo. To povzroca probleme zlasti pri multihome active-pasive postavitvah, ko se resuje dostopnost SMTP streznika s pomocjo preference. Zaradi teh in podobnih razlogov bi se sam izogibal reguliranju dostave s pomocjo MX preferenc.

   -DNS. Po moje je glavni vzrok, da se posta dostavi na ipv4 SMTP in ne na v6, kjub temu da obstaja AAAA zapis MX zapisa ta, da je okoli se vedno ogromno kriplastih DNS relayev, ki enostavno zignorirajo AAAA odgovore na neko poizvedbo. Druga stvar so resolverji v sami operacijskih sistemih, ki lahko zignorirajo AAAAje. Glede na to ne vidim nevarnosti, da bi sploh bili problemi s starimi strezniki in AAAA zapisi. Bilo bi pa zanimnivo stestirat kaksen zlo star sendmail ali qmail, kako se obnasa ob prisotnosti AAAA zapisa.

   Sam bi pa najraje presekal problem s tem, da se doda v standard recimo MXXXX zapis, ki bi kazal na ipv6 enabled SMTP in bi ga ipv6 enabled MTAji morali upostevati. na v4 nivoju pa bi se vedno obstajali MX zapisi.

   Do takrat pa se mi zdi se najbolj varno uporabljati ustaljeno prakso s hkratnim AAAA in A zapisom za SMTP streznik.

   Boban.

2. JanZorz
   February 7th, 2010 | 10:05 PM

   S prvo točko se strinjam. Tudi sam opažam napačno obnašanje in razumevanje mail serverjev, kar se tiče MX preferenc. Čudno mi je edino, da si to privoščijo na IETF-ju in RIPE-NCCju :).

   Z drugo točko se tudi načeloma strinjam, obstajajo kripljasti DNS resolverji, ki dajo samo A zapise, na AAAA pa pozabijo, pa čeprav si mu rekel “any”, a tu mislim da ni to problem, saj se normalno delovanje vzpostavi takoj, ko odstranim MX na v4-only host. V nasprotnem primeru bi mail še vedno hodil preko v4.

   Mislim da prva točka čisto spodobno odgovori, kje bi znala biti težava.

3. ales
   February 10th, 2010 | 07:28 AM

   Da maili prihajajo kar na sekundarni (ali celo kak nižji) MX, sem opazil predvsem pri SPAMu, mogoče tudi pri virusih. Drugače pa niti ne.

   Jan, nič prepričljivega nisi navedel, da bi za to obnašanje bil kriv prav ta “hack”. Da vam slučajno kak greylisting ne zadrži dostave preko IPv6, čez nekaj časa pa *isti* server spusti skozi drugi poskus dostave (na “drugi” server) preko IPv4?

   Aleš

4. JanZorz
   February 10th, 2010 | 11:17 AM

   @ales: ne, sem preveril v logih, če bi bilo temu tako, potem bi bil prvi connect na IPv6 naslov in zavrnjen (greylisted), naslednji pa na IPv4, a temu ni tako, prvi connect od severjev pride na IPv4.

   Edino kar nisem stestiral je, da bi dal IPv4 naslov na sekundarnem MX-u na nekaj drugega kot je IPv4 naslov pri primarnem MX-u.

   To bi še lahko sprobal, da bi bil čisto zares prepričan, da se mi connecta na sekundarni MX in ne kar direkt na IPv4 naslov v primarnem MX-u.

5. j
   February 10th, 2010 | 02:51 PM

   yep. greylisting bi znal biti “zaviralec” dostave.

   Jaz sicer uporabljam hostaname z A/AAAA zapisom za MX in nimam problemov pri dostavi.

   PS
   glede spama/trojancev, ki hodijo preko backup MX “not”, pa obstaja resitev – “null listing” oz. “DNS greylisting” – http://tnt.aufbix.org/spam

Leave a reply