«DNS и BIND»

5. DNS и электронная почта

MX-алгоритм

Такова основная идея MX-записей и почтовых ретрансляторов, но есть и кое-что еще, о чем следует знать. Чтобы избежать петель маршрутизации, почтовые программы должны использовать чуть более сложный алгоритм, чем в случае принятия решения о том, куда направлять почтовые сообщения.[1]

Представим, что может произойти, если почтовые программы не будут учитывать появление петель маршрутизации. Допустим, необходимо отправить на адрес nuts@oreilly.com почтовое сообщение, содержащее негодующий отзыв об этой книге. К сожалению, узел ora.oreilly.com в данный момент недоступен. Никаких проблем! Что написано в MX- записях для oreilly.com?

oreilly.com.    IN MX    0 ora.oreilly.com.
oreilly.com.    IN MX   10 ruby.oreilly.com.
oreilly.com.    IN MX   10 opal.oreilly.com.

Почтовая программа принимает решение отправить почту через узел ruby.oreilly.com, который исправно функционирует. Почтовая программа на ruby.oreilly.com пытается передать почту узлу ora.reilly.com, естественно безрезультатно, поскольку этот узел пребывает в нерабочем состоянии. И что дальше? Если на ruby.oreilly.com не предусмотрена проверка разумности действий, будет предпринята попытка передать почту узлу opal.oreilly.com либо самому узлу ruby.oreilly.com. Разумеется, это не даст никакого результата в плане доставки почтовых сообщений. Если ruby.oreilly.com отправит сообщение себе, получится петля маршрутизации. Если ruby.oreilly.com отправит сообщение узлу opal.oreilly.com, opal.oreilly.com либо вернет это сообщение узлу ruby.oreilly.com, либо пошлет себе, и в этом случае снова получится петля маршрутизации.

Чтобы предотвратить подобные вещи, почтовые программы исключают из рассмотрения некоторые MX-записи перед принятием решения о том, куда посылать сообщения. Почтовая программа сортирует список MX-записей по приоритетам и производит поиск канонического доменного имени узла, на котором запущена сама программа. Если текущий узел является почтовым ретранслятором, программа исключает эту MX-запись, а также все MX-записи с приоритетами, большими или равными значению из первой исключаемой записи (то есть исключает менее предпочтительные и столь же предпочтительные почтовые ретрансляторы). Таким образом, предотвращается отправка почты узлом самому себе либо узлам, которые расположены «дальше» от конечного пункта назначения.

Вернемся к аналогии с аэропортом. На этот раз представьте себе, что вы - пассажир самолета (почтовое сообщение), который пытается попасть в Грили, штат Колорадо. Прямого рейса до Грили нет, но можно воспользоваться рейсом до города Форт-Коллинз или до Денвера (двумя из более предпочтительных почтовых ретрансляторов). Поскольку Форт-Коллинз ближе к Грили, вы выбираете именно этот рейс.

Итак, очутившись в Форт-Коллинзе, вы понимаете, что смысла лететь в Денвер нет, поскольку это отдалит вас от пункта назначения (и будет выбором менее предпочтительного почтового маршрутизатора). А лететь из Форт-Коллинза в Форт-Коллинз и вовсе глупо. Так что единственным приемлемым рейсом остается прямой рейс из Форт-Коллинза в Грили. Таким образом, вы можете не рассматривать рейсы до менее предпочтительных пунктов, чтобы предотвратить рейсовые петли и не терять лишнее время на дорогу.

Одно предостережение: большинство почтовых программ производят поиск исключительно канонического доменного имени текущего узла в списке MX-записей. Псевдонимы (доменные имена в левой части CNAME-записей) не рассматриваются. Нет никаких гарантий, что почтовая программа сможет обнаружить свой узел в списке MX-записей, если в этих записях не были использованы канонические доменные имена; в таком случае существует риск появления петель маршрутизации.

Если же почтовый ретранслятор был определен через псевдоним и наивно пытается доставить почту самому себе, в большинстве случаев будет определена почтовая петля, и почта вернется отправителю с сообщением об ошибке. Вот это сообщение в изложении последних версий sendmail:

554 MX list for movie.edu points back to relay.isp.com
554 ... Local configuration error @movie.edu>

Это сообщение заменило замысловатое «I refuse t o talk to myself» («Отказываюсь разговаривать с собой»), которое было присуще более старым версиям sendmail. Мораль: всегда используйте каноническое доменное имя почтового ретранслятора в MX-записях.

И еще одно предостережение: для узлов, перечисленных в качестве почтовых ретрансляторов, должны существовать адресные записи. Почтовая программа должна быть в состоянии определить адрес почтового ретранслятора, чтобы попытаться доставить через него сообщения.

Вернемся к примеру с oreilly.com, где узел ruby.oreilly.com получает сообщение от читателя. Почтовая программа сверяется со списком MX-записей:

oreilly.com.    IN MX    0 ora.oreilly.com.
oreilly.com.    IN MX   10 ruby.oreilly.com.
oreilly.com.    IN MX   10 opal.oreilly.com.

Обнаружив доменное имя текущего узла в списке, почтовая программа на ruby.oreilly.com исключает из рассмотрения записи с приоритетом 10 или выше (записи выделены жирным шрифтом):

oreilly.com.    IN MX    0 ora.oreilly.com.
oreilly.com.    IN MX   10 ruby.oreilly.com.
oreilly.com.    IN MX   10 opal.oreilly.com.

после чего остается только:

oreilly.com.    IN MX    0 ora.oreilly.com.

Поскольку узел ora.oreilly.com неработоспособен, ruby.oreilly.com откладывает доставку сообщения, помещая его в очередь.

А что происходит в случае, когда почтовая программа обнаруживает, что текущий узел имеет наивысший приоритет (наименьшее число в MX-записи) и что в связи с этим следует исключить все MX-записи из списка? Некоторые почтовые программы пытаются произвести прямую доставку по IP-адресу конечного узла в качестве последнего средства. Однако в большинстве почтовых программ такая ситуация считается ошибкой. Она может возникать в т ом случае, если DNS считает, что почтовая программа должна обрабатывать (а не просто передавать дальше) почту для определенного узла, но почтовая программа не была соответствующим образом настроена. Или же если администратор некорректно расположил MX-записи, используя неверные приоритеты.

Скажем, ребята, которые управляют доменом acme.com, добавили MX-запись, чтобы передавать почту, адресованную acme.com, почтовой программе своего интернет-провайдера:

acme.com. IN MX 10 mail.isp.net.

Обычно почтовая программа должна быть настроена так, чтобы распознавать собственные псевдонимы и имена узлов, для которых она производит обработку почты. Если почтовая программа узла mail. isp.net не была сконфигурирована так, чтобы распознавать почтовые адреса домена acme.com в качестве локальных, она будет считать, что пришел запрос на передачу почты, и попытается отправить сообщения почтовому ретранслятору, который находится ближе к пункту назначения.[2] После изучения MX-записей для acme.com программа обнаружит, что текущий узел является наиболее предпочтительным почтовым ретранслятором, после чего вернет почтовое сообщение отправителю с уже знакомой нам ошибкой:

554 MX list for acme.com points back to mail.isp.net
554 ... Local configuration error @acme.com>

Во многих версиях программы sendmail используется класс w или файловый класс w для определения списка «местных» пунктов доставки.

В зависимости от существующего файла sendmail.cf добавление псевдонима может сводиться просто к добавлению к этому файлу строки:

Cw acme.com

Внимательные читатели, наверно, заметили, что для приоритетов мы используем числа, кратные 10. Десятка удобна, поскольку позволяет временно добавлять MX-записи с промежуточными значениями, не меняя значений всех остальных записей, и больше никакого волшебства здесь нет. Мы могли бы с тем же успехом использовать приращение 1 или 100.

[1] Этот алгоритм основан на документе RFC 2821, в котором описана почтовая маршрутизация в сети Интернет.
[2] Разумеется, речь идет о том, что почтовая программа mail.isp.net вообще позволяет передачу почты для неизвестных ей доменных имен. В противном случае в доставке почтовых сообщений просто будет отказано.