Перевод RFC 2476

Network Working Group R. Gellens

Request for Comments: 2476 QUALCOMM

Category: Standards Track J. Klensin

MCI December 1998

Прием сообщений от пользователей

Message Submission

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Авторские права

Оглавление

1. Тезисы ....................................................................................................................................................................................... .................... 1

2. Сведения о документе ........................................................................................................................................................ ...... ...................... 2

2.1. Определения используемых терминов ................................................................................................................................... ...........2

2.2. Используемые в документе соглашения ........................................................................................................................ .................. 2

3. Подача сообщений ............................................................................................................................................................. ........................... 2

3.1. Идентификация подачи сообщения .................................................................................................................................... .. ............. 2

3.2. Отказ от приема сообщений ..................................................................................................................................................... ........ 3

3.3. Уполномоченная подача сообщений ....................................................................................................................................... ..........3

3.4. Расширенные коды состояния ................................................................................................................................................ .......... 3

Обязательные действия ............................................................................................................................................................................ ..3...

4.1. Код общего назначения для отказа при подаче сообщения .......................................................................................... ................ 3

4.2. Все домены должны быть полными (Fully-Qualified) ................................................................................................................. ...3. .

Рекомендуемые действия .............................................................................................................................................................. ............. 4

5.1. Обеспечение корректного синтаксиса адресов .............................................................................................................................. 4...

5.2. Протоколирование ошибок ....................................................................................................................................................... .........4

Дополнительные действия .............................................................................................................................................................. ........... 4

6.1. Выполнение правил подачи сообщений .............................................................................................................................. ....... ....... 4

6.2. Требование аутентификации ..................................................................................................................................................... ....... 4

6.3. Проверка полномочий .................................................................................................................................................. ...... .. ............... 4

6.4. Проверка данных в сообщении ....................................................................................................................................................... .4...

Взаимодействие с расширениями SMTP ................................................................................................................................. ...... ............. 4

Изменение сообщений ................................................................................................................................................................. ............... 5

8.1. Добавление поля 'Sender' ..................................................................................................................................................... ...... ......... 5

8.2. Добавление поля 'Date' ................................................................................................................................................. ...................... 5

8.3. Добавление поля 'Message-ID' .................................................................................................................................................... ...... 5

8.4. Транспортное кодирование ........................................................................................................................................... .................... 5

8.5. Включение сигнатуры .................................................................................................................................................... ..... .. .............. 5

8.6. Шифрование сообщений ............................................................................................................................................................. ...........5

8.7. Преобразование псевдонимов ......................................................................................................................................................... .6..

8.8. Перезапись заголовков.

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

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

11. Литература ........................................

12. Адреса авторов .................................

13. Полное заявление авторских прав.

1. Тезисы

SMTP был определен как протокол пересылки (transfer) сообщений, т. е., он способен маршрутизировать (если нужно) и доставлять почтовые сообщения. Не предполагается, что агенты пересылки сообщений (MTA¹) изменяют текст этих сообщений за исключением добавления 'Received', 'Return-Path' и других полей заголовков в соответствии с требованиями [SMTP-MTA].

¹Message Transfer Agent

rfc.com.ru

Перевод RFC 2476

Однако в настоящее время SMTP широко используется в качестве протокола приема сообщений от пользователей², т. е., предоставляют пользовательским почтовым агентам (MUA³) возможность отправки новых сообщений в сеть маршрутизации MTA. Процесс, принимающий пользовательские сообщения от MUA, называют агентом подачи сообщений (MSA⁴).

Подаваемые сообщения могут быть в некоторых случаях завершенными (finished или complete), а в других - незавершенными (unfinished или incomplete). Незавершенные сообщения требуется дополнить в соответствии с требованиями [MESSAGE-FORMAT] и более поздних документов. Например, в сообщении может не быть корректного поля 'Date' или домен может не быть указан полным именем. В некоторых случаях агент MUA может оказаться неспособным генерировать завершенные сообщения (например, при отсутствии данных о часовом поясе). Даже в тех случаях, когда подается полное сообщение, локальная политика сайта может требовать проверки или изменения текста сообщения. Такие дополнения и изменения приносят вред, если их производить на “нисходящих” (downstream) MTA - т. е., на MTA после использованного для подачи сообщения агента MTA - и в общем случае выходят за пределы стандартных функций агента MTA.

Разделение подачи и пересылки сообщений упрощает для разработчиков и сетевых администраторов целый ряд операций:

♦ реализация политики безопасности и предотвращение несанкционированной трансляции почты или массовых незапрошенных рассылок;

♦ реализация аутентификации при подаче, включая подачу сообщений имеющими на то полномочия пользователями из других сетей (например, при работе из другого города);

♦ разделение программного кода разных задач, упрощающее код и позволяющее использовать разные программы для трансляции и подачи сообщений;

♦ детектирование конфигурационных проблем в почтовых клиентах;

♦ обеспечение прочной основы для расширения сервиса подачи сообщений в будущем.

В этом документе описан недорогой и детерминированный способ идентификации подачи сообщений и задаются действия, выполняемые сервером подачи (submission server).

Публичные комментарии следует слать по адресу списка рассылки IETF Submit <ietf-submit@imc.org>. Для подписки на рассылку следует отправить сообщение с текстом SUBSCRIBE по адресу <ietf-submit-request@imc.org>. Частные комментарии можно напрямую отправлять автору.

2. Сведения о документе

2.1. Определения используемых терминов

Fully-Qualified - полное имя

Полное доменное имя, которое может быть преобразовано с использованием глобальной системы DNS⁵; полное имя не может быть локальным псевдонимом или частью полного доменного имени.

Message Submission Agent (MSA) - агент подачи сообщений

Процесс, который соответствует данной спецификации, действует как сервер обработки подаваемых сообщений от агентов MUA и доставляет сообщения или действует как клиент SMTP для трансляции сообщений через MTA.

Message Transfer Agent (MTA) - агент пересылки сообщений

Процесс, который соответствует спецификации [SMTP-MTA], действует как сервер SMTP для приема сообщений от MSA или других MTA и доставляет сообщения или выступает в качестве клиента SMTP для трансляции сообщений через другой MTA.

Message User Agent (MUA) - пользовательский почтовый агент

Процесс, который служит (обычно от имени пользователя) для создания и подачи новых сообщений, а также для обработки доставленных сообщений В модели “расщепленного агента⁶” для доступа к доставленной почте используется протокол POP или IMAP.

2.2. Используемые в документе соглашения

В примерах строки "C:" и "S:" показывают строки, передаваемые клиентом и сервером, соответственно. Перевод строки в командах дается лишь для удобства.

В примерах используется домен example.net.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), следует (SHOULD), не следует (SHOULD NOT), возможно (MAY) в данном документе должны интерпретироваться в соответствии с документом "Ключевые слова для обозначения уровня требований в RFC" [KEYWORDS].

3. Подача сообщений

3.1. Идентификация подачи сообщения

Данный документ резервирует порт с номером 587 для подачи сообщений. Сообщения, полученные через этот порт, предназначены для подачи серверу. В качестве протокола используется ESMTP [SMTP-MTA, ESMTP], с описанными здесь расширениями.

²message *submission* protocol

³message user agent

⁴Message Submission Agent

⁵Domain Name Service – служба доменных имен. Прим. перев.

⁶split-MUA model

rfc.com.ru

Перевод RFC 2476

Большинство почтовых клиентов и серверов настраивается на использование порта 587 взамен порта 25, но в отдельных случаях это невозможно или неудобно. Сайт может выбрать использование для подачи сообщений порта 25, обозначив, что одни хосты являются агентами MSA, а другие – агентами MTA.

3.2. Отказ от приема сообщений

Агенты MTA и MSA могут реализовать правила отказа от приема сообщений, которые опираются, в частности на то, что нужно сделать с сообщением – принять его подачу или транслировать.

Например, некоторые сайты могут использовать в своих агентах MTA настройки на отказ от приема любых значений RCPT TO, которым не соответствуют локальные пользователи, а в агентах MSA отвергать подачу всех сообщений, которые не исходят от уполномоченных пользователей (определяются по адресам IP или результатам аутентификации).

Примечание: Лучше отвергнуть сообщение, чем передавать сообщения с риском их повреждения. Это особенно важно для проблем, которые исправляются на уровне MUA (например, некорректное поле 'From').

Если MSA не может определить путь возврата для подающего сообщение пользователя из корректного значения MAIL FROM, корректного адреса IP или по результатам аутентификации, агенту MSA следует незамедлительно отвергнуть сообщение. Сообщение может быть незамедлительно отвергнуто путем возврата кода 550 команде MAIL FROM.

Отметим, что пустой путь возврата (т. е., MAIL FROM:<>) разрешен и должен приниматься (агентам MUA требуется генерация сообщений с пустым путем возврата по целому ряду причин, включая уведомления об уничтожении сообщений).

За исключением тех случаев, когда MSA не может определить корректный путь возврата для подаваемого сообщения, содержащиеся в данном документе, инструкции MSA по возврату код отказа, можно смягчить до восприятия сообщения с последующей генерацией сообщения о невозможности его принять (bounce message). Иными словами, если MSA следует отвергнуть сообщение по любой причине за исключением невозможности определения кода возврата, агент может незамедлительно отвергнуть сообщение или принять его и отправить в ответ сообщение о невозможности принять (bounce).

Примечание: В нормальной ситуации отказ от приема сообщения является предпочтительным вариантом, поскольку обеспечивает незамедлительную обратную связь с пользователем и MUA. Для корректной обработки отложенных сообщений о невозможности восприятия (delayed bounce) клиентский агент MUA должен поддерживать очередь поданных сообщений и сопоставлять полученные отказы с этой очередью.

3.3. Уполномоченная подача сообщений

Множество методов используется для того, чтобы только уполномоченные пользователи могли передавать сообщения по электронной почте. К этим методам относятся аутентификация SMTP, ограничения по адресам IP, secure IP и предварительная POP-аутентификация.

Предлагается использовать расширение Authenticated SMTP [SMTP-AUTH]. Это расширение позволяет агенту MSA проверить полномочия пользователя при подаче сообщений, чего невозможно добиться при использовании других протоколов.

Ограничения по адресам IP очень широко распространены, но недопустимы для мобильных пользователей и, кроме того, уязвимы путем подмены адресов.

Можно также использовать Secure IP [IPSEC] – это решение обеспечивает дополнительную защиту от перехвата и анализа трафика.

Требование предварительной аутентификации POP [POP3] (с того же адреса IP) с некоторым (например, 20 минут) упреждением по отношению к подаче сообщений также может использоваться, но этот метод может вносить некоторые ограничения на использование клиентов и серверов. В частности, клиент должен выполнить процедуры POP-аутентификации до начала сеанса SMTP (подача сообщения), а это обеспечивают не все клиенты. Кроме того требуется координация MSA с POP-сервером, что может оказаться сложной задачей. Существует также интервал времени, в течение которого не имеющий полномочий пользователь может подать свое сообщение, просто опередив уполномоченного пользователя.

3.4. Расширенные коды состояния

В этом документе предлагается несколько дополнительных кодов состояния [SMTP-CODES] для связанных с подачей сообщений отказов. К таким кодам относятся:

5.6.0 Bad content – недопустимое содержимое заголовка или текста сообщения. 5.6.2 Bad domain or address – некорректный или недопустимый домен или адрес в команде MAIL FROM, RCPT TO или DATA.

5.7.1 Not allowed – Указанный в команде MAIL FROM адрес представляется некорректным, не имеет достаточных прав или используемый метод аутентификации не подтвердил полномочий для пользователя с этим адресом; адрес в команде RCPT TO несовместим с предоставленными пользователю полномочиями или данные сообщения отвергнуты с учетом подавшего сообщение пользователя.

5.7.0 Site policy – сообщение представляется противоречащим тем или иным правилам сайта.

4. Обязательные действия

Агент MSA должен выполнять все перечисленные в этой главе операции.

4.1. Код общего назначения для отказа при подаче сообщения

Если явно не указан специальный код, следует использовать код 554 для отказа от выполнения команд MAIL FROM, RCPT TO или DATA, содержащих что-либо некорректное. Если не задано иного, используется расширенный код 5.6.0.

4.2. Все домены должны быть полными (Fully-Qualified)

Агент MSA должен обеспечить полноту указания всех доменов в “конверте” сообщения (envelope).

rfc.com.ru

Перевод RFC 2476

Если MSA проверяет или изменяет текст сообщения, во всех случаях, за исключением добавления трассировочных заголовков [SMTP-MTA], агент должен должен обеспечить полноту указание доменов в адресных полях заголовка.

Код 554 используется для отказа от выполнения команд MAIL FROM, RCPT TO или DATA, содержащих некорректно указанные домены.

Примечание: Зачастую локальные соглашения допускают использование одноуровневых (single-level) доменов (например, 'sales') и тогда адрес расширяется добавлением оставшейся части доменного имени (например, до 'sales.example.net'). Локальным соглашениям, которые допускают одноуровневые домены, следует отвергать, а не дополнять неполные многоуровневые доменные имена, поскольку дополнение таких имен связано с риском ошибки.

5. Рекомендуемые действия

Агенту MSA следует выполнять перечисленные в этой главе операции.

5.1. Обеспечение корректного синтаксиса адресов

Агенту MSA следует отвергать сообщения с некорректным синтаксисом адреса отправителя или получателя в “конверте” сообщения.

Если MSA проверяет или изменяет проверяет или изменяет текст сообщения, во всех случаях, за исключением добавления трассировочных заголовков [SMTP-MTA], агенту следует отвергать сообщения с некорректным синтаксисом адресов в адресных полях заголовка.

Код 501 используется для отказа от выполнения команд MAIL FROM и RCPT TO, содержащих недопустимые адреса.

Когда адреса преобразуются после подачи тела сообщения, используется код 554 с расширенным кодом 5.6.2 после завершения обработки данных, если сообщение содержит некорректные адреса в заголовке.

5.2. Протоколирование ошибок

Агенту MSA следует делать записи в системном журнале (log) при возникновении ошибок, особенно в случаях некорректных настроек клиентских программ.

Примечание: Весьма полезно уведомлять администратора при обнаружении проблем, связанных с локальными почтовыми клиентами. Это дополнительное преимущество разделения систем подачи и трансляции сообщений – системный администратор может быть заинтересован в информации о локальных конфигурационных проблемах, но не клиентских проблемах других сайтов.

6. Дополнительные действия

Агент MSA может выполнять перечисленные в этой главе операции.

6.1. Выполнение правил подачи сообщений

MSA может возвращать код ошибки (error response) в ответ на команду MAIL FROM, если адрес в MAIL FROM не имеет достаточных для подачи сообщения прав или не прошла проверка полномочий с использованием выбранного метода аутентификации (если сессия была аутентифицирована).

Для этих целей используется код 550 с расширенным кодом состояния 5.7.1.

6.2. Требование аутентификации

MSA может возвращать код ошибки в ответ на команду MAIL FROM, если сессия не была аутентифицирована. Механизм аутентификации рассматривается в параграфе 3.3. Для этих целей используется код 530 [SMTP-AUTH].

6.3. Проверка полномочий

MSA может возвращать код ошибки в ответ на команду RCPT TO, если эта команда не соответствует предоставленным пользователю полномочиям (после успешной аутентификации сессии).

Для этих целей используется код 550 с расширенным кодом состояния 5.7.1.

6.4. Проверка данных в сообщении

MSA может возвращать код ошибки в ответ на команду DATA или передавать информацию об отказе после завершения данных, если поданное сообщение синтаксически некорректно, представляется несоответствующим предоставленным пользователю правам или нарушает правила данного сайта.

Код 554 используется при обнаружении синтаксических проблем в данных. Код 501 служит для индикации синтаксической некорректности самой команды. Код 550 с расширенным кодом состояния 5.7.1 используется в случаях отказа для подавшего сообщение пользователя (нет прав). Код 550 с расширенным кодом состояния 5.7.0 указывает на несоответствие политике сайта.

7. Взаимодействие с расширениями SMTP

В приведенной ниже таблице указаны расширения предложенные в качестве стандартов и экспериментальные расширения SMTP. Таблица содержит номера RFC, имена расширений, информацию об использовании расширения на порту submit и ссылку на документ:

rfc.com.ru

Перевод RFC 2476


	*RFC Имя Использование с портом Submission* 2197 Pipelining Нужно	*Ссылка* [PIPELINING]
	2034 Error Codes – коды ошибок Нужно	[CODES-EXTENSION]
	1985 ETRN Недопустимо 1893 Extended Codes – расширенные коды Нужно	[ETRN] [SMTP-CODES]
	1891 DSN Нужно 1870 Size Возможно	[DSN] [SIZE]
	1846 521 Недопустимо 1845 Checkpoint Возможно 1830 Binary Возможно	[521REPLY] [Checkpoint] [CHUNKING]
	1652 8-bit MIME Нужно ---- Authentication - аутентификация ------	[8BITMME]__________ [SMTP-AUTH]

Будущим расширениям SMTP следует явно указывать свою корректность по отношению к порту Submission.

Некоторые расширения SMTP особенно полезны для подачи сообщений:

Расширенные коды состояния⁷ [SMTP-CODES] следует поддерживать и использовать в соответствии с документом [CODES-EXTENSION]. Это позволяет агенту MSA уведомлять клиента о проблемах в его конфигурации или иных проблемах с предоставлением более подробной информации, нежели могут коды откликов, перечисленные в этом документе. Поскольку некоторые отказы могут быть связаны с политикой сайта, следует принять меры по предотвращению раскрытия информации, которое могло бы позволить обход ограничений политики.

[PIPELINING] следует поддерживать в MSA.

[SMTP-AUTH] позволяет MSA проверить полномочия и идентифицировать подавшего сообщение пользователя.

Все упоминания команды DATA в этом документе относятся также и к любым заменам этой команды, таким как команда BDAT, используемая в [CHUNKING].

8. Изменение сообщений

Сайты могут изменять подаваемые сообщения для приведения их в соответствие со стандартами и политикой сайта. В этой главе описан ряд модификаций, которые могут оказаться полезными.

Примечание: В качестве основного руководства для принятия решений о локальном изменении сообщений следует принять правило ограничения таких действий и выполнение лишь тех операций, которые решают конкретные проблемы. Особенно важно это правило для адресных элементов. Например, неразборчивое добавление имени домена к адресам или элементам, в которых не хватает его обычно приводит к появлению некорректных адресов. Для неполных адресов сначала следует проверить корректность локальной части в домене и только после этого можно добавлять имя домена.

8.1. Добавление поля 'Sender'

Агент MSA может добавлять или изменять поле 'Sender', если отправитель известен и не совпадает с указанным в поле 'From'. MSA должен обеспечить корректность почтового адреса, помещаемого в поле 'Sender'.

8.2. Добавление поля 'Date'

Агент MSA может добавлять поле 'Date' к поданному сообщению, если это поле отсутствует, или исправлять значение поля 'Date', если оно не соответствует синтаксису [MESSAGE-FORMAT].

8.3. Добавление поля 'Message-ID'

Агент MSA может добавлять или изменять поле 'Message-ID' при его отсутствии или наличии синтаксических ошибок (см. [MESSAGE-FORMAT]).

8.4. Транспортное кодирование

Агент MSA может применять операции транспортного кодирования (transfer encoding) к сообщению в соответствии с соглашениями MIME при необходимости, если это не представляет опасности для данного типа MIME.

8.5. Включение сигнатуры

Агент MSA может создавать (цифровую) подпись для сообщения или добавлять к нему аутентификационные данные.

8.6. Шифрование сообщений

Агент MSA может шифровать сообщения для передачи в соответствии с политикой организации.

Примечание: При добавлении сигнатуры и/или шифровании сообщений на уровне агента MSA в общем случае предполагается, что для соединения между MUA и MSA тем или иным способом обеспечивается защита (например, использование в защищенной среде, защиты связанных с подачей соединений на транспортном уровне или использование механизма [SMTP-AUTH], обеспечивающего целостность сессий).

⁷Extended Status Code

rfc.com.ru

Перевод RFC 2476

8.7. Преобразование псевдонимов

Агент MSA может преобразовывать псевдонимы (записи CNAME) для доменных имен в конверте и (опционально) в адресных полях заголовка с учетом локальной политики.

Примечание: Безусловное преобразование псевдонимов может представлять опасность. Например, если www.example.net и ftp.example.net являются псевдонимами mail.example.net после преобразования может теряться полезная информация.

8.8. Перезапись заголовков

Агент MSA может переписывать локальную часть адреса и/или доменное имя в конверте и (опционально) в адресных полях заголовка в соответствии с локальной политикой. Например, сайт может заменить 'JRU' на ' J.Random.User' для того, чтобы скрыть регистрационное имя, или заменить 'squeeky.sales.example.net' на 'zyx.example.net' для сокрытия имени машины и упрощения процедур при перемещении пользователей.

Однако изменять следует только локальные части или доменные имена, которые соответствуют локальным конфигурационным параметрам MSA. Очень опасно применять для MSA независимые от данных правила замены (такие, как удаление первого элемента доменного имени). Например, правило, удаляющее первый (слева) элемент доменного имени, если это имя соответствует шаблону '*.foo.example.net', является вполне приемлемым.

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

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

Разделение служб может также быть полезным с точки зрения контроля и предотвращения нежелательной массовой рассылки почты (спам).

Например, сайт может настроить свой агент MSA так, чтобы выполнялась аутентификация до того, как сообщение будет принято, а для MTA задать отказ от приема всех сообщений, где RCPT TO не указывает на локального пользователя. Такое решение может быть важной частью общей политики безопасности электронной почты для сайта.

Если сайт отказывается от использования той или иной формы аутентификации при подаче сообщений (см. параграф 3.3), этот сайт открывает для использования свои ресурсы и имя, что может послужить для массовой рассылки незапрошенной почты.

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

Этот обновленный вариант документа был частично пересмотрен с учетом комментариев и дискуссий в почтовой конференции IETF-Submit. Спасибо всем, кто потратил свое время на просмотр черновых вариантов и предложения, - особенно Dave Crocker, Ned Freed, Keith Moore, John Myers и Chris Newman.

Особой благодарности заслуживает Harald Alvestrand, давший начало этому документу.

11. Литература

[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.

[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.

[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.

[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.

[DSN] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.

[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.

[ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.

[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119⁸, March 1997.

[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982;

Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123⁸, October 1989.

[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.

[POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.

[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.

[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", Work in Progress⁹.

[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.

⁸Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.

⁹Эта работа завершена и опубликована в RFC 2554. Перевод имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 6 rfc.com.ru

Перевод RFC 2476

[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821¹⁰, August 1982.

Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.

Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123⁸, October 1989.

12. Адреса авторов

Randall Gellens

QUALCOMM Incorporated

6455 Lusk Blvd.

San Diego, CA 92121-2779

U.S.A.

Phone: +1 619 651 5115

Fax: +1 619 651 5334

EMail: Randy@Qualcomm.Com

John C. Klensin

MCI Telecommunications

800 Boylston St, 7th floor

Boston, MA 02199

USA

Phone: +1 617 960 1011

EMail: klensin@mci.net

Перевод на русский язык Николай Малых

nmalykh@bilim.com

13. Полное заявление авторских прав

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

¹⁰Этот документ признан устаревшим и заменен RFC 2821. Перевод имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 7 rfc.com.ru


На главную

Network Working Group R. Gellens Request for Comments: 2476 QUALCOMM Category: Standards Track J. Klensin MCI December 1998

Прием сообщений от пользователей Message Submission Статус документа В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений. Авторские права Copyright (C) The Internet Society (1998). All Rights Reserved. Оглавление 1. Тезисы ....................................................................................................................................................................................... .................... 1 2. Сведения о документе ........................................................................................................................................................ ...... ...................... 2 2.1. Определения используемых терминов ................................................................................................................................... ...........2 2.2. Используемые в документе соглашения ........................................................................................................................ .................. 2 3. Подача сообщений ............................................................................................................................................................. ........................... 2 3.1. Идентификация подачи сообщения .................................................................................................................................... .. ............. 2 3.2. Отказ от приема сообщений ..................................................................................................................................................... ........ 3 3.3. Уполномоченная подача сообщений ....................................................................................................................................... ..........3 3.4. Расширенные коды состояния ................................................................................................................................................ .......... 3

4.	Обязательные действия ............................................................................................................................................................................ ..3...

5.	4.1. Код общего назначения для отказа при подаче сообщения .......................................................................................... ................ 3 4.2. Все домены должны быть полными (Fully-Qualified) ................................................................................................................. ...3. . Рекомендуемые действия .............................................................................................................................................................. ............. 4 5.1. Обеспечение корректного синтаксиса адресов .............................................................................................................................. 4... 5.2. Протоколирование ошибок ....................................................................................................................................................... .........4 Дополнительные действия .............................................................................................................................................................. ........... 4 6.1. Выполнение правил подачи сообщений .............................................................................................................................. ....... ....... 4 6.2. Требование аутентификации ..................................................................................................................................................... ....... 4 6.3. Проверка полномочий .................................................................................................................................................. ...... .. ............... 4 6.4. Проверка данных в сообщении ....................................................................................................................................................... .4... Взаимодействие с расширениями SMTP ................................................................................................................................. ...... ............. 4 Изменение сообщений ................................................................................................................................................................. ............... 5 8.1. Добавление поля 'Sender' ..................................................................................................................................................... ...... ......... 5 8.2. Добавление поля 'Date' ................................................................................................................................................. ...................... 5 8.3. Добавление поля 'Message-ID' .................................................................................................................................................... ...... 5 8.4. Транспортное кодирование ........................................................................................................................................... .................... 5 8.5. Включение сигнатуры .................................................................................................................................................... ..... .. .............. 5 8.6. Шифрование сообщений ............................................................................................................................................................. ...........5 8.7. Преобразование псевдонимов ......................................................................................................................................................... .6..
6.

8.8. Перезапись заголовков. 9. Вопросы безопасности ....................... 10. Благодарности .................................. 11. Литература ........................................ 12. Адреса авторов ................................. 13. Полное заявление авторских прав.

*1. Тезисы* SMTP был определен как протокол пересылки (transfer) сообщений, т. е., он способен маршрутизировать (если нужно) и доставлять почтовые сообщения. Не предполагается, что агенты пересылки сообщений (MTA¹) изменяют текст этих сообщений за исключением добавления 'Received', 'Return-Path' и других полей заголовков в соответствии с требованиями [SMTP-MTA].

¹Message Transfer Agent rfc.com.ru		rfc.com.ru



		Перевод RFC 2476
		Перевод RFC 2476
	8.7. Преобразование псевдонимов Агент MSA может преобразовывать псевдонимы (записи CNAME) для доменных имен в конверте и (опционально) в адресных полях заголовка с учетом локальной политики. Примечание: Безусловное преобразование псевдонимов может представлять опасность. Например, если www.example.net и ftp.example.net являются псевдонимами mail.example.net после преобразования может теряться полезная информация. 8.8. Перезапись заголовков Агент MSA может переписывать локальную часть адреса и/или доменное имя в конверте и (опционально) в адресных полях заголовка в соответствии с локальной политикой. Например, сайт может заменить 'JRU' на ' J.Random.User' для того, чтобы скрыть регистрационное имя, или заменить 'squeeky.sales.example.net' на 'zyx.example.net' для сокрытия имени машины и упрощения процедур при перемещении пользователей. Однако изменять следует только локальные части или доменные имена, которые соответствуют локальным конфигурационным параметрам MSA. Очень опасно применять для MSA независимые от данных правила замены (такие, как удаление первого элемента доменного имени). Например, правило, удаляющее первый (слева) элемент доменного имени, если это имя соответствует шаблону '.foo.example.net', является вполне приемлемым. 9. Вопросы безопасности* Разделение функций подачи и трансляции сообщений может позволить сайту реализацию различных наборов правил для этих служб, включая требование использования дополнительных механизмов защиты для одного или обоих типов сервиса. Это повышает вероятность корректной реализации политики. Разделение служб может также быть полезным с точки зрения контроля и предотвращения нежелательной массовой рассылки почты (спам). Например, сайт может настроить свой агент MSA так, чтобы выполнялась аутентификация до того, как сообщение будет принято, а для MTA задать отказ от приема всех сообщений, где RCPT TO не указывает на локального пользователя. Такое решение может быть важной частью общей политики безопасности электронной почты для сайта. Если сайт отказывается от использования той или иной формы аутентификации при подаче сообщений (см. параграф 3.3), этот сайт открывает для использования свои ресурсы и имя, что может послужить для массовой рассылки незапрошенной почты. *10. Благодарности* Этот обновленный вариант документа был частично пересмотрен с учетом комментариев и дискуссий в почтовой конференции IETF-Submit. Спасибо всем, кто потратил свое время на просмотр черновых вариантов и предложения, - особенно Dave Crocker, Ned Freed, Keith Moore, John Myers и Chris Newman. Особой благодарности заслуживает Harald Alvestrand, давший начало этому документу. *11. Литература* [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995. [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995. [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [DSN] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. [ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119⁸, March 1997. [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982; Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123⁸, October 1989. [PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997. [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", Work in Progress⁹. [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.

	⁸Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев. ⁹Эта работа завершена и опубликована в RFC 2554. Перевод имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 6 rfc.com.ru



	Перевод RFC 2476 [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821¹⁰, August 1982. Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986. Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123⁸, October 1989. *12. Адреса авторов* Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A. Phone: +1 619 651 5115 Fax: +1 619 651 5334 EMail: Randy@Qualcomm.Com John C. Klensin MCI Telecommunications 800 Boylston St, 7th floor Boston, MA 02199 USA Phone: +1 617 960 1011 EMail: klensin@mci.net Перевод на русский язык Николай Малых nmalykh@bilim.com *13. Полное заявление авторских прав* Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

	¹⁰Этот документ признан устаревшим и заменен RFC 2821. Перевод имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 7 rfc.com.ru