RFC 7504 | 521 и 556 коды ответов SMTP

Аннотация

В этой записке определены два кода ответа SMTP — 521 и 556. Код 521 был первоначально описан в экспериментальном RFC в 1995 году и широко используется, но ранее официально не включался в SMTP. Код 556 был создан для поддержки новых тестов и действий, указанных в RFC 7505. Эти коды используются для указания того, что хост Интернета вообще не принимает входящую почту. Эта спецификация не применима, когда хост иногда принимает почту, но может отклонить определенные сообщения или даже все сообщения при определенных обстоятельствах.

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

1. Введение
1.1. Терминология
2. Предпосылки
3. Код ответа 521
4. Код ответа 556
5. Мелкие детали, чтобы избежать свободных концов
5.1. Конкретные изменения в RFC 5321
5.2. RFC 1846 Эксперимент
6. Соображения IANA
7. Вопросы безопасности
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Благодарности
Адрес автора

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

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

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

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

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

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

1. Введение

Спецификация SMTP [2] (упоминаемая вместе с ее различными обновлениями как «SMTP» ниже) содержит список и обсуждение кодов ответов. Этот документ обновляет этот список новым кодом 521 для использования в ответ на первоначальное соединение. В этом контексте это определенно обозначает систему, которая не получает почту или иным образом обрабатывает почту SMTP или транзакции запроса. Этот код отличается от использования кода ответа 554, рекомендованного в RFC 5321, поскольку последний код может использоваться в большем разнообразии ситуаций, включая почту, которая не принимается для определенных источников, адресатов или адресов, или из них. Он также вводит второй код ответа, 556, для использования, когда SMTP-клиент обнаруживает домен по адресу, указанному в прямом направлении, который он может определить (например, из соглашения DNS «null MX» [5]), не поддерживает получение почты и должен сообщить об этом состоянии хосту, который доставил ему сообщение для дальнейшей обработки.

Эта спецификация обновляет RFC 5321 для добавления новых кодов. Код 521 был впервые официально предложен в Экспериментальном RFC 1846 [4]; этот документ обновляет эту спецификацию, чтобы стандартизировать код и предоставить более конкретный подход к нему.

1.1. Терминология

Предполагается, что читатель этого документа хорошо знаком со спецификацией SMTP в RFC 5321, в частности, с обсуждением кодов ответов, их использованием и теорией.

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

2. Предпосылки

Многие интернет-хосты не в состоянии — ни технически, ни оперативно, ни административно — предложить почтовые услуги. Если SMTP-клиент (отправитель) пытается открыть почтовое соединение с системой, в которой нет SMTP-сервера, попытка подключения будет прервана. SMTP требует, чтобы тайм-ауты приводили к тому, что клиент ставил сообщение в очередь и повторял его в течение продолжительного периода времени. Такое поведение приведет к потере впустую ресурсов и длительным задержкам в получении сообщения об ошибке обратно его отправителю.

Одна альтернатива — запустить фиктивный SMTP-сервер на хостах, которые ни при каких условиях не получают почту и заставляют этот фиктивный сервер возвращать код ответа с неустранимой ошибкой в ответ на любую попытку открытия соединения. Другой способ — определить из отдельного источника, такого как запись DNS, что хост не получает почту. Этот документ определяет коды ответов, которые будут использоваться для этих целей.

3. Код ответа 521

Эта спецификация добавляет код ответа 521 к репертуару, указанному в SMTP, резервируя его для использования во время открытия соединения, чтобы указать, что хост не принимает почту ни при каких обстоятельствах. Он ДОЛЖЕН использоваться для фиктивных SMTP-серверов, единственной целью которых является уведомление систем, пытающихся открыть почтовые соединения, о том, что хост никогда не принимает почту. Он МОЖЕТ использоваться в других ситуациях, когда целью является указание, что хост никогда не принимает почту. Его НЕ СЛЕДУЕТ использовать в ситуациях, когда сервер отклоняет почту от определенных хостов или адресов, или когда почта для определенного хоста назначения не принимается. Как обсуждалось в SMTP, код ответа 554 больше подходит для большинства из этих условий; дополнительный случай, в котором определение того, что почта не принята, определяется за пределами почтовой системы, рассматривается в следующем разделе (раздел 4).

«Server does not accept mail — Сервер не принимает почту» (или такой вариант, как «Host — Хост», «Domain — Домен» или связанный термин) — это приемлемое сообщение, сопровождающее код 521, используемый для этой цели.

Как только код ответа 521 возвращается вместо обычного 220, сеанс SMTP проходит нормально. Если SMTP-клиент пытается отправить дополнительные команды, отличные от QUIT, сервер МОЖЕТ либо продолжить отправку 521 кодов ответа, либо просто закрыть соединение. Если целью запуска фиктивного SMTP-сервера, который возвращает код 521, является сохранение ресурсов, последний, как правило, предпочтительнее.

4. Код ответа 556

Эта спецификация добавляет код ответа 556 к репертуару, указанному в SMTP. Когда промежуточная SMTP-система (обычно ретранслятор), которая обычно пытается открыть почтовое соединение с хостом, указанным в адресе, указывающем на переадресацию, может определить, что хост не принимает почтовые соединения, и делает это, не пытаясь открыть соединение этому целевому хосту целесообразно вернуть ответ с кодом 556 в систему, которая отправила ему сообщение для исходящей передачи. Интерпретация специальной записи DNS, найденной при выполнении поиска в сочетании с командой RCPT [5], является одним из таких методов (и единственным стандартизированным на момент написания данной спецификации).

Когда SMTP-сервер возвращает код ответа 556 после получения команды (например, RCPT, которая содержит адрес, указывающий на переадресацию), поскольку у него есть информация (например, как обсуждалось выше), что почта не будет принята, ожидается, что SMTP-клиент обрабатывать ответ как любой другой постоянный отрицательный ответ о завершении команды. Это соответствует спецификации SMTP.

5. Мелкие детали, чтобы избежать свободных концов

5.1. Конкретные изменения в RFC 5321

Этот документ добавляет код 521 с сообщением «Хост не принимает почту» и код 556 с сообщением «Домен не принимает почту» в функциональную группу и числовые списки (разделы 4.2.2 и 4.2.3 соответственно ) RFC 5321. Он также добавляет код 521 к части «УСТАНОВЛЕНИЕ СОЕДИНЕНИЯ» раздела 4.3.2 («Последовательности команд-ответов»), предшествующей коду 554, и коду 556 к части «RCPT» того же самого раздел.

5.2. RFC 1846 Эксперимент

Формализируя код ответа 521, эта спецификация завершает эксперимент, предложенный в RFC 1846. В этом документе также обсуждаются общие стратегии для хостов, которые не принимают почту напрямую. Это обсуждение выходит за рамки настоящего документа.

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

Этот документ обновляет RFC 5321, добавляя описания и текст для двух кодов ответов, но для этих кодов нет реестра. IANA обновила подсистему «Перечисленные коды состояния» в «Реестре расширенных кодов состояния SMTP» [3], включив в них следующие коды, а именно:

Добавлен 521 в список кодов, связанных с расширенной записью кода для X.3.2, которая теперь ссылается на этот документ.
Добавлен этот документ к ссылкам, связанным с расширенной записью кода для X.1.10 и кодом ответа 556. Обратите внимание, что, если возникает использование для 556, которое не связано с нулевым MX [5], может потребоваться добавить дополнительный расширенный код, но такое действие выходит за рамки этого документа.

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

Отсутствие какого-либо SMTP-сервера или SMTP-сервер, который просто генерирует фиксированные строки в ответ на входящие соединения, должно обеспечить значительно меньше возможностей для проблем безопасности, чем полная реализация SMTP. См. Раздел «Вопросы безопасности» в RFC 7505 [5] для обсуждения проблем безопасности с этим подходом. Использование определенных кодов, представленных здесь, предоставляет клиенту больше информации, чем общий или произвольно выбранный код 5yz, но не должен оказывать никакого другого влияния на безопасность.

8. Ссылки

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

[1] 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>.

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

[3] IANA, «Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry», <http://www.iana.org/assignments/smtp-enhanced-status-codes>.

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

[4] Durand, A. and F. Dupont, «SMTP 521 Reply Code», RFC 1846, OI 10.17487/RFC1846, September 1995, <http://www.rfc-editor.org/info/rfc1846>.

[5] Levine, J. and M. Delany, «A «Null MX» No Service Resource Record for Domains That Accept No Mail», RFC 7505, DOI 10.17487/RFC7505, June 2015, <http://www.rfc-editor.org/info/rfc7505>.

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

Ален Дюран и Фрэнсис Дюпон предложили код 521 в RFC 1846 [4]. Они также участвовали в расширенной беседе и предоставили много полезных комментариев, которые привели к этому документу. Документ также содержит, с их разрешения, некоторый текст, скопированный из этой ранней спецификации.

Обсуждение подхода и предложения «null MX» [5] вдохновило на создание этой спецификации. Конкретные комментарии и предложения от Джона Левина (соавтор этого документа) также были полезны. Мартин Дюрст и Том Петч определили существенные проблемы в первоначальном проекте текущей формы документа.

Дилян Палаузов внимательно прочитал и выявил редакционную ошибку.

Нед Фрид, Тони Хансен и Рольф Сонневелд предложили внести текстовые улучшения. Тони Хансен также выступал в качестве пастора документов и сделал несколько вкладов в связи с этой ролью.

Адрес автора

John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
United States
Phone: +1 617 245 1457
Email: john-ietf@jck.com