RFC 7505 | Запись ресурса службы «Null MX» для доменов, которые не принимают почту

Аннотация

Интернет-почта определяет адрес принимающего сервера через DNS, сначала путем поиска записи MX, а затем путем поиска записи A / AAAA в качестве запасного варианта. К сожалению, это означает, что запись A / AAAA считается адресом почтового сервера, даже если этот адрес не принимает почту. No Service MX RR, неофициально называемый «null MX», формализует существующий механизм, посредством которого домен объявляет, что он не принимает почту, без необходимости предоставлять почтовый сервер; Это позволяет значительно повысить эффективность работы.

Скачать оригинальный документ на английском языке RFC 7505 PDF

1. Введение
2. Условные обозначения, используемые в этом документе
3. Записи ресурса MX, указывающие нулевой MX
4. Эффекты Null MX
4.1. Преимущества SMTP-сервера
4.2. Отправка почты с доменов, которые публикуют Null MX
5. Вопросы безопасности
6. Соображения IANA
7. Ссылки
7.1. Нормативные ссылки
7.2. Информационные ссылки
Благодарности
Авторы Адреса

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7505.

Уведомление об авторских правах

Этот документ регулируется BCP 78 и правовыми положениями IETF Trust, касающимися документов IETF.

(http://trustee.ietf.org/license-info), действующий на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

1. Введение

Этот документ определяет No Service MX, неофициально называемый «null MX», как простой механизм, с помощью которого домен может указать, что он не принимает электронную почту.

Клиенты SMTP имеют предписанную последовательность для идентификации сервера, который принимает электронную почту для домена. Раздел 5 [RFC5321] охватывает это подробно; по сути, SMTP-клиент сначала ищет DNS MX RR, и, если он не найден, он возвращается к поиску DNS A или AAAA RR. Следовательно, это перегружает запись DNS (которая имеет другое основное предназначение) семантикой службы электронной почты.

Если в домене нет записей MX, отправители будут пытаться доставлять почту хостам по адресам в записях домена A или AAAA. Если на адресах A / AAAA нет прослушивателей SMTP, будет предпринята попытка доставки сообщения в течение длительного периода времени, обычно в течение недели, до того как агент передачи почты (MTA) откажется. Это задержит уведомление отправителя в случае перенаправления почты и потребит ресурсы у отправителя.

Этот документ определяет нулевой MX, который приведет к немедленному сбою всех попыток доставки почты в домен, не требуя от доменов создания SMTP-прослушивателей, предназначенных для предотвращения попыток доставки.

2. Условные обозначения, используемые в этом документе

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

Термины «RFC5321.MailFrom» и «RFC5322.From» используются, как определено в [RFC5598].

3. Записи ресурса MX, указывающие нулевой MX

Чтобы указать, что домен не принимает электронную почту, он объявляет одну запись MX RR (см. Раздел 3.3.9 [RFC1035]) с разделом RDATA, состоящим из номера предпочтения 0 и метки нулевой длины, записанной в основных файлах как «. «, как домен обмена, для обозначения отсутствия почтового обменника для домена. Поскольку «.» не является допустимым именем хоста, пустая запись MX не может быть перепутана с обычной записью MX. Использование «.» в качестве псевдо-имени хоста, означающего, что никакая доступная услуга не смоделирована на SRV RR [RFC2782], где оно имеет аналогичное значение.

Домен, который рекламирует нулевой MX, НЕ ДОЛЖЕН рекламировать другие MX RR.

4. Эффекты Null MX

Нулевая запись MX имеет ряд преимуществ в плане эффективности и удобства использования.

4.1. Преимущества SMTP-сервера

Почта часто имеет неправильный адрес из-за ошибки пользователя, когда адрес был неправильно переписан или неправильно понят, например, alice@www.example.com, alice@example.org или alice@examp1e.com, а не alice@example.com , Null MX позволяет почтовой системе сообщать об ошибке доставки, когда пользователь отправляет сообщение, а не через несколько часов или дней.

Отправители оскорбительной почты часто используют поддельные недоставленные обратные адреса. Null MX позволяет эффективно отправлять уведомления о доставке (DSN) и другие попытки ответа на такую почту.

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

Когда сервер отправки или ретрансляции SMTP отклоняет получателя конверта из-за нулевой записи MX домена, он ДОЛЖЕН использовать код ответа 556 [RFC7504] (Запрошенное действие не выполнено: домен не принимает почту) и расширенный код состояния 5.1.10 ( Постоянный сбой: адрес получателя имеет нулевой MX).

Получающий SMTP-сервер, который выбирает отклонение электронной почты во время SMTP-диалога, который представляет недоставленный домен RFC5321.MailFrom или RFC5322.From, может быть более уверенным, что для других сообщений последующая попытка отправить DSN или другой ответ достигнет SMTP-сервера получателя.

SMTP-серверам, которые отклоняют почту, поскольку домен RFC5321.MailFrom или RFC5322.From имеет нулевую запись MX, ДОЛЖЕН использовать код ответа 550 (Запрошенное действие не выполнено: почтовый ящик недоступен) и расширенный код состояния 5.7.27 (постоянный сбой: адрес отправителя имеет нулевой MX).

4.2. Отправка почты с доменов, которые публикуют Null MX

Null MX в первую очередь предназначен для доменов, которые не отправляют и не получают почту, но в любом случае им отправляется почта из-за ошибок или злого умысла. Многие принимающие системы отклоняют почту с неправильным обратным адресом. Обратные адреса необходимы, чтобы отправитель мог обрабатывать ошибки доставки сообщений. Неверный обратный адрес часто сигнализирует о том, что сообщение является спамом. Следовательно, почтовым системам НЕ СЛЕДУЕТ публиковать пустую запись MX для доменов, которые они используют в адресах RFC5321.MailFrom или RFC5322.From. Если система, тем не менее, делает это, она рискует отклонить свою почту.

Операторы доменов, которые не отправляют почту, могут опубликовать «-all» политики Sender Policy Framework (SPF) [RFC7208], чтобы сделать явное заявление о том, что домены не отправляют почту.

Null MX не предназначен для замены нулевого обратного пути, описанного в Разделе 4.5.5 RFC 5321, и не меняет значение или использование нулевого обратного пути.

5. Вопросы безопасности

В DNS нулевой MX RR является обычной записью MX и не представляет никаких новых проблем безопасности. При желании он может быть защищен так же, как и любая другая запись DNS с использованием DNSSEC.

6. Соображения IANA

Code: X.1.10
Sample Text: Адрес получателя имеет нулевой MX
Associated basic status code: 556
Description: Этот код состояния возвращается, когда связанный адрес помечается как недействительный с использованием нулевого MX.
Reference: Этот документ
Submitter: Авторы этого документа
Change controller: IESG

Code: X.7.27
Sample Text: Адрес отправителя имеет нулевой MX
Associated basic status code: 550
Description: Этот код состояния возвращается, когда связанный адрес отправителя имеет нулевой MX, и получатель SMTP настроен на отклонение почты от такого отправителя (например, потому что он не мог вернуть DSN).
Reference: Этот документ
Submitter: Авторы этого документа
Change controller: IESG

7. Ссылки

7.1. Нормативные ссылки

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[RFC7504] Klensin, J., «SMTP 521 and 556 Reply Codes», RFC 7504, DOI 10.17487/RFC7504, June 2015, <http://www.rfc-editor.org/info/rfc7504>.

7.2. Информационные ссылки

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.

[RFC5598] Crocker, D., «Internet Mail Architecture», RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.

[RFC7208] Kitterman, S., «Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1», RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.

Благодарности

Мы благодарим Дэйва Крокера за его усердное и длительное руководство этим документом, а также членов рабочей группы APPSAWG за их конструктивные предложения.

Авторы Адреса

John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
United States
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly

Mark Delany
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
United States
Email: mx0dot@yahoo.com