Я заметил странное поведение моего домена приложений Google. Большинство писем приходит, как и следовало ожидать, но со временем я пришел к выводу, что письма от определенный отправители не проходят. После идентификации одного такого отправителя, чьи письма не приходили, я попросил его попытаться отправить мне электронное письмо и переслать ответ «ошибка доставки» на мой обычный Gmail.
Ответ о сбое доставки содержал следующий фрагмент:
----- Стенограмма сессии следует -----
<myusername@GHS.L.GOOGLE.COM>... Отложено: время ожидания соединения с ghs.l.google.com истекло.
Это помогло мне определить проблему, выполнив быстрый поиск, который привел меня к эта страница на справочном форуме Google Apps. Действительно, я проверил 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 Apps.
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. com. Затем он попытался найти записи MX для ghs.l.google.com. В этом домене в настоящее время нет записей MX, поэтому почтовый сервер перешел к записи A для ghs.l.google.com. Этот IP-адрес не прослушивал порт SMTP, поэтому возникает ошибка «Превышено время ожидания соединения с ghs.l.google.com».
Удалив запись CNAME, вы устранили проблемы с почтой. Вы можете столкнуться с проблемами, если IP-адрес, который вы указали вместо него, будет изменен на стороне Google.
Вместо этого вы можете определить cname для 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 для электронной почты. Возможно, у вас даже есть ошибки в файле зоны - проверьте их у компетентного администратора зоны.