Как по мне, то CNAME (при всей кажущейся красоте и полезности этого типа записи), не должны использоваться вообще. Я уже многие годы стараюсь использовать A вместо CNAME и не припомню случая, когда этого было бы недостаточно. Даже гипотетически не могу сконструировать ситуацию, когда использование CNAME давало бы выигрыш по сравнению с множественными A записями. Впрочем, я еще толком не проснулся :) Хотя да, сама идея CNAME мне нравится. Просто нерационально.
Все это безотносительно MX, вообще. > On Jun 16, 2016, at 6:51 PM, Dmitry Bogun <[email protected]> wrote: > >>>>> Проблема в том, что mail.p.nyaka.org - это CNAME(этого я изменить не могу) >>>> RFC уже не в моде =( >>> Который именно? Это ж "ручной" роутинг, кто нам тут что запрещает? >> >> Тут я "промазал": почему-то решил, что речь про MX'ы. Пардон. >> >>> Единственный "запрет" на CNAME в отношении почты, который я помню - для MX >>> записей. И то там не запрет, а "особое" поведение в случае CNAME. >> >> Про запрет знаю, а вот про "особое поведение" - не слышал. Ткнёте >> пальцем в соответствующее RFC? > > Да, я таки подзабыл чуток правила - это "специальное" поведение касалось не > mx записи, а самого домена, когда он "разрешается" через cname - то этот > домен обрабатывается как domain alias. > (http://tools.ietf.org/html/rfc2821#section-5) > > про cname в mx'а компрады уже понаписывали. > >> >>>> Как подручная затычка: с периодичностью меньше самого минимального ttl >>>> из всех используемых smart-host'ов прогонять цикл, который будет >>>> резолвить cname (например, с помощью `dig +norecurse +short smart-host') >>>> и записывать в CONFDIR/auth-virtual-client >>>> Судя по всему, в итоге получится не однострочник, а целый скриптик с >>>> проверками, но, если цель оправдывает средства, то почему бы и нет =) >> >>> Тоже вариант. Но мне он не нравится. Не люблю я poll скрипты. >> >> [...] >> >>> Еще можно зайти по крупному и "взять" в руки perl. >> >> Чем это лучше shell-скрипта? =) > > Как минимум тем, что работает только в правильные моменты времени(во время > обработки сообщения) и обладает всеми нужными данными. > > Имелось ввиду использование встроенного в exim perl'а, а не сторонний скрипт > на perl'е вместо shell'а. > _______________________________________________ > Exim-users mailing list > [email protected] > http://mailground.net/mailman/listinfo/exim-users >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Exim-users mailing list [email protected] http://mailground.net/mailman/listinfo/exim-users
