Не надходить повідомлення від деяких відправників через конфігурацію DNS

Я помітив особливу поведінку домену моїх програм 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. Вони часто неправильно використовуються, неправильно розуміються та неправильно реалізуються. :-)

Якщо ваш домен je 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 "Псевдоніми та канонічні імена" рекомендує проти цієї конфігурації:

Якщо RAME CNAME присутній у вузлі, інших даних не повинно бути; це гарантує, що дані для канонічного імені та його псевдонімів не можуть бути різними.

У випадку помилки, яку ви вставили, поштовий сервер та / або сервер 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, ви усунули проблеми з поштою. Ви можете зіткнутися з проблемами, якщо в кінці Google буде змінено IP-адресу, яку ви визначили на її місці.

Ви можете замість цього визначити ім'я для 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 для електронної пошти. Можливо, у вашому зоновому файлі навіть є деякі помилки - перевірте їх компетентним адміністратором зони.