MX “hack”, predlagan na 1. Slo IPv6 summitu ne dela dobro.
Na 1. Slo IPv6 summitu je IJS predlagal rešitev, kako zagotovimo, da je možnost za ne-dostavo e-pošte čimmanjša, če usmerimo primarni MX zapis na host zapis, ki ima A in AAAA zapis. Po daljšem testiranju smo ugotovili, da to ne deluje pravilno…
Predlog je sledeč; imamo na primer A in AAAA zapis za mail.go6.si:
mail.go6.si. 3597 IN AAAA 2a02:e8:0:1::babe:face
mail.go6.si. 3224 IN A 212.44.108.1
MX zapis za go6.si usmerimo na mail.go6.si:
go6.si. 3095 IN MX 10 mail.go6.si.
Predvidevamo, da kakšni arhaični poštni strežniki ne vedo nič o IPv6 in jih bo AAAA zapis zmedel in elektronska pošta od tam ne bo dostavljena. Kako to rešiti? Fantje iz IJS so zelo logično ugotovili, da bo takšen strežnik šel preveriti sekundarni MX zapis in če je usmerjen na host zapis, ki vsebuje samo A, bo pošta dostavljena. Recimo temu 4.go6.si.
4.go6.si. 3600 IN A 212.44.108.1
Če sedaj dodamo sekundarni MX zapis na domeno go6.si, dobimo sledeče:
go6.si. 3095 IN MX 10 mail.go6.si.
go6.si. 3095 IN MX 20 4.go6.si.
mail.go6.si. 3597 IN AAAA 2a02:e8:0:1::babe:face
mail.go6.si. 3224 IN A 212.44.108.1
4.go6.si. 3600 IN A 212.44.108.1
Zgleda super, pa še logično. Le da ne dela. No, čisto natančno povedano, nekako dela to, za kar je namenjeno, uniči pa dostavo pošte na poštni strežnik preko IPv6 protokola. Kako to? Pojma nimam. Niti malo.
To sem opazil, ko so mi začeli poštni strežniki iz psg.com, ietf.org, ripe.net in ostali dostavljati pošto preko IPv4. V obratno smer je šlo v redu, preko IPv6, od njim k meni pa nikakor ne. Po nekem čudnem naključju so se ti strežniki odločili, da dostavijo preko IPv4, kar je še bolj čudno je pa to, da ne čisto vedno, bile so svetje redke izjeme, ko sem na strežnik dobil pošto preko IPv6. Preveril sem iz kar nekaj strežnikov (recimo tudi ran.psg.com) in IPv6 povezava na port 25 na mail.go6.si je delovala čisto brez težav.
Poglavitno vprašanje sedaj je, zakaj so se remote strežniki odločili za IPv4 dostavo?
Ko sem odstranil drugi MX zapis, ki je kazal na 4.go6.si je zadeva spet začela normalno delovati in začel sem dobivati pošto preko IPv6.
Weird. Very very weird. Skratka, če hočete dobivati pošto preko IPv6, ne uporabite tega hacka.
Jan Žorž
Vaš IP naslov (ali ste na IPv6 ?):
3.15.142.252
Comments(5)
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.
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.
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š
@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.
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