Не получает письма от некоторых отправителей из-за настройки DNS

Я заметил своеобразное поведение моего домена приложений Google. Большая часть писем поступает так, как вы и ожидаете, но через некоторое время я пришел к выводу, что письма от определенных отправителей не поступают. После идентификации одного такого отправителя, чьи письма не были получены, я попросил его попытаться отправить мне электронное письмо и переслать ответ «ошибка доставки» в мой обычный почтовый ящик.

Ответ об ошибке доставки содержал следующий фрагмент:

----- Стенограмма сеанса следующая -----
<myusername@GHS.L.GOOGLE.COM>... Отложено: Время соединения истекло с ghs.l.google.com.

Это помогло мне определить проблему, выполнив быстрый поиск, который привел меня на эту страницу на Справочном форуме Служб Google. Действительно, я проверил запись DNS для своего домена и @был установлен на ghs.google.com. (CNAME), чего не должно быть. Изменение на @ 74.125.93.121 (A)* решило проблему.

Я понимаю, что в тех случаях, когда почта не проходила, мое доменное имя заменялось его каноническим именем при поиске CNAME, поэтому письмо было отправлено myusername@ghs.l.google.comвместо myusername@mydomain.com. Но почему это работает для подавляющего большинства отправителей? Использовали ли отправители, чья почта не пришла, какой-то другой почтовый протокол, какие-то странные настройки DNS или что это может быть?

Из того, что я мог видеть, исследуя проблему в Google, это, кажется, распространенная проблема (многие люди, жалующиеся на электронные письма с Battle.net не приходят, был бы одним популярным примером), только то, что люди не кажутся знать, что проблема заключается в их собственных настройках DNS, а не на стороне отправителя.

Так как это можно объяснить?

^{* Я использовал этот IP из-за того, что я здесь прочитал , но я думаю, что любой IP справился бы с задачей. Кто-нибудь может это подтвердить? Обратите внимание, что простое удаление @записи не решило проблему, ее пришлось изменить.}

Из RFC 2821 «Простой протокол передачи почты», раздел 5 «Разрешение адресов и обработка почты»:

Сначала поиск пытается найти запись MX, связанную с именем. Если вместо этого найдена запись CNAME, результирующее имя обрабатывается так, как если бы оно было начальным именем.

В общем, так работают CNAME. Их часто неправильно используют, неправильно понимают и неправильно применяют. :-)

Если ваш домен - example.com, у вас, вероятно, есть записи MX, указывающие на обычные хосты Служб Google.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Похоже, у вас также есть запись, как это:

example.com. CNAME ghs.l.google.com.

RFC 1034 «Концепции и возможности домена» в разделе 3.6.2 «Псевдонимы и канонические имена» рекомендует в отношении этой конфигурации:

Если CNAME RR присутствует на узле, никакие другие данные не должны присутствовать; это гарантирует, что данные для канонического имени и его псевдонимов не могут быть разными.

В случае вставленной вами ошибки почтовый сервер и / или DNS-сервер на отправляющей стороне попытались найти записи MX для вашего домена example.com и обнаружили CNAME, указывающую на ghs.l.google. ком. Затем он попытался найти записи MX для ghs.l.google.com. В этом домене в настоящее время нет записей MX, поэтому почтовый сервер перешел бы на запись A для ghs.l.google.com. Этот IP-адрес не прослушивался через порт SMTP, поэтому в результате возникает ошибка «Превышено время соединения с ghs.l.google.com».

Удалив запись CNAME, вы исправили проблемы с почтой. Вы можете столкнуться с проблемами, если IP-адрес, который вы указали вместо него, будет изменен на стороне Google.

Вместо этого вы можете определить имя для www.example.com:

www.example.com. CNAME ghs.l.google.com.

И запустите небольшой веб-сервер с любым IP-адресом, на который вы указываете example.com, который просто перенаправляет HTTP на http://www.example.com/

Несколько удивительно, что это сработало так же, как и было. Я полагаю, что закон Постеля заслуживает доверия. :-)

Вернуться к RFC 1034 2.6.2:

CNAME RR вызывают специальные действия в программном обеспечении DNS. Когда серверу имен не удается найти нужный RR в наборе ресурсов, связанном с именем домена, он проверяет, состоит ли набор ресурсов из записи CNAME с соответствующим классом. Если это так, сервер имен включает в ответ запись CNAME и перезапускает запрос на доменном имени, указанном в поле данных записи CNAME. Единственным исключением из этого правила является то, что запросы, соответствующие типу CNAME, не перезапускаются.

Таким образом, в этом случае можно утверждать, что DNS-сервер не будет / не должен следовать CNAME при поиске MX, если не было найдено записей MX.

При отправке почты Sendmail и qmail (и, вероятно, другие) по умолчанию будут пытаться переписать любое CNAME, использованное в правой части адреса электронной почты, в каноническое имя.

Действительно, некоторые сайты полагались на такое поведение. djb подробно объясняет, почему он считает, что люди должны перестать полагаться на него, в его документе «Записи CNAME по почте» .

@Символ в BIND записи просто сокращенный способ написания домена. Если вы создаете запись для example.com, то @это просто псевдоним для example.com. Сказать, что @запись должна быть IP-адресом, - это утверждение, в котором отсутствует критическая информация - вы не сказали нам, что это была за запись.

Из отчета о доставке кажется, что вы, возможно, что-то сделали со своим DNS, чтобы удаленный почтовый сервер переписал ваш домен на ghs.l.google.com - очень странно (PS, запись A должна быть IP, запись CNAME не должен быть IP или другой записью CNAME).

Почему этот почтовый сервер переписывает ваш адрес странно - это не должно происходить, если этот человек не сделал что-то, чтобы явно сказать ему переписать его. Также не должно быть никакого значения, какой IP-адрес вашего домена, если только он не может найти записи MX, поскольку записи MX определяют, как почта отправляется.

Мне кажется, учитывая очень мало предоставленной информации, что вы вообще не следовали инструкциям Google о том, как правильно настроить DNS для электронной почты. Возможно, у вас даже есть ошибки в файле зоны - их должен проверить компетентный администратор зоны.