RFC 2821 | Простой протокол пересылки почты

Аннотация

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

• исходная спецификация SMTP (Simple Mail Transfer Protocol) RFC 821 [30],
• требования к системе доменных имен и последствия для почтового транспорта из RFC 1035 [22] и RFC 974 [27],
• разъяснения и заявления о применимости в RFC 1123 [2],
• материал взят из механизмов расширения SMTP [19].

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

Он устаревает RFC 821, RFC 974 и обновляет RFC 1123 (заменяет почтовые транспортные материалы RFC 1123). Тем не менее, в RFC 821 указаны некоторые функции, которые не использовались в Интернете к середине 1990-х годов и (в приложениях) некоторые дополнительные транспортные модели. Эти разделы здесь опущены в интересах ясности и краткости; читатели, нуждающиеся в них, должны обратиться к RFC 821.

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

Хотя SMTP был разработан как протокол передачи и доставки почты, эта спецификация также содержит информацию, которая важна для его использования в качестве протокола «отправки почты», как рекомендуется для POP [3, 26] и IMAP [6]. Дополнительные вопросы представления обсуждаются в RFC 2476 [15].

Раздел 2.3 содержит определения терминов, характерных для этого документа. За исключением случаев, когда историческая терминология необходима для ясности, этот документ использует текущую терминологию «клиент» и «сервер» для идентификации отправляющего и получающего SMTP-процессов соответственно.

Сопутствующий документ [32] обсуждает заголовки сообщений, тела сообщений и форматы и структуры для них, а также их взаимосвязь.

 

Оглавление

1. Введение
2. Модель SMTP
2.1 Основная структура
2.2 Модель расширения
2.2.1 История вопроса
2.2.2 Определение и регистрация расширений
2.3 Терминология
2.3.1 Почтовые объекты
2.3.2 Отправители и получатели
2.3.3 Почтовые агенты и хранилища сообщений
2.3.4 Хост
2.3.5 Домен
2.3.6 Таблица буфера и состояния
2.3.7 Линии
2.3.8 Системы отправителя, доставки, ретрансляции и шлюза
2.3.9 Содержание сообщения и данные почты
2.3.10 Почтовый ящик и адрес
2.3.11 Ответить
2.4 Общие принципы синтаксиса и модель транзакции
3. Процедуры SMTP: обзор
3.1 Начало сеанса
3.2 Инициирование клиента
3.3 Почтовые транзакции
3.4 Пересылка для исправления или обновления адреса
3.5 Команды для отладки адресов
3.5.1 Обзор
3.5.2 VRFY Нормальный ответ
3.5.3 Значение ответа успеха VRFY или EXPN
3.5.4 Семантика и применение EXPN
3.6 Домены
3.7 Эстафета
3.8 Почтовый шлюз
3.8.1 Поля заголовка в шлюзе
3.8.2. Полученные строки в шлюзе
3.8.3 Адреса в шлюзе
3.8.4 Другие поля заголовка в шлюзе
3.8.5 Конверты в шлюзе
3.9 Завершение сеансов и соединений
3.10 Списки рассылки и псевдонимы
3.10.1 Псевдоним
3.10.2 Список
4. Спецификации SMTP
4.1 SMTP-команды
4.1.1 Семантика и синтаксис команд
4.1.1.1 Расширенный HELLO (EHLO) или HELLO (HELO)
4.1.1.2 ПОЧТА MAIL (MAIL)
4.1.1.3 ПОЛУЧАТЕЛЬ RECIPIENT (RCPT)
4.1.1.4 ДАННЫЕ DATA (DATA)
4.1.1.5 СБРОС RESET (RSET)
4.1.1.6 ПРОВЕРКА VERIFY (VRFY)
4.1.1.7 РАСШИРЕНИЕ EXPAND (EXPN)
4.1.1.8 ПОМОЩЬ HELP (HELP)
4.1.1.9 КНОПКА NOOP (NOOP)
4.1.1.10 ВЫЙТИ QUIT (QUIT)
4.1.2 Синтаксис аргумента команды
4.1.3 Адресные литералы
4.1.4 Порядок команд
4.1.5 Команды частного использования
4.2 Ответы SMTP
4.2.1 Серьезность и теория кода ответа
4.2.2 Коды ответов по группам функций
4.2.3 Коды ответов в числовом порядке
4.2.4 Код ответа 502
4.2.5 Коды ответа после DATA и последующего <CRLF>. <CRLF>
4.3 Последовательность команд и ответов
4.3.1 Обзор последовательности
4.3.2 Последовательности команд-ответов
4.4 Информация о трассировке
4.5 Дополнительные вопросы реализации
4.5.1 Минимальная реализация
4.5.2 Прозрачность
4.5.3 Размеры и время ожидания
4.5.3.1 Размерные ограничения и минимумы
4.5.3.2 Тайм-ауты
4.5.4. Стратегии повтора
4.5.4.1 Стратегия отправки
4.5.4.2. Получение стратегии
4.5.5 Сообщения с нулевым обратным путем
5. Разрешение адресов и обработка почты
6. Обнаружение и устранение проблем
6.1 Надежная доставка и ответы по электронной почте
6.2 Обнаружение петли
6.3 Компенсация за нарушения
7. Вопросы безопасности
7.1 Безопасность почты и спуфинг
7.2 «Слепые» копии
7.3 VRFY, EXPN и безопасность
7.4 Раскрытие информации в объявлениях
7.5 Раскрытие информации в полях трассировки
7.6 Раскрытие информации при пересылке сообщений
7.7 Объем работы SMTP-серверов
8. Соображения IANA
9. Ссылки
10. Адрес редактора
11. Благодарности

Приложения

А. Транспортная служба TCP
B. Генерация SMTP-команд из заголовков RFC 822
C. Исходные маршруты
D. Сценарии
E. Другие проблемы шлюза
F. Устаревшие функции RFC 821
Заявление об авторском праве

 

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

Этот документ определяет протокол отслеживания стандартов Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшению. Пожалуйста, обратитесь к текущей редакции «Официальных стандартов протокола Интернета» (STD 1) для ознакомления с состоянием стандартизации и статусом этого протокола. Распространение этой заметки не ограничено.

 

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

Copyright (C) Интернет-общество (2001). Все права защищены.

 

1. Введение

Целью простого протокола передачи почты (SMTP) является надежная и эффективная передача почты.

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

Важной особенностью SMTP является его способность транспортировать почту через сети, обычно называемую «ретрансляция почты SMTP» (см. Раздел 3.8). Сеть состоит из хостов с взаимной доступностью TCP в общедоступном Интернете, хостов с взаимной доступностью TCP в изолированной брандмауэром интрасети TCP / IP или хостов в какой-либо другой среде LAN или WAN, использующих транспортный уровень не-TCP протокол. Используя SMTP, процесс может передавать почту другому процессу в той же сети или другой сети через процесс ретрансляции или шлюза, доступный для обеих сетей.

Таким образом, почтовое сообщение может проходить через несколько промежуточных узлов ретрансляции или шлюза на своем пути от отправителя к конечному получателю. Механизмы Mail eXchanger системы доменных имен [22, 27] (и раздел 5 этого документа) используются для определения соответствующего пункта назначения следующего перехода для транспортируемого сообщения.

2. Модель SMTP

2.1 Основная структура

Дизайн SMTP может быть изображен как:

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

Средства, с помощью которых почтовое сообщение представляется SMTP-клиенту, и то, как этот клиент определяет доменные имена, на которые должны быть переданы почтовые сообщения, являются локальным вопросом и не рассматриваются в этом документе. В некоторых случаях доменное имя (имена), переданное или определенное SMTP-клиентом, идентифицирует конечный пункт назначения почтового сообщения. В других случаях, общих с SMTP-клиентами, связанными с реализациями протоколов POP [3, 26] или IMAP [6], или когда SMTP-клиент находится в изолированной среде транспортных служб, определенное доменное имя будет идентифицировать промежуточный пункт назначения, через который все почтовые сообщения должны быть переданы. SMTP-клиенты, которые передают весь трафик независимо от имен целевых доменов, связанных с отдельными сообщениями, или не поддерживают очереди для повторных попыток передачи сообщений, которые изначально не могут быть завершены, могут в противном случае соответствовать этой спецификации, но не считаются полностью совместимыми. Ожидается, что реализации SMTP с полной поддержкой, включая ретрансляторы, используемые этими менее способными, и их назначения, будут поддерживать все функции организации очередей, повторных попыток и альтернативных адресов, обсуждаемые в этой спецификации.

Средства, с помощью которых SMTP-клиент, после того как он определил имя целевого домена, определяет идентификатор SMTP-сервера, на который должна быть передана копия сообщения, а затем выполняет эту передачу, охватывается этим документом. Для осуществления передачи почты на SMTP-сервер SMTP-клиент устанавливает двусторонний канал передачи на этот SMTP-сервер. SMTP-клиент определяет адрес соответствующего хоста, на котором запущен SMTP-сервер, путем преобразования целевого доменного имени в промежуточный хост Mail eXchanger или конечный целевой хост.

Сервер SMTP может быть либо конечным пунктом назначения, либо промежуточным «ретранслятором» (то есть он может взять на себя роль клиента SMTP после получения сообщения) или «шлюзом» (то есть он может дополнительно транспортировать сообщение с использованием некоторого протокола кроме SMTP). Команды SMTP генерируются клиентом SMTP и отправляются на сервер SMTP. SMTP-ответы отправляются с SMTP-сервера SMTP-клиенту в ответ на команды.

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

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

Сервер отвечает на каждую команду ответом; ответы могут указывать, что команда была принята, что ожидаются дополнительные команды или что существует временная или постоянная ошибка. Команды, указывающие отправителя или получателей, могут включать в себя запросы расширения SMTP-службы, разрешенные сервером, как описано в разделе 2.2. Диалог преднамеренно блокируется, по одному, хотя его можно изменить взаимно согласованными запросами на расширение, такими как конвейерная обработка команд [13].

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

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

Обычно промежуточные хосты определяются с помощью записи MX DNS, а не с помощью явной маршрутизации «источника» (см. Раздел 5 и приложения C и F.2).

2.2 Модель расширения

2.2.1 История вопроса

В 1990 году, примерно через десять лет после завершения RFC 821, протокол был изменен с помощью модели «расширений услуг», которая позволяет клиенту и серверу соглашаться использовать общие функциональные возможности сверх первоначальных требований SMTP. Механизм расширения SMTP определяет средство, с помощью которого расширенный SMTP-клиент и сервер могут распознавать друг друга, и сервер может информировать клиента о поддерживаемых им расширениях службы.

Современные реализации SMTP ДОЛЖНЫ поддерживать базовые механизмы расширения. Например, серверы ДОЛЖНЫ поддерживать команду EHLO, даже если они не реализуют никаких конкретных расширений, а клиенты ДОЛЖНЫ преимущественно использовать EHLO, а не HELO. (Однако для совместимости со старыми соответствующими реализациями клиенты и серверы SMTP ДОЛЖНЫ поддерживать исходные механизмы HELO в качестве запасного варианта.) Если для целей взаимодействия не должны быть идентифицированы различные характеристики HELO, в этом документе рассматривается только EHLO.

SMTP широко распространен, и высококачественные реализации оказались очень надежными. Однако в настоящее время интернет-сообщество считает важными некоторые службы, которые не были ожидаемы при разработке протокола. Если необходимо добавить поддержку этих сервисов, это должно быть сделано таким образом, чтобы старые реализации продолжали работать приемлемо. Структура расширения состоит из:

• команда SMTP EHLO, заменяющая более раннюю HELO,
• реестр расширений службы SMTP,
• дополнительные параметры к командам SMTP MAIL и RCPT, и
• необязательные замены для команд, определенных в этом протоколе, например, для DATA в передачах не-ASCII [33].

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

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

2.2.2 Определение и регистрация расширений

IANA поддерживает реестр расширений службы SMTP. Соответствующее значение ключевого слова EHLO связано с каждым расширением. Каждое расширение службы, зарегистрированное в IANA, должно быть определено в официальном документе, соответствующем стандартам или утвержденному IESG документу об экспериментальном протоколе. Определение должно включать:

• текстовое имя расширения службы SMTP;
• значение ключевого слова EHLO, связанное с расширением;
• синтаксис и возможные значения параметров, связанных со значением ключевого слова EHLO;
• любые дополнительные глаголы SMTP, связанные с расширением (дополнительные глаголы, как правило, будут, но не обязательно, совпадают со значением ключевого слова EHLO);
• любые новые параметры, которые расширение связывает с глаголами MAIL или RCPT;
• описание того, как поддержка расширения влияет на поведение SMTP-сервера и клиента;
• приращение, на которое расширение увеличивает максимальную длину команд MAIL и / или RCPT по сравнению с указанной в этом стандарте.

Кроме того, любое значение ключевого слова EHLO, начинающееся с верхнего или нижнего регистра «X», относится к локальному расширению службы SMTP, используемому исключительно в рамках двустороннего соглашения. Ключевые слова, начинающиеся с «X», НЕ ДОЛЖНЫ использоваться в зарегистрированном расширении службы. И наоборот, значения ключевых слов, представленные в ответе EHLO, которые не начинаются с «X», ДОЛЖНЫ соответствовать стандартному стандартному или одобренному IESG экспериментальному расширению службы SMTP, зарегистрированному в IANA. Соответствующий сервер НЕ ДОЛЖЕН предлагать значения ключевых слов без префикса «X», которые не описаны в зарегистрированном расширении.

Дополнительные глаголы и имена параметров связаны теми же правилами, что и ключевые слова EHLO; в частности, глаголы, начинающиеся с «X», являются локальными расширениями, которые не могут быть зарегистрированы или стандартизированы. И наоборот, глаголы, не начинающиеся с «X», всегда должны быть зарегистрированы.

2.3 Терминология

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

1. ОБЯЗАН — MUST. Это слово или термины «ТРЕБУЕТСЯ — REQUIRED» или «ДОЛЖЕН — SHALL» означают, что определение является абсолютным требованием спецификации.

2. НЕ ОБЯЗАН — MUST NOT. Эта фраза или фраза «НЕ ДОЛЖЕН — SHALL NOT» означают, что определение является абсолютным запретом спецификации.

3. СЛЕДУЕТ — SHOULD. Это слово или прилагательное «РЕКОМЕНДУЕТСЯ — RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах игнорировать конкретный элемент, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбрать другой курс.

4. НЕ СЛЕДУЕТ — SHOULD NOT. Эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах, когда конкретное поведение является приемлемым или даже полезным, но все последствия должны быть поняты, а случай тщательно взвешен, прежде чем реализовывать какое-либо поведение. описано с этим ярлыком.

5. ВОЗМОЖЕН — MAY. Это слово, или прилагательное «ДОПОЛНИТЕЛЬНО — OPTIONAL», означает, что предмет действительно необязателен. Один продавец может включить товар, потому что этого требует конкретный рынок, или потому что продавец чувствует, что он улучшает продукт, в то время как другой продавец может опустить тот же товар. Реализация, которая не включает в себя конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена ​​к взаимодействию с другой реализацией, которая включает опцию, хотя, возможно, с уменьшенной функциональностью. В том же духе реализация, которая включает конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена ​​к взаимодействию с другой реализацией, которая не включает эту опцию (за исключением, конечно, функции, предоставляемой опцией).

2.3.1 Почтовые объекты (Mail Objects)

SMTP транспортирует почтовый объект. Почтовый объект содержит конверт и контент.

Конверт SMTP отправляется в виде последовательности блоков протокола SMTP (описано в разделе 3). Он состоит из адреса отправителя (на который следует направлять отчеты об ошибках); один или несколько адресов получателей; и дополнительный протокол расширения материала. Исторически, вариации команды указания адреса получателя (RCPT TO) могли использоваться для указания альтернативных режимов доставки, таких как немедленное отображение; эти изменения были объявлены устаревшими (см. приложение F, раздел F.6).

Содержимое SMTP отправляется в модуле протокола SMTP DATA и состоит из двух частей: заголовков и тела. Если содержимое соответствует другим современным стандартам, заголовки формируют набор пар поле / значение, структурированных как в спецификации формата сообщения [32]; тело, если оно структурировано, определяется в соответствии с MIME [12]. Содержание носит текстовый характер, выражено с использованием репертуара US-ASCII [1]. Хотя расширения SMTP (такие как «8BITMIME» [20]) могут ослабить это ограничение для тела контента, заголовки контента всегда кодируются с использованием репертуара US-ASCII. Расширение MIME [23] определяет алгоритм для представления значений заголовков за пределами репертуара US-ASCII, в то же время кодируя их с использованием репертуара US-ASCII.

2.3.2 Отправители (Senders) и получатели (Receivers)

В RFC 821 два хоста, участвующие в SMTP-транзакции, были описаны как «SMTP-отправитель» и «SMTP-получатель». Этот документ был изменен, чтобы отразить текущую отраслевую терминологию и, следовательно, называет их «SMTP-клиент» (или иногда просто «клиент») и «SMTP-сервер» (или просто «сервер»), соответственно. Поскольку данный хост может выступать как сервер и клиент в ситуации ретрансляции, терминология «получатель» и «отправитель» все еще используется там, где это необходимо для ясности.

2.3.3 Почтовые агенты (Mail Agents) и хранилища сообщений (Message Stores)

Дополнительная терминология почтовой системы стала общепринятой после публикации RFC 821 и, где это удобно, используется в данной спецификации. В частности, SMTP-серверы и клиенты предоставляют почтовый транспорт и, следовательно, действуют как «Агенты пересылки почты» (MTA). «Агенты пользователя почты» (MUA или UA) обычно рассматриваются как источники и цели почты. В источнике MUA может собирать почту для передачи от пользователя и передавать ее MTA; последний («доставляющий») MTA будет считаться передачей почты MUA (или, по крайней мере, передачей ему ответственности, например, путем помещения сообщения в «хранилище сообщений»). Однако, хотя эти термины используются, по крайней мере, с высокой точностью в других средах, подразумеваемые границы между MUA и MTA часто не точно соответствуют обычной и соответствующей практике работы с почтой Интернета. Следовательно, читатель должен быть осторожен в определении сильных взаимоотношений и обязанностей, которые могут подразумеваться, если эти термины используются в другом месте.

2.3.4 Хост (Host)

Для целей данной спецификации хост — это компьютерная система, подключенная к Интернету (или, в некоторых случаях, к частной сети TCP / IP) и поддерживающая протокол SMTP. Хосты известны по именам (см. «Домен»); идентифицировать их по числовому адресу не рекомендуется.

2.3.5 Домен (Domain)

Домен (или доменное имя) состоит из одного или нескольких компонентов, разделенных точками. Эти компоненты («метки» в терминологии DNS [22]) ограничены для целей SMTP и состоят из последовательности букв, цифр и дефисов, взятых из набора символов ASCII [1]. Доменные имена используются как имена хостов и других объектов в иерархии доменных имен. Например, домен может ссылаться на псевдоним (метка записи CNAME RR) или метку записей Mail eXchanger, которые будут использоваться для доставки почты вместо представления имени хоста. См. [22] и раздел 5 этой спецификации.

Доменное имя, как описано в этом документе и в [22], является полным полностью определенным именем (часто называемым «полным доменным именем»). Доменное имя, которое находится не в форме FQDN, не более, чем локальный псевдоним. Локальные псевдонимы НЕ ДОЛЖНЫ появляться в любой транзакции SMTP.

2.3.6 Таблица буфера (Buffer Table) и состояния (State Table)

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

2.3.7 Линии (Lines)

Команды SMTP и, если не изменено расширением службы, данные сообщения передаются «линиями». Строки состоят из нуля или более символов данных, оканчивающихся символом ASCII последовательности «CR» (шестнадцатеричное значение 0D), за которым сразу следует символ ASCII «LF» (шестнадцатеричное значение 0A). Эта последовательность завершения обозначена как <CRLF> в этом документе. Соответствующие реализации НЕ ДОЛЖНЫ распознавать или генерировать любые другие символы или символьную последовательность в качестве ограничителя строки. Пределы МОГУТ быть наложены на длины линий серверами (см. Раздел 4.5.3).

Кроме того, появление в тексте «голых» символов «CR» или «LF» (т. Е. Либо без других) имеет долгую историю возникновения проблем в реализациях почты и приложениях, которые используют почтовую систему в качестве инструмента. Реализации SMTP-клиента НЕ ДОЛЖНЫ передавать эти символы, кроме случаев, когда они предназначены в качестве ограничителей строки, а затем ДОЛЖНЫ, как указано выше, передавать их только как последовательность <CRLF>.

2.3.8 Системы отправителя (Originator), доставки (Delivery), ретрансляции (Relay) и шлюза (Gateway)

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

SMTP-система «шлюз» (обычно называемая просто «шлюзом») получает почту от клиентской системы в одной транспортной среде и передает ее серверной системе в другой транспортной среде. Различия в протоколах или семантике сообщений между транспортными средами по обе стороны шлюза могут потребовать, чтобы система шлюза выполняла преобразования в сообщения, которые не разрешены для систем ретрансляции SMTP. Для целей данной спецификации межсетевые экраны, которые перезаписывают адреса, должны рассматриваться как шлюзы, даже если SMTP используется по обе стороны от них (см. [11]).

2.3.9 Содержание сообщения (Message Content) и данные почты (Mail Data)

Термины «содержание сообщения» и «почтовые данные» используются в этом документе взаимозаменяемо для описания материала, переданного после того, как команда DATA принята и до того, как будет передано указание конца данных. Содержимое сообщения включает заголовки сообщения и возможно структурированное тело сообщения. Спецификация MIME [12] предоставляет стандартные механизмы для структурированных тел сообщений.

2.3.10 Почтовый ящик (Mailbox) и адрес (Address)

Как используется в данной спецификации, «адрес» — это символьная строка, которая идентифицирует пользователя, которому отправляется почта, или местоположение, в которое будет отправляться почта. Термин «почтовый ящик» относится к этому хранилищу. Эти два термина обычно используются взаимозаменяемо, если различие между местоположением, в котором находится почта (почтовый ящик), и ссылкой на него (адрес) не является важным. Адрес обычно состоит из спецификаций пользователя и домена. Стандартное соглашение об именах почтовых ящиков определено как «localpart @ domain»: современное использование допускает гораздо более широкий набор приложений, чем простые «имена пользователей». Следовательно, и из-за долгой истории проблем, когда промежуточные хосты пытались оптимизировать транспорт, изменяя их, локальная часть ДОЛЖНА интерпретироваться и назначаться семантикой только хостом, указанным в доменной части адреса.

2.3.11 Ответ (Reply)

SMTP-ответ — это подтверждение (положительное или отрицательное), отправленное от получателя отправителю по каналу передачи в ответ на команду. Общая форма ответа — это цифровой код завершения (указывающий на неудачу или успех), обычно сопровождаемый текстовой строкой. Коды предназначены для использования программами, а текст обычно предназначен для пользователей. В недавней работе [34] было определено дальнейшее структурирование строк ответа, включая использование дополнительных и более конкретных кодов завершения.

2.4 Общие принципы синтаксиса и модель транзакции

Команды и ответы SMTP имеют жесткий синтаксис. Все команды начинаются с командного глагола. Все ответы начинаются с трехзначного цифрового кода. В некоторых командах и ответах аргументы ДОЛЖНЫ следовать за глаголом или кодом ответа. Некоторые команды не принимают аргументы (после глагола), а некоторые коды ответов сопровождаются, иногда необязательно, текстом произвольной формы. В обоих случаях, где появляется текст, он отделяется от глагола или кода ответа пробелом. Полные определения команд и ответов приведены в разделе 4.

Глаголы и значения аргументов (например, «TO:» или «to:» в ключевых словах имени команды и расширения RCPT) не чувствительны к регистру, за единственным исключением в этой спецификации локальной части почтового ящика (расширения SMTP могут явно указывать регистр -чувствительные элементы). Таким образом, командный глагол, значение аргумента, отличное от локальной части почтового ящика, и текст произвольной формы МОГУТ быть закодированы в верхнем регистре, нижнем регистре или любой комбинации верхнего и нижнего регистра без влияния на его значение. Это НЕ верно для локальной части почтового ящика. Локальная часть почтового ящика ДОЛЖНА БЫТЬ обрабатываться с учетом регистра. Поэтому реализации SMTP ДОЛЖНЫ позаботиться о том, чтобы сохранить случай локальных частей почтового ящика. Домены почтовых ящиков не чувствительны к регистру. В частности, для некоторых хостов пользователь «Смит» отличается от пользователя «Смит». Однако использование чувствительности к регистру локальных частей почтового ящика затрудняет взаимодействие и не поощряется.

Несколько SMTP-серверов, в нарушение этой спецификации (и RFC 821) требуют, чтобы глаголы команд кодировались клиентами в верхнем регистре. Реализации МОГУТ использовать эту кодировку для размещения этих серверов.

Поле аргумента состоит из символьной строки переменной длины, заканчивающейся концом строки, то есть последовательностью символов <CRLF>. Получатель не будет предпринимать никаких действий, пока эта последовательность не будет получена.

Синтаксис каждой команды показан вместе с обсуждением этой команды. Общие элементы и параметры приведены в разделе 4.1.2.

Команды и ответы состоят из символов из набора символов ASCII [1]. Когда транспортная служба предоставляет 8-битный байтовый (октетный) канал передачи, каждый 7-битный символ передается с прямым выравниванием в октете с битом старшего разряда, очищенным до нуля. Точнее говоря, нерасширенная служба SMTP обеспечивает только семибитную передачу. Исходящий SMTP-клиент, который не успешно согласовал соответствующее расширение с конкретным сервером, НЕ ДОЛЖЕН передавать сообщения с информацией в старшем разряде октетов. Если такие сообщения передаются с нарушением этого правила, принимающие SMTP-серверы МОГУТ сбрасывать старший бит или отклонять сообщение как недействительное. Как правило, SMTP-ретранслятор ДОЛЖЕН предполагать, что полученный контент сообщения является действительным, и, предполагая, что конверт позволяет это сделать, ретранслировать его без проверки этого содержимого. Конечно, если содержимое имеет неправильную маркировку и путь данных не может принять фактическое содержимое, это может привести к окончательной доставке сообщения с серьезным искажением получателю. Системы доставки SMTP МОГУТ отклонять («отказов») такие сообщения, а не доставлять их. Запрещается отправка SMTP-системы для отправки команд конверта в любом наборе символов, кроме US-ASCII; принимающим системам СЛЕДУЕТ отклонять такие команды, обычно используя ответы «500 синтаксическая ошибка — недопустимый символ».

Восьмибитная передача содержимого сообщения МОЖЕТ быть запрошена сервером клиентом, использующим расширенные средства SMTP, в частности, расширение «8BITMIME» [20]. 8BITMIME ДОЛЖНЫ поддерживаться SMTP-серверами. Однако это НЕ ДОЛЖНО быть истолковано как разрешение на передачу неограниченного восьмибитного материала. 8BITMIME НЕ ДОЛЖЕН запрашиваться отправителями для материала с старшим битом, который не находится в формате MIME с соответствующей кодировкой передачи контента; серверы МОГУТ отклонять такие сообщения.

Металингвистическая нотация, используемая в этом документе, соответствует «Расширенному БНФ», используемому в других документах почтовой системы Интернета. Читатель, который не знаком с этим синтаксисом, должен обратиться к спецификации ABNF [8]. Термины метаязыка, используемые в бегущем тексте, для ясности заключены в острые скобки (например, <CRLF>).

3. Процедуры SMTP: обзор

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

3.1 Начало сеанса

Сеанс SMTP инициируется, когда клиент открывает соединение с сервером, и сервер отвечает открывающим сообщением.

Реализации SMTP-сервера МОГУТ включать идентификацию своего программного обеспечения и информации о версии в ответ на приветствие соединения после кода 220, что позволяет более эффективно изолировать и устранить любые проблемы. Реализации МОГУТ предусмотреть для SMTP-серверов отключение объявления о программном обеспечении и версии, если это вызывает проблемы безопасности. Хотя некоторые системы также идентифицируют свою контактную точку для проблем с почтой, это не является заменой для поддержания требуемого адреса «postmaster» (см. Раздел 4.5.1).

Протокол SMTP позволяет серверу формально отклонить транзакцию, в то же время разрешая начальное соединение следующим образом: в начальном сообщении об открытии соединения МОЖЕТ быть дан ответ 554 вместо 220. Сервер, использующий такой подход, ДОЛЖЕН все еще ждать, пока клиент отправит ВЫЙТИ (см. раздел 4.1.1.10) перед закрытием соединения и СЛЕДУЕТ отвечать на любые промежуточные команды «503 неверной последовательностью команд». Поскольку попытка установить SMTP-соединение с такой системой, вероятно, является ошибкой, сервер, возвращающий ответ 554 при открытии соединения, ДОЛЖЕН предоставить достаточно информации в тексте ответа, чтобы облегчить отладку отправляющей системы.

3.2 Инициирование клиента

Как только сервер отправил приветственное сообщение и клиент получил его, клиент обычно отправляет команду EHLO на сервер, указывая личность клиента. В дополнение к открытию сеанса использование EHLO указывает, что клиент может обрабатывать расширения службы и запрашивает у сервера список поддерживаемых расширений. Старые SMTP-системы, которые не могут поддерживать расширения служб и современные клиенты, которым не требуются расширения служб в инициируемом почтовом сеансе, МОГУТ использовать HELO вместо EHLO. Серверы НЕ ДОЛЖНЫ возвращать расширенный ответ в стиле EHLO на команду HELO. Для конкретной попытки подключения, если сервер возвращает ответ «команда не распознана» на EHLO, клиент ДОЛЖЕН иметь возможность выполнить откат и отправить HELO.

В команде EHLO хост, отправляющий команду, идентифицирует себя; команда может быть интерпретирована как «Здравствуйте, я <домен>» (и, в случае EHLO, «и я поддерживаю запросы на расширение службы»).

3.3 Почтовые транзакции

Есть три шага для SMTP почтовых транзакций. Транзакция начинается с команды MAIL, которая дает идентификацию отправителя. (Как правило, команда MAIL может быть отправлена только в том случае, если не выполняется ни одна почтовая транзакция; см. Раздел 4.1.4.) Далее следует серия из одной или нескольких команд RCPT, предоставляющая информацию о получателе. Затем команда DATA инициирует передачу почтовых данных и завершается индикатором данных «конец почты», который также подтверждает транзакцию.

Первым шагом в процедуре является команда MAIL.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

Эта команда сообщает SMTP-получателю о начале новой почтовой транзакции и обнулении всех ее таблиц состояний и буферов, включая любых получателей или почтовые данные. Часть <reverse-path> первого или единственного аргумента содержит исходный почтовый ящик (в скобках «<» и «>»), который можно использовать для сообщения об ошибках (см. Раздел 4.2 для обсуждения сообщений об ошибках). Если он принят, SMTP-сервер возвращает ответ 250 OK. Если спецификация почтового ящика по какой-то причине неприемлема, сервер ДОЛЖЕН возвратить ответ, указывающий, является ли сбой постоянным (то есть будет ли он повторяться, если клиент попытается снова отправить тот же адрес), или временным (то есть адрес может быть принят если клиент попытается снова позже). Несмотря на очевидную область применения этого требования, существуют обстоятельства, при которых приемлемость обратного пути не может быть определена до тех пор, пока не будет исследован один или несколько прямых путей (в командах RCPT). В этих случаях сервер МОЖЕТ разумно принять обратный путь (с ответом 250) и затем сообщить о проблемах после получения и проверки прямых путей. Обычно ошибки дают 550 или 553 ответа.

Исторически сложилось так, что <reverse-path> может содержать больше, чем просто почтовый ящик, однако современные системы НЕ ДОЛЖНЫ использовать маршрутизацию от источника (см. Приложение C).

Необязательные <mail-параметры> связаны с согласованными расширениями службы SMTP (см. Раздел 2.2).

Вторым этапом процедуры является команда RCPT.

RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

Первый или единственный аргумент этой команды включает прямой путь (обычно почтовый ящик и домен, всегда заключенный в скобки «<» и «>»), идентифицирующий одного получателя. Если он принят, SMTP-сервер возвращает ответ 250 OK и сохраняет прямой путь. Если известно, что получатель не является доставляемым адресом, SMTP-сервер возвращает ответ 550, обычно со строкой, такой как «нет такого пользователя -» и именем почтового ящика (возможны другие обстоятельства и коды ответов). Этот шаг процедуры может повторяться любое количество раз.

<Forward-path> может содержать больше, чем просто почтовый ящик. Исторически, <forward-path> может быть исходным списком маршрутизации узлов и почтовым ящиком назначения, однако современные SMTP-клиенты НЕ ДОЛЖНЫ использовать исходные маршруты (см. Приложение C). Серверы ДОЛЖНЫ быть готовы встретить список исходных маршрутов в прямом пути, но ДОЛЖНЫ игнорировать маршруты или МОГУТ отказаться от поддержки предполагаемой им ретрансляции. Аналогично, серверы МОГУТ отказаться принимать почту, предназначенную для других хостов или систем. Эти ограничения делают сервер бесполезным в качестве ретранслятора для клиентов, которые не поддерживают полную функциональность SMTP. Следовательно, клиенты с ограниченными возможностями НЕ ДОЛЖНЫ предполагать, что любой SMTP-сервер в Интернете может использоваться в качестве их сайта обработки (ретрансляции) почты. Если команда RCPT появляется без предыдущей команды MAIL, сервер ДОЛЖЕН вернуть ответ 503 «Плохая последовательность команд». Необязательные <rcpt-параметры> связаны с согласованными расширениями службы SMTP (см. Раздел 2.2).

Третий шаг в процедуре — команда DATA (или некоторая альтернатива, указанная в расширении службы).

DATA <CRLF>

В случае принятия SMTP-сервер возвращает промежуточный ответ 354 и считает все последующие строки вплоть до, но не включая индикатор конца почтового сообщения, текстом сообщения. Когда конец текста успешно получен и сохранен, SMTP-получатель отправляет ответ 250 OK.

Поскольку почтовые данные отправляются по каналу передачи, необходимо указать данные конца почты, чтобы можно было возобновить диалог команды и ответа. SMTP указывает конец почтовых данных, отправляя строку, содержащую только «.» (точка или полная остановка). Процедура прозрачности используется для предотвращения вмешательства в текст пользователя (см. Раздел 4.5.2).

Индикатор конца почтовых данных также подтверждает почтовую транзакцию и сообщает SMTP-серверу теперь обрабатывать сохраненные получатели и почтовые данные. Если он принят, SMTP-сервер возвращает ответ 250 OK. Команда DATA может дать сбой только в двух точках обмена протоколами:

• Если не было MAIL или RCPT, команда или все такие команды были отклонены, сервер МОЖЕТ вернуть ответ «команда из последовательности» (503) или «нет действительных получателей» (554) в ответ на команду DATA. , Если один из этих ответов (или любой другой ответ 5yz) получен, клиент НЕ ДОЛЖЕН отправлять данные сообщения; в более общем случае данные сообщения НЕ ДОЛЖНЫ отправляться, пока не получен ответ 354.
• Если глагол был первоначально принят и ответ 354 выдан, команда DATA должна завершиться неудачей только в том случае, если почтовая транзакция была неполной (например, нет получателей), или если ресурсы были недоступны (в том числе, конечно, сервер неожиданно стал недоступным) или если сервер определяет, что сообщение должно быть отклонено по политическим или другим причинам.

Однако на практике некоторые серверы не выполняют проверку получателей до тех пор, пока не получен текст сообщения. Эти серверы ДОЛЖНЫ обрабатывать сбой одного или нескольких получателей как «последующий сбой» и возвращать почтовое сообщение, как описано в разделе 6. Использование кода ответа «550 почтовый ящик не найден» (или эквивалентного) после того, как данные приняты, усложняет задачу. или невозможно для клиента определить, какие получатели потерпели неудачу.

Когда используется формат RFC 822 [7, 32], данные почты включают в себя такие элементы заголовка заметки, как Дата, Тема, Кому, Копия, От. Серверным SMTP-системам НЕ СЛЕДУЕТ отклонять сообщения на основании обнаруженных дефектов в заголовке сообщения RFC 822 или MIME [12] или теле сообщения. В частности, они НЕ ДОЛЖНЫ отклонять сообщения, в которых номера полей Resent не совпадают или Resent-to появляется без Resent-from и / или Resentdate.

Команды почтовой транзакции ДОЛЖНЫ использоваться в порядке, рассмотренном выше.

3.4 Пересылка для исправления или обновления адреса

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

Как в случае предприятия, так и в случае с «новым адресом» соображения сокрытия информации (а иногда и безопасности) приводят к тому, что «конечный» адрес через протокол SMTP является побочным эффектом пересылки. Это может быть особенно важно, когда отправитель может даже не получить окончательный адрес. Следовательно, механизмы «пересылки», описанные в разделе 3.2 RFC 821, и особенно коды ответа 251 (исправленное место назначения) и 551 от RCPT, должны тщательно оцениваться исполнителями и, когда они доступны, теми, кто настраивает системы.

Особенно:

• Серверы МОГУТ (MAY) пересылать сообщения, когда им известно об изменении адреса. Когда они это сделают, они МОГУТ (MAY) либо предоставить информацию для обновления адреса с кодом 251, либо могут переслать «молча» и вернуть код 250. Но, если используется код 251, они НЕ ДОЛЖНЫ (MUST NOT) предполагать, что клиент фактически обновит адресную информацию или даже вернет эту информацию пользователю.

С другой стороны

• Серверы МОГУТ отклонять или отклонять сообщения, когда они не доставляются при обращении. Когда они делают это, они МОГУТ либо предоставить информацию об обновлении адреса с кодом 551, либо могут отклонить сообщение как недоставленное с кодом 550 и без информации, специфичной для адреса. Но, если используется код 551, они НЕ ДОЛЖНЫ предполагать, что клиент фактически обновит адресную информацию или даже вернет эту информацию пользователю.

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

3.5 Команды для отладки адресов

3.5.1 Обзор

SMTP предоставляет команды для проверки имени пользователя или получения содержимого списка рассылки. Это делается с помощью команд VRFY и EXPN, которые имеют строковые аргументы. Реализации ДОЛЖНЫ поддерживать VRFY и EXPN (однако, см. Раздел 3.5.2 и 7.3).

Для команды VRFY строка представляет собой имя пользователя или имя пользователя и домен (см. Ниже). Если возвращается нормальный (то есть 250) ответ, ответ МОЖЕТ включать полное имя пользователя и ДОЛЖЕН включать почтовый ящик пользователя. Он ДОЛЖЕН быть в любой из следующих форм:

User Name <local-part@domain>
local-part@domain

Когда имя, являющееся аргументом для VRFY, может идентифицировать более одного почтового ящика, сервер МОЖЕТ либо заметить неоднозначность, либо определить альтернативы. Другими словами, любое из следующего является законным ответом на VRFY:

553 User ambiguous

или

553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>

или

553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>

При нормальных обстоятельствах клиент, получивший ответ 553, должен был бы представить результат пользователю. Использование именно указанных форм и ключевых слов «неоднозначный» или «неоднозначный» для пользователя, возможно, дополненных расширенными кодами ответов, такими как описанные в [34], будут способствовать автоматическому переводу на другие языки по мере необходимости. Конечно, клиент, который был в высокой степени автоматизирован или работал на другом языке, отличном от английского, мог бы попытаться перевести ответ, вернуть пользователю какое-либо другое указание, отличное от буквального текста ответа, или предпринять какое-либо автоматическое действие. например, проконсультироваться со службой каталогов для получения дополнительной информации, прежде чем сообщать пользователю.

Для команды EXPN строка идентифицирует список рассылки, и успешный (т.е. 250) многострочный ответ МОЖЕТ включать полное имя пользователя и ДОЛЖЕН предоставлять почтовые ящики в списке рассылки.

На некоторых хостах различие между списком рассылки и псевдонимом для одного почтового ящика немного размыто, так как общая структура данных может содержать записи обоих типов, и возможно иметь списки рассылки, содержащие только один почтовый ящик. Если сделан запрос на применение VRFY к списку рассылки, МОЖЕТ быть дан положительный ответ, если сообщение с таким адресом будет доставлено всем в списке, в противном случае СЛЕДУЕТ сообщать об ошибке (например, «550 Это список рассылки, не пользователь «или» 252 Невозможно проверить участников списка рассылки «). Если сделан запрос на расширение имени пользователя, сервер МОЖЕТ вернуть положительный ответ, состоящий из списка, содержащего одно имя, или МОЖЕТ быть сообщено об ошибке (например, «550 Это имя пользователя, а не список рассылки»).

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

«Имя пользователя — User name» — это нечеткий термин, который используется намеренно. Реализация команд VRFY или EXPN ДОЛЖНА включать, по крайней мере, распознавание локальных почтовых ящиков как «имен пользователей». Тем не менее, поскольку современная практика Интернета часто приводит к тому, что один хост обрабатывает почту для нескольких доменов, хосты, особенно хосты, которые предоставляют эту функциональность, ДОЛЖНЫ принять форму «local-part @ domain» как «имя пользователя»; хосты МОГУТ также выбрать распознавание других строк как «имен пользователей».

В случае расширения списка почтовых ящиков требуется многострочный ответ, например:

C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>

или

C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.

Аргументы символьных строк команд VRFY и EXPN не могут быть дополнительно ограничены из-за разнообразных реализаций концепций имени пользователя и списка почтовых ящиков. В некоторых системах может оказаться целесообразным, чтобы аргумент команды EXPN представлял собой имя файла для файла, содержащего список рассылки, но, опять же, в Интернете существует множество соглашений об именах файлов. Точно так же исторические различия в том, что возвращают эти команды, таковы, что ответ ДОЛЖЕН интерпретироваться очень осторожно, если вообще вообще, и ДОЛЖЕН, как правило, использоваться только для диагностических целей.

3.5.2 VRFY Нормальный ответ

Когда нормальные (2yz или 551) ответы возвращаются из запроса VRFY или EXPN, ответ обычно включает имя почтового ящика, то есть «<local-part @ domain>», где «domain» — это полное доменное имя, ДОЛЖНО появиться в синтаксисе. В обстоятельствах, достаточно исключительных, чтобы оправдать нарушение намерений этой спецификации, текст в произвольной форме МОЖЕТ быть возвращен. Чтобы облегчить синтаксический анализ как компьютерами, так и людьми, адреса ДОЛЖНЫ быть указаны в квадратных скобках. Когда возвращаются адреса, а не отладочная информация в свободной форме, EXPN и VRFY ДОЛЖНЫ возвращать только действительные доменные адреса, которые можно использовать в командах SMTP RCPT. Следовательно, если адрес подразумевает доставку в программу или другую систему, ДОЛЖНО быть указано имя почтового ящика, используемого для достижения этой цели. Пути (явные исходные маршруты) НЕ ДОЛЖНЫ возвращаться VRFY или EXPN.

Серверные реализации ДОЛЖНЫ поддерживать как VRFY, так и EXPN. По соображениям безопасности реализации МОГУТ предоставлять локальным установкам способ отключить одну или обе эти команды с помощью параметров конфигурации или аналогичных. Когда эти команды поддерживаются, они не обязаны работать через реле, когда ретрансляция поддерживается. Поскольку оба они являются необязательными в RFC 821, они ДОЛЖНЫ быть перечислены в качестве расширений службы в ответе EHLO, если они поддерживаются.

3.5.3 Значение ответа успеха VRFY или EXPN

Сервер НЕ ДОЛЖЕН возвращать код 250 в ответ на команду VRFY или EXPN, если он фактически не проверил адрес. В частности, сервер НЕ ДОЛЖЕН возвращать 250, если все, что он сделал, — это подтвердил, что приведенный синтаксис действителен. В этом случае ДОЛЖНЫ быть возвращены 502 (команда не реализована) или 500 (синтаксическая ошибка, команда не распознана). Как указано в другом месте, настоятельно рекомендуется реализация (в смысле фактической проверки адресов и возврата информации) VRFY и EXPN. Следовательно, реализации, которые возвращают 500 или 502 для VRFY, не полностью соответствуют этой спецификации.

Могут быть обстоятельства, когда адрес кажется действительным, но не может быть обоснованно проверен в реальном времени, особенно когда сервер выступает в роли почтового обменника для другого сервера или домена. «Кажущаяся достоверность» в этом случае обычно включает в себя, по крайней мере, проверку синтаксиса и может включать проверку того, что любые указанные домены являются доменами, на которые хост, как ожидается, сможет ретранслировать почту. В этих ситуациях код ответа 252 ДОЛЖЕН быть возвращен. Эти случаи параллельны обсуждению проверки RCPT, которое обсуждается в разделе 2.1. Аналогичным образом, обсуждение в разделе 3.4 относится к использованию кодов ответов 251 и 551 с VRFY (и EXPN) для указания адресов, которые распознаются, но которые будут переадресованы или отклонены, если для них будет получена почта. Реализации, как правило, ДОЛЖНЫ быть более агрессивными в отношении проверки адреса в случае VRFY, чем в случае RCPT, даже если это займет немного больше времени.

3.5.4 Семантика и применение EXPN

EXPN часто очень полезен для отладки и понимания проблем со списками рассылки и псевдонимами с несколькими целевыми адресами. Некоторые системы пытались использовать расширение источников списков рассылки для устранения дубликатов. Распространение систем псевдонимов с почтой в Интернете, для хостов (как правило, с записями DNS MX и CNAME), для почтовых ящиков (различные типы псевдонимов локальных хостов) и в различных механизмах прокси почти не позволяет этим стратегиям работать последовательно, и почтовые системы не должны пытаться их.

3.6 Домены

Только разрешаемые, полностью определенные доменные имена (FQDN) разрешены, когда доменные имена используются в SMTP. Другими словами, разрешены имена, которые могут быть разрешены в записи MX RR или A RR (как обсуждено в разделе 5), а также записи CNAME, цели которых, в свою очередь, могут быть разрешены в записи MX или A RR. Локальные псевдонимы или неквалифицированные имена НЕ ДОЛЖНЫ использоваться. Есть два исключения из правила, требующие полных доменных имен:

• Доменное имя, указанное в команде EHLO, ДОЛЖНО БЫТЬ либо основным именем хоста (доменное имя, которое разрешается в A RR), либо, если у хоста нет имени, литералом адреса, как описано в разделе 4.1.1.1.
• Зарезервированное имя почтового ящика «postmaster» может использоваться в команде RCPT без указания домена (см. Раздел 4.1.1.3) и ДОЛЖНО приниматься, если используется.

3.7 Эстафета

В целом, наличие записей Mail eXchanger в системе доменных имен [22, 27] делает ненужным использование явных исходных маршрутов в почтовой системе Интернета. Многие исторические проблемы с их интерпретацией сделали их использование нежелательным. Клиентам SMTP НЕ СЛЕДУЕТ генерировать явные исходные маршруты, за исключением необычных обстоятельств. SMTP-серверы МОГУТ отказываться действовать как почтовые ретрансляторы или принимать адреса, которые указывают исходные маршруты. Когда встречается информация о маршруте, SMTP-серверам также разрешается игнорировать информацию о маршруте и просто отправлять их в конечный пункт назначения, указанный в качестве последнего элемента в маршруте, и СЛЕДУЕТ это делать. Существует недопустимая практика использования имен, которые не отображаются в DNS в качестве имен назначения, при этом отправители рассчитывают на промежуточные хосты, указанные в маршрутизации источника, для решения любых проблем. Если исходные маршруты будут удалены, эта практика приведет к сбоям. Это одна из нескольких причин, почему SMTP-клиенты НЕ ДОЛЖНЫ генерировать недопустимые исходные маршруты или зависят от последовательного разрешения имен.

Когда исходные маршруты не используются, процесс, описанный в RFC 821 для построения обратного пути из прямого пути, не применим, и обратный путь во время доставки будет просто адресом, который появился в команде MAIL.

Ретрансляционный SMTP-сервер обычно является целью DNS-записи MX, которая его обозначает, а не конечной системой доставки. Сервер ретрансляции может принять или отклонить задачу ретрансляции почты так же, как он принимает или отклоняет почту для локального пользователя. Если он принимает задачу, он становится SMTP-клиентом, устанавливает канал передачи на следующий SMTP-сервер, указанный в DNS (согласно правилам в разделе 5), и отправляет ему почту. Если он отклоняет пересылку почты на определенный адрес по политическим причинам, ДОЛЖЕН быть возвращен ответ 550.

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

Важно отметить, что записи MX могут указывать на SMTP-серверы, которые действуют как шлюзы в другие среды, а не только на SMTP-ретрансляторы и системы конечной доставки; см. разделы 3.8 и 5.

Если SMTP-сервер принял на себя задачу ретрансляции почты, а затем обнаружил, что адресат указан неверно или что почта не может быть доставлена по какой-либо другой причине, тогда он ДОЛЖЕН создать сообщение с уведомлением о невозможности доставки и отправить его отправителю недоставленная почта (как указано обратным путем). Форматы, указанные для отчетов о недоставке по другим стандартам (см., Например, [24, 25]), ДОЛЖНЫ использоваться, если это возможно.

Это уведомление должно быть получено от SMTP-сервера на узле ретрансляции или хосте, который первым определяет, что доставка не может быть выполнена. Разумеется, SMTP-серверы НЕ ДОЛЖНЫ отправлять уведомления о проблемах при транспортировке уведомлений. Одним из способов предотвращения циклов в отчетах об ошибках является указание нулевого обратного пути в команде MAIL уведомления. Когда такое сообщение передается, обратный путь ДОЛЖЕН быть установлен равным нулю (см. Раздел 4.5.5 для дополнительного обсуждения). Команда MAIL с нулевым обратным путем выглядит следующим образом:

MAIL FROM:<>

Как обсуждалось в разделе 2.4.1, SMTP ретранслятора не нуждается в проверке или воздействии на заголовки или тело данных сообщения, и НЕ ДОЛЖЕН делать этого, за исключением добавления собственного заголовка «Received:» (раздел 4.4) и, необязательно, попытаться обнаружить зацикливание в почтовой системе (см. раздел 6.2).

3.8 Почтовый шлюз

Хотя рассмотренная выше функция ретрансляции работает в среде транспортных услуг SMTP в Интернете, записи MX или различные формы явной маршрутизации могут требовать, чтобы промежуточный SMTP-сервер выполнял функцию преобразования между одной транспортной службой и другой. Как обсуждалось в разделе 2.3.8, когда такая система находится на границе между двумя средами транспортных услуг, мы называем ее «шлюзом» или «шлюзом SMTP».

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

3.8.1 Поля заголовка в шлюзе

Поля заголовка МОГУТ при необходимости переписываться, так как сообщения передаются через границы почтовой среды. Это может включать проверку тела сообщения или интерпретацию локальной части адреса назначения, несмотря на запреты в разделе 2.4.1.

Другие почтовые системы, подключенные к Интернету, часто используют подмножество заголовков RFC 822 или предоставляют аналогичные функциональные возможности с другим синтаксисом, но некоторые из этих почтовых систем не имеют эквивалента конверту SMTP. Поэтому, когда сообщение покидает Интернет-среду, может возникнуть необходимость сложить информацию конверта SMTP в заголовок сообщения. Возможным решением будет создание новых полей заголовка для переноса информации о конверте (например, «X-SMTP-MAIL:» и «X-SMTP-RCPT:»); однако это потребует внесения изменений в почтовые программы в других странах и может привести к раскрытию частной информации (см. раздел 7.2).

3.8.2. Полученные строки в шлюзе

При пересылке сообщения в Интернет-среду или из нее шлюз ДОЛЖЕН предварять строку Received:, но он НЕ ДОЛЖЕН каким-либо образом изменять строку Received:, которая уже находится в заголовке.

Поля «получены:» сообщений, поступающих из других сред, могут не полностью соответствовать данной спецификации. Однако наиболее важное использование строк Received: предназначено для отладки почтовых сбоев, и эта отладка может быть серьезно затруднена шлюзами из лучших побуждений, которые пытаются «исправить» строку Received :. Как еще одно следствие полей трассировки, возникающих в средах, отличных от SMTP, принимающие системы НЕ ДОЛЖНЫ отклонять почту на основе формата поля трассировки и ДОЛЖНЫ быть чрезвычайно устойчивыми в свете неожиданной информации или форматов в этих полях.

Шлюз ДОЛЖЕН указывать среду и протокол в предложениях «через» полей «Получено», которые он предоставляет.

3.8.3 Адреса в шлюзе

Со стороны Интернета шлюз ДОЛЖЕН принимать все допустимые форматы адресов в командах SMTP и в заголовках RFC 822, а также все действительные сообщения RFC 822. Адреса и заголовки, генерируемые шлюзами, ДОЛЖНЫ соответствовать действующим интернет-стандартам (включая этот и RFC 822). Шлюзы, конечно, подчиняются тем же правилам для обработки исходных маршрутов, которые описаны для других систем SMTP в разделе 3.3.

3.8.4 Другие поля заголовка в шлюзе

Шлюз ДОЛЖЕН обеспечить, чтобы все поля заголовка сообщения, которое он пересылает в почтовую среду Интернета, соответствовали требованиям для почты Интернета. В частности, все адреса в полях «From:», «To:», «Cc:» и т. Д. ДОЛЖНЫ быть преобразованы (при необходимости) для соответствия синтаксису RFC 822, ДОЛЖНЫ ссылаться только на полностью определенные доменные имена и ДОЛЖНЫ быть эффективно и полезно для отправки ответов. Алгоритм преобразования, используемый для преобразования почты из интернет-протоколов в протокол другой среды, ДОЛЖЕН гарантировать, что сообщения об ошибках из внешней почтовой среды доставляются по обратному пути из конверта SMTP, а не отправителю, указанному в поле «От:» (или другие поля) сообщения RFC 822.

3.8.5 Конверты в шлюзе

Аналогично, при пересылке сообщения из другой среды в Интернет шлюз ДОЛЖЕН установить путь возврата конверта в соответствии с адресом возврата сообщения об ошибке, если он предоставляется внешней средой. Если во внешней среде нет эквивалентной концепции, шлюз должен выбрать и использовать наилучшее приближение с адресом отправителя сообщения по умолчанию в качестве последнего средства.

3.9 Завершение сеансов и соединений

SMTP-соединение прерывается, когда клиент отправляет команду QUIT. Сервер отвечает положительным кодом ответа, после чего он закрывает соединение.

SMTP-сервер НЕ ДОЛЖЕН преднамеренно закрывать соединение, за исключением:

• После получения команды ВЫХОД и ответа 221 ответом.
• После обнаружения необходимости закрыть службу SMTP и возврата кода ответа 421. Этот код ответа может быть выдан после того, как сервер получит какую-либо команду или, при необходимости, асинхронно из получения команды (при условии, что клиент получит его после выполнения следующей команды).

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

Сервер SMTP, который принудительно отключен с помощью внешних средств, ДОЛЖЕН попытаться отправить строку, содержащую код ответа 421, клиенту SMTP перед выходом. SMTP-клиент обычно читает код ответа 421 после отправки следующей команды.

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

3.10 Списки рассылки и псевдонимы

Узел с поддержкой SMTP ДОЛЖЕН поддерживать как псевдоним, так и модели списка расширения адресов для множественной доставки. Когда сообщение доставляется или пересылается на каждый адрес расширенной формы списка, адрес возврата в конверте («MAIL FROM:») ДОЛЖЕН быть изменен на адрес человека или другого объекта, который управляет списком. Однако в этом случае заголовок сообщения [32] ДОЛЖЕН быть оставлен без изменений; в частности, поле «От» заголовка сообщения не изменяется.

Важным почтовым средством является механизм доставки одного сообщения несколькими получателями путем преобразования (или «расширения» или «взрыва») адреса псевдопочты в список адресов почтового ящика назначения. Когда сообщение отправляется в такой псевдо-почтовый ящик (иногда называемый «взломщиком»), копии пересылаются или перераспределяются каждому почтовому ящику в расширенном списке. Серверы ДОЛЖНЫ просто использовать адреса в списке; Применение эвристики или других правил соответствия для устранения некоторых адресов, таких как адрес отправителя, настоятельно не рекомендуется. Мы классифицируем такой псевдопочтовый ящик как «псевдоним» или «список», в зависимости от правил расширения.

3.10.1 Псевдоним

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

3.10.2 Список

Можно сказать, что список рассылки работает «перераспределением», а не «пересылкой». Чтобы развернуть список, почтовая программа получателя заменяет адрес псевдопочты в конверте на все расширенные адреса. Адрес возврата в конверте изменяется, так что все сообщения об ошибках, сгенерированные окончательными доставками, будут возвращены администратору списка, а не отправителю сообщения, который обычно не контролирует содержимое списка и обычно находит сообщения об ошибках раздражающими.

4. Спецификации SMTP

4.1 SMTP-команды

4.1.1 Семантика и синтаксис команд

Команды SMTP определяют передачу почты или функцию почтовой системы, запрошенную пользователем. Команды SMTP — это строки символов, оканчивающиеся на <CRLF>. Сами команды представляют собой буквенные символы, оканчивающиеся на <SP>, если следуют параметры, и <CRLF> в противном случае. (В интересах улучшения совместимости SMTP-приемникам рекомендуется допускать конечный пробел перед завершающим <CRLF>.) Синтаксис локальной части почтового ящика должен соответствовать соглашениям сайта получателя и синтаксису, указанному в разделе 4.1.2. Команды SMTP обсуждаются ниже. Ответы SMTP обсуждаются в разделе 4.2.

Почтовая транзакция включает в себя несколько объектов данных, которые передаются в качестве аргументов различным командам. Обратный путь — это аргумент команды MAIL, прямой путь — это аргумент команды RCPT, а почтовые данные — аргумент команды DATA. Эти аргументы или объекты данных должны быть переданы и удерживаться в ожидании подтверждения, переданного указанием данных конца почты, которое завершает транзакцию. Модель для этого заключается в том, что предусмотрены различные буферы для хранения типов объектов данных, то есть есть буфер обратного пути, буфер прямого пути и почтовый буфер данных. Определенные команды приводят к добавлению информации в определенный буфер или к очистке одного или нескольких буферов.

Несколько команд (RSET, DATA, QUIT) указаны как не разрешающие параметры. В отсутствие конкретных расширений, предлагаемых сервером и принимаемых клиентом, клиенты НЕ ДОЛЖНЫ отправлять такие параметры, и серверам СЛЕДУЕТ отклонять содержащие их команды как имеющие неверный синтаксис.

4.1.1.1 Расширенный HELLO (EHLO) или HELLO (HELO)

Эти команды используются для идентификации SMTP-клиента на SMTP-сервере. Поле аргумента содержит полное доменное имя клиента SMTP, если оно доступно. В ситуациях, когда система клиента SMTP не имеет значимого доменного имени (например, когда его адрес распределяется динамически, а запись обратного сопоставления недоступна), клиент ДОЛЖЕН отправить буквенный адрес (см. Раздел 4.1.3), за которым следует необязательно по информации, которая поможет идентифицировать клиентскую систему. y SMTP-сервер идентифицирует себя для SMTP-клиента в ответе на приветствие соединения и в ответе на эту команду.

Клиент SMTP ДОЛЖЕН начать сеанс SMTP, введя команду EHLO. Если SMTP-сервер поддерживает расширения службы SMTP, он выдаст успешный ответ, ответ об ошибке или ответ об ошибке. Если SMTP-сервер, в нарушение этой спецификации, не поддерживает какие-либо расширения службы SMTP, он выдаст сообщение об ошибке. Более старые клиентские SMTP-системы МОГУТ, как обсуждалось выше, использовать HELO (как указано в RFC 821) вместо EHLO, и серверы ДОЛЖНЫ поддерживать команду HELO и правильно на нее отвечать. В любом случае клиент ДОЛЖЕН выдать HELO или EHLO перед началом почтовой транзакции.

Эти команды и ответ «250 OK» на одну из них подтверждают, что и клиент SMTP, и сервер SMTP находятся в исходном состоянии, то есть транзакция не выполняется, а все таблицы состояний и буферы очищены.

Синтаксис:

ehlo = «EHLO» SP Domain CRLF
helo = «HELO» SP Domain CRLF

Обычно ответ на EHLO будет многострочным. Каждая строка ответа содержит ключевое слово и, необязательно, один или несколько параметров. Следуя обычному синтаксису для многострочных ответов, эти сочетания клавиш следуют коду (250) и дефису для всех, кроме последней строки, а также коду и пробелу для последней строки. Синтаксис для положительного ответа с использованием обозначения ABNF и терминальных символов из [8]:

ehlo-ok-rsp = ( «250» domain [ SP ehlo-greet ] CRLF )
/ ( «250-» domain [ SP ehlo-greet ] CRLF
*( «250-» ehlo-line CRLF )
«250» SP ehlo-line CRLF )

ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF

ehlo-line = ehlo-keyword *( SP ehlo-param )

ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / «-«)
; additional syntax of ehlo-params depends on
; ehlo-keyword

ehlo-param = 1*(%d33-127)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 inclusive)

Хотя ключевые слова EHLO могут указываться в верхнем, нижнем или смешанном регистре, они ДОЛЖНЫ всегда распознаваться и обрабатываться без учета регистра. Это просто расширение практики, указанной в RFC 821 и разделе 2.4.1.

4.1.1.2 ПОЧТА MAIL (MAIL)

Эта команда используется для инициирования почтовой транзакции, в которой почтовые данные доставляются на SMTP-сервер, который, в свою очередь, может доставлять их в один или несколько почтовых ящиков или передавать их в другую систему (возможно, с использованием SMTP). Поле аргумента содержит обратный путь и может содержать необязательные параметры. В общем, команда MAIL может быть отправлена только тогда, когда не выполняется никакая почтовая транзакция, см. Раздел 4.1.4.

Обратный путь состоит из почтового ящика отправителя. Исторически этому почтовому ящику мог предшествовать список хостов, но это поведение теперь устарело (см. Приложение C). В некоторых типах сообщений с сообщениями, для которых ответ может вызвать зацикливание почты (например, уведомления о доставке почты и недоставке), обратный путь может быть нулевым (см. Раздел 3.7).

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

Если расширения службы были согласованы, команда MAIL также может нести параметры, связанные с конкретным расширением службы.

Синтаксис:

«MAIL FROM:» («<>» / Reverse-Path)
[SP Mail-parameters] CRLF

4.1.1.3 ПОЛУЧАТЕЛЬ RECIPIENT (RCPT)

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

Прямой путь обычно состоит из необходимого целевого почтового ящика. Отправляющим системам НЕ СЛЕДУЕТ генерировать дополнительный список хостов, известный как исходный маршрут. Приемные системы ДОЛЖНЫ распознавать синтаксис исходного маршрута, но ДОЛЖНЫ удалить спецификацию исходного маршрута и использовать доменное имя, связанное с почтовым ящиком, как если бы исходный маршрут не был предоставлен.

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

Например, почта, полученная на узле ретрансляции xyz.com с командами конверта

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

обычно отправляется напрямую на хост d.bar.org с помощью команд конверта

MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>

Как указано в приложении C, xyz.com МОЖЕТ также выбрать передачу сообщения на hosta.int, используя команды envelope

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

или jkl.org, используя команды конверта

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>

Конечно, поскольку хосты вообще не обязаны ретранслировать почту, xyz.com может также полностью отклонить сообщение при получении команды RCPT, используя код 550 (так как это «причина политики»).

Если расширения службы были согласованы, команда RCPT также может нести параметры, связанные с конкретным расширением службы, предлагаемым сервером. Клиент НЕ ДОЛЖЕН передавать параметры, отличные от тех, которые связаны с расширением услуги, предлагаемым сервером в его ответе EHLO.

Синтаксис:

«RCPT TO:» («<Postmaster@» domain «>» / «<Postmaster>» / Forward-Path)
[SP Rcpt-parameters] CRLF

4.1.1.4 ДАННЫЕ DATA (DATA)

Обычно получатель отправляет ответ 354 в DATA, а затем обрабатывает строки (строки, заканчивающиеся последовательностями <CRLF>, как описано в разделе 2.3.7) после команды как данные почты от отправителя. Эта команда вызывает добавление почтовых данных в буфер почтовых данных. Почтовые данные могут содержать любой из 128 кодов символов ASCII, хотя опыт показывает, что использование управляющих символов, отличных от SP, HT, CR и LF, может вызвать проблемы, и их следует по возможности избегать.

Почтовые данные заканчиваются строкой, содержащей только точку, то есть последовательность символов «<CRLF>. <CRLF>» (см. Раздел 4.5.2). Это указание конца почтовых данных. Обратите внимание, что первый <CRLF> этой завершающей последовательности также является <CRLF>, который завершает последнюю строку данных (текст сообщения) или, если данных не было, завершает саму команду DATA. НЕ ДОЛЖНО быть добавлен дополнительный <CRLF>, так как это приведет к добавлению пустой строки в сообщение. Единственное исключение из этого правила возникло бы, если бы тело сообщения было передано отправляющему SMTP-отправителю с последней «строкой», которая не заканчивалась на <CRLF>; в этом случае исходная SMTP-система ДОЛЖНА либо отклонить сообщение как недействительное, либо добавить <CRLF>, чтобы принимающий SMTP-сервер распознал условие «конец данных».

Обычай принимать строки, оканчивающиеся только на <LF>, как уступку несоответствующему поведению со стороны некоторых систем UNIX, доказал, что он вызывает больше проблем взаимодействия, чем решает, и серверные системы SMTP НЕ ДОЛЖНЫ делать это, даже в имя повышенной надежности. В частности, последовательность «<LF>. <LF>» (пустые переводы строк, без возврата каретки) НЕ ДОЛЖНА рассматриваться как эквивалентная <CRLF>. <CRLF> как указание на конец почтовых данных.

Получение указания данных об окончании почты требует, чтобы сервер обработал сохраненную информацию о транзакции почты. Эта обработка использует информацию в буфере обратного пути, буфере прямого пути и буфере почтовых данных, и по завершении этой команды эти буферы очищаются. Если обработка прошла успешно, получатель ДОЛЖЕН отправить ответ OK. Если обработка не удалась, получатель ДОЛЖЕН отправить ответ об ошибке. Модель SMTP не допускает частичных сбоев на этом этапе: либо сообщение принимается сервером для доставки и возвращается положительный ответ, либо оно не принимается, а ответ об ошибке возвращается. При отправке положительного ответа о завершении в конце индикации данных получатель несет полную ответственность за сообщение (см. Раздел 6.1). Об ошибках, которые впоследствии диагностируются, ДОЛЖНЫ быть сообщены в почтовом сообщении, как описано в разделе 4.4.

Когда SMTP-сервер принимает сообщение либо для ретрансляции, либо для окончательной доставки, он вставляет запись трассировки (также называемую взаимозаменяемо как «строка отметки времени» или «строка получено») в верхней части почтовых данных. Эта запись трассировки указывает идентификационную информацию хоста, который отправил сообщение, идентификационную информацию хоста, который получил сообщение (и вставляет эту метку времени), а также дату и время получения сообщения. Ретранслируемые сообщения будут иметь несколько временных отметок. Подробности формирования этих строк, включая их синтаксис, указаны в разделе 4.4.

Дополнительное обсуждение работы команды DATA приведено в разделе 3.3.

Синтаксис:

«DATA» CRLF

4.1.1.5 СБРОС RESET (RSET)

Эта команда указывает, что текущая почтовая транзакция будет прервана. Любые сохраненные данные об отправителе, получателях и почте ДОЛЖНЫ быть отброшены, а все буферы и таблицы состояний очищены. Получатель ДОЛЖЕН послать ответ «250 OK» на команду RSET без аргументов. Команда сброса может быть выдана клиентом в любое время. Он фактически эквивалентен NOOP (т. Е. Если не имеет никакого эффекта), если выдается сразу после EHLO, до того, как EHLO будет выдан в сеансе, после того, как индикатор конца данных был отправлен и подтвержден, или непосредственно перед QUIT. Сервер SMTP НЕ ДОЛЖЕН закрывать соединение в результате получения RSET; это действие зарезервировано для QUIT (см. раздел 4.1.1.10).

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

Существуют обстоятельства, противоречащие цели данной спецификации, в которых SMTP-сервер может получать указание о том, что основное TCP-соединение было закрыто или сброшено. Чтобы сохранить надежность почтовой системы, SMTP-серверы ДОЛЖНЫ быть подготовлены к этому условию и ДОЛЖНЫ обращаться с ним, как если бы было получено сообщение QUIT до исчезновения соединения.

Синтаксис:

«RSET» CRLF

4.1.1.6 ПРОВЕРКА VERIFY (VRFY)

Эта команда просит получателя подтвердить, что аргумент идентифицирует пользователя или почтовый ящик. Если это имя пользователя, информация возвращается, как указано в разделе 3.5.

Эта команда не влияет на буфер обратного пути, буфер прямого пути или буфер почтовых данных.

Синтаксис:

«VRFY» SP String CRLF

4.1.1.7 РАСШИРЕНИЕ EXPAND (EXPN)

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

Эта команда не влияет на буфер обратного пути, буфер прямого пути или буфер почтовых данных и может быть выполнена в любое время.

Синтаксис:

«EXPN» SP String CRLF

4.1.1.8 ПОМОЩЬ HELP (HELP)

Эта команда заставляет сервер отправлять полезную информацию клиенту. Команда МОЖЕТ принять аргумент (например, любое имя команды) и вернуть более конкретную информацию в качестве ответа.

Эта команда не влияет на буфер обратного пути, буфер прямого пути или буфер почтовых данных и может быть выполнена в любое время.

SMTP-серверы ДОЛЖНЫ поддерживать HELP без аргументов и МОГУТ поддерживать его с аргументами.

Синтаксис:

«HELP» [ SP String ] CRLF

4.1.1.9 КНОПКА NOOP (NOOP)

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

Эта команда не влияет на буфер обратного пути, буфер прямого пути или буфер почтовых данных и может быть выполнена в любое время. Если указана строка параметра, серверы ДОЛЖНЫ ее игнорировать.

Синтаксис:

«NOOP» [ SP String ] CRLF

4.1.1.10 ВЫЙТИ QUIT (QUIT)

Эта команда указывает, что получатель ДОЛЖЕН отправить ответ OK, а затем закрыть канал передачи.

Приемник НЕ ДОЛЖЕН преднамеренно закрывать канал передачи до тех пор, пока он не получит и не ответит на команду QUIT (даже если произошла ошибка). Отправитель НЕ ДОЛЖЕН преднамеренно закрывать канал передачи до тех пор, пока не отправит команду ВЫХОД, и ДОЛЖЕН подождать, пока не получит ответ (даже если на предыдущую команду было получено сообщение об ошибке). Если соединение преждевременно закрыто из-за нарушения вышеуказанного или сбоя системы или сети, сервер ДОЛЖЕН отменить любую незавершенную транзакцию, но не отменить ранее завершенную транзакцию и, как правило, ДОЛЖЕН действовать так, как если бы выполняемая команда или транзакция получила временную ошибка (т.е. ответ 4yz).

Команда QUIT может быть введена в любое время.

Синтаксис:

«QUIT» CRLF

 

4.1.2 Синтаксис аргумента команды

Синтаксис полей аргументов вышеуказанных команд (с использованием синтаксиса, указанного в [8], где это применимо) приведен ниже. Некоторые из приведенных ниже продуктов используются только в сочетании с исходными маршрутами, как описано в приложении C. Терминалы, не определенные в этом документе, такие как ALPHA, DIGIT, SP, CR, LF, CRLF, соответствуют определению в синтаксисе «core». [8 (раздел 6)] или в синтаксисе формата сообщения [32].

Reverse-path = Path
Forward-path = Path
Path = «<» [ A-d-l «:» ] Mailbox «>»
A-d-l = At-domain *( «,» A-d-l )
; Note that this form, the so-called «source route»,
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain = «@» domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)

esmtp-param = esmtp-keyword [«=» esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / «-«)
esmtp-value = 1*(%d33-60 / %d62-127)
; any CHAR excluding «=», SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*(«.» sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = «[» IPv4-address-literal /
IPv6-address-literal /
General-address-literal «]»
; See section 4.1.3

Mailbox = Local-part «@» Domain

Local-part = Dot-string / Quoted-string
; MAY be case-sensitive

Dot-string = Atom *(«.» Atom)

Atom = 1*atext

Quoted-string = DQUOTE *qcontent DQUOTE

String = Atom / Quoted-string

Хотя приведенное выше определение для Local-part является относительно разрешающим, для максимальной функциональной совместимости хосту, который ожидает получения почты, СЛЕДУЕТ избегать определения почтовых ящиков, где Local-часть требует (или использует) форму Quoted-string или где Local-part чувствительна к регистру. , Для любых целей, которые требуют генерирования или сравнения Local-частей (например, с конкретными именами почтовых ящиков), все цитируемые формы ДОЛЖНЫ рассматриваться как эквивалентные, и отправляющая система ДОЛЖНА передавать форму, которая использует минимально возможное цитирование.

Системы НЕ ДОЛЖНЫ определять почтовые ящики таким образом, чтобы требовать использования в SMTP не-ASCII символов (октеты с битом старшего разряда, установленным в единицу) или ASCII «управляющих символов» (десятичные значения 0-31 и 127). Эти символы НЕ ДОЛЖНЫ использоваться в командах MAIL или RCPT или других командах, которым требуются имена почтовых ящиков.

Обратите внимание, что обратная косая черта, «\», является символом кавычки, который используется, чтобы указать, что следующий символ должен использоваться буквально (вместо его обычной интерпретации). Например, «Joe \, Smith» указывает одно пользовательское поле из девяти символов, запятая является четвертым символом поля.

Для обеспечения совместимости и в соответствии с давними рекомендациями о консервативном использовании DNS в именовании и приложениях (например, см. Раздел 2.3.1 базового документа DNS, RFC1035 [22]), символы вне набора букв, цифр и Дефис НЕ ДОЛЖЕН появляться в метках доменных имен для SMTP-клиентов или серверов. В частности, символ подчеркивания не допускается. Серверы SMTP, которые получают команду, в которой были использованы недопустимые коды символов и для которой нет других причин отклонения, ДОЛЖНЫ отклонить эту команду с ответом 501.

4.1.3 Адресные литералы

Иногда хост не известен системе доменных имен, и связь (и, в частности, связь для сообщения и исправления ошибки) блокируется. Чтобы обойти этот барьер, в качестве альтернативы доменному имени разрешена специальная буквенная форма адреса. Для адресов IPv4 эта форма использует четыре небольших десятичных целых числа, разделенных точками и заключенных в квадратные скобки, такие как [123.255.37.2], который указывает (IPv4) Интернет-адрес в форме последовательности октетов. Для IPv6 и других форм адресации, которые в конечном итоге могут быть стандартизированы, форма состоит из стандартизированного «тега», который идентифицирует синтаксис адреса, двоеточие и сам адрес, в формате, заданном как часть стандартов IPv6 [17].

В частности:

IPv4-address-literal = Snum 3(«.» Snum)
IPv6-address-literal = «IPv6:» IPv6-addr
General-address-literal = Standardized-tag «:» 1*dcontent
Standardized-tag = Ldh-str
; MUST be specified in a standards-track RFC
; and registered with IANA
Snum = 1*3DIGIT ; representing a decimal integer
; value in the range 0 through 255
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / «-» ) Let-dig
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(«:» IPv6-hex)
IPv6-comp = [IPv6-hex *5(«:» IPv6-hex)] «::» [IPv6-hex *5(«:»
IPv6-hex)]
; The «::» represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the «::» may be
; present
IPv6v4-full = IPv6-hex 5(«:» IPv6-hex) «:» IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(«:» IPv6-hex)] «::»

[IPv6-hex *3(«:» IPv6-hex) «:»] IPv4-address-literal
; The «::» represents at least 2 16-bit groups of zeros
; No more than 4 groups in addition to the «::» and
; IPv4-address-literal may be present

4.1.4 Порядок команд

Существуют ограничения на порядок использования этих команд.

Сеанс, который будет содержать почтовые транзакции, ДОЛЖЕН быть сначала инициализирован с помощью команды EHLO. SMTP-сервер ДОЛЖЕН принимать команды для не-почтовых транзакций (например, VRFY или EXPN) без этой инициализации.

Команда EHLO МОЖЕТ быть выдана клиентом позже в сеансе. Если он выдается после начала сеанса, SMTP-сервер ДОЛЖЕН очистить все буферы и сбросить состояние точно так, как если бы была введена команда RSET. Другими словами, последовательность RSET, за которой сразу следует EHLO, является избыточной, но не наносит вреда, кроме затрат на производительность выполнения ненужных команд.

Если команда EHLO неприемлема для SMTP-сервера, 501, 500 или 502 сообщения об ошибках ДОЛЖНЫ быть возвращены в зависимости от ситуации. Сервер SMTP ДОЛЖЕН оставаться в том же состоянии после передачи этих ответов, в которых он находился до получения EHLO.

Клиент SMTP ДОЛЖЕН, если возможно, гарантировать, что параметр домена для команды EHLO является допустимым именем основного хоста (не CNAME или MX) для своего хоста. Если это невозможно (например, когда адрес клиента назначается динамически, а клиент не имеет очевидного имени), следует заменить буквенное значение адреса на доменное имя и предоставленную дополнительную информацию, которая поможет в идентификации клиента.

SMTP-сервер МОЖЕТ проверить, что параметр имени домена в команде EHLO действительно соответствует IP-адресу клиента. Однако сервер НЕ ДОЛЖЕН отказываться принимать сообщение по этой причине, если проверка не удалась: информация об ошибке проверки предназначена только для регистрации и отслеживания.

Команды NOOP, HELP, EXPN, VRFY и RSET могут использоваться в любое время в течение сеанса или без предварительной инициализации сеанса. SMTP-серверам СЛЕДУЕТ обрабатывать их нормально (т.е. не возвращать код 503), даже если команда EHLO еще не получена; клиенты ДОЛЖНЫ открыть сеанс с EHLO перед отправкой этих команд.

Если эти правила соблюдаются, пример в RFC 821, который показывает «550 доступ запрещен для вас» в ответ на команду EXPN, является неправильным, если команда EHLO не предшествует EXPN, или отказ в доступе основан на IP-адресе клиента или другой аутентификации или механизмы определения авторизации.

Команда MAIL (или устаревшие команды SEND, SOML или SAML) начинает почтовую транзакцию. После запуска почтовая транзакция состоит из команды начала транзакции, одной или нескольких команд RCPT и команды DATA в указанном порядке. Почтовая транзакция может быть прервана командой RSET (или новой EHLO). В сеансе может быть ноль или более транзакций. MAIL (или SEND, SOML или SAML) НЕ ДОЛЖНЫ отправляться, если почтовая транзакция уже открыта, т. Е. Отправлять ее следует только в том случае, если в сеансе не было запущено ни одной почтовой транзакции, или если предыдущая успешно завершилась успешным Команда DATA, или если предыдущая была прервана с помощью RSET.

Если аргумент команды начала транзакции неприемлем, ответ 501 об ошибке ДОЛЖЕН быть возвращен, а SMTP-сервер ДОЛЖЕН оставаться в том же состоянии. Если команды в транзакции вышли из строя в той степени, в которой они не могут быть обработаны сервером, ответ 503 об ошибке ДОЛЖЕН быть возвращен, а сервер SMTP ДОЛЖЕН оставаться в том же состоянии.

Последняя команда в сеансе ДОЛЖНА быть командой QUIT. Команда QUIT не может использоваться в любое другое время сеанса, но ДОЛЖНА использоваться клиентом SMTP для запроса на закрытие соединения, даже если команда открытия сеанса не была отправлена ​​и принята.

4.1.5 Команды частного использования

Как указано в разделе 2.2.2, команды, начинающиеся с «X», могут использоваться по двустороннему соглашению между SMTP-агентами клиента (отправляющего) и сервера (получающего). Ожидается, что SMTP-сервер, который не распознает такую команду, ответит «500 Команда не распознана». Расширенный SMTP-сервер МОЖЕТ перечислить имена функций, связанных с этими частными командами, в ответ на команду EHLO.

Команды, отправленные или принятые системами SMTP, которые не начинаются с «X», ДОЛЖНЫ соответствовать требованиям раздела 2.2.2.

4.2 Ответы SMTP

Ответы на команды SMTP служат для обеспечения синхронизации запросов и действий в процессе пересылки почты и для гарантии того, что SMTP-клиент всегда знает состояние SMTP-сервера. Каждая команда ДОЛЖНА генерировать ровно один ответ.

Детали последовательности команда-ответ описаны в разделе 4.3.

Ответ SMTP состоит из трехзначного числа (переданного в виде трех числовых символов), за которым следует некоторый текст, если в этом документе не указано иное. Номер предназначен для использования автоматами, чтобы определить, в какое состояние войти дальше; текст предназначен для пользователя. Три цифры содержат достаточно закодированной информации, поэтому SMTP-клиенту не нужно проверять текст, и он может либо отбросить его, либо, при необходимости, передать его пользователю. Исключения, как отмечено в другом месте в этом документе. В частности, коды ответов 220, 221, 251, 421 и 551 связаны с текстом сообщения, который должен анализироваться и интерпретироваться машинами. В общем случае текст может зависеть от получателя и от контекста, поэтому для каждого кода ответа могут быть различные тексты. Обсуждение теории кодов ответов приведено в разделе 4.2.1. Формально ответ определяется как последовательность: трехзначный код, <SP>, одна строка текста и <CRLF> или многострочный ответ (как определено в разделе 4.2.1). Поскольку в нарушение этой спецификации текст иногда не отправляется, клиенты, которые его не получают, ДОЛЖНЫ быть готовы обрабатывать код один (с символом завершающего пробела или без него). Ожидается, что только команды EHLO, EXPN и HELP приведут к многострочным ответам в нормальных условиях, однако многострочные ответы разрешены для любой команды.

В ABNF ответы сервера:

Greeting = «220 » Domain [ SP text ] CRLF
Reply-line = Reply-code [ SP text ] CRLF

где «Приветствие — Greeting» появляется только в ответе 220, который объявляет, что сервер открывает свою часть соединения.

SMTP-сервер ДОЛЖЕН отправлять только коды ответов, перечисленные в этом документе. SMTP-сервер ДОЛЖЕН использовать текст, показанный в примерах, всякий раз, когда это необходимо.

SMTP-клиент ДОЛЖЕН определять свои действия только по коду ответа, а не по тексту (за исключением «изменения адреса» 251 и 551 и, при необходимости, ответов 220, 221 и 421); в общем случае любой текст, включая текст вообще (хотя отправители НЕ ДОЛЖНЫ отправлять открытые коды), ДОЛЖЕН быть приемлемым. Пробел (пустой), следующий за кодом ответа, считается частью текста. Когда это возможно, SMTP-приемник ДОЛЖЕН проверять первую цифру (указание серьезности) кода ответа.

Список кодов, приведенный ниже, НЕ ДОЛЖЕН истолковываться как постоянный. В то время как добавление новых кодов должно быть редким и значительным видом деятельности, при этом предпочтительной является дополнительная информация в текстовой части ответа, новые коды могут добавляться в результате новых стандартов или спецификаций отслеживания стандартов. Следовательно, отправитель-SMTP ДОЛЖЕН быть готов обрабатывать коды, не указанные в этом документе, и ДОЛЖЕН делать это только путем интерпретации только первой цифры.

4.2.1 Серьезность и теория кода ответа

Три цифры ответа имеют особое значение. Первая цифра обозначает, является ли ответ хорошим, плохим или неполным. Неискушенный SMTP-клиент или тот, кто получает неожиданный код, сможет определить свое следующее действие (выполнить как запланировано, повторить, восстановить и т. Д.), Изучив эту первую цифру. SMTP-клиент, который хочет приблизительно узнать, какой тип ошибки произошел (например, системная ошибка почты, синтаксическая ошибка команды), может проверить вторую цифру. Третья цифра и любая дополнительная информация, которая может присутствовать, зарезервированы для наилучшей градации информации.

Существует пять значений для первой цифры кода ответа:

• 1yz Положительный Предварительный ответ. Команда была принята, но запрошенное действие приостановлено в ожидании подтверждения информации в этом ответе. SMTP-клиент должен отправить другую команду, указывающую, продолжать или прервать действие. Примечание: в расширенном SMTP нет команд, разрешающих этот тип ответа, и поэтому нет команд продолжения или прерывания.
• 2yz Положительный ответ о завершении. Запрошенное действие было успешно выполнено. Новый запрос может быть инициирован.
• 3yz Положительный Промежуточный ответ. Команда была принята, но запрошенное действие приостановлено до получения дополнительной информации. Клиент SMTP должен отправить другую команду, указав эту информацию. Этот ответ используется в группах последовательностей команд (то есть в DATA).
• 4yz Переходный Отрицательный ответ о завершении. Команда не была принята, и запрошенное действие не произошло. Однако условие ошибки является временным, и действие может быть запрошено снова. Отправитель должен вернуться к началу последовательности команд (если есть). Трудно присвоить значение термину «переходный процесс», когда два разных сайта (SMTP-агенты получателя и отправителя) должны согласовать интерпретацию. Каждый ответ в этой категории может иметь разное значение времени, но SMTP-клиенту рекомендуется повторить попытку. Эмпирическое правило, определяющее, подходит ли ответ к категории 4yz или 5yz (см. Ниже), заключается в том, что ответы имеют размер 4yz, если они могут быть успешными, если они повторяются без каких-либо изменений в форме команды или в свойствах отправителя или получателя (то есть , команда повторяется одинаково, и получатель не устанавливает новую реализацию.)
• 5yz Постоянный отрицательный ответ о завершении. Команда не была принята, и запрошенное действие не произошло. Клиент SMTP не рекомендуется повторять точный запрос (в той же последовательности). Даже некоторые «постоянные» условия ошибки могут быть исправлены, поэтому пользователь-человек может пожелать, чтобы SMTP-клиент повторно инициировал последовательность команд путем прямого действия в некоторый момент в будущем (например, после того, как написание было изменено, или пользователь изменил статус аккаунта).

Вторая цифра кодирует ответы в определенных категориях:

• Синтаксис x0z. Эти ответы относятся к синтаксическим ошибкам, синтаксически корректным командам, которые не соответствуют ни одной функциональной категории, а также к невыполненным или лишним командам.
• x1z Информация: это ответы на запросы о предоставлении информации, такой как статус или помощь.
• x2z Connections: это ответы, относящиеся к каналу передачи.
• x3z Не указано.
• x4z не указано.
• Почтовая система x5z: в этих ответах указывается состояние почтовой системы получателя в отношении запрошенной передачи или других действий почтовой системы.

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

Например, такая команда, как NOOP, чье успешное выполнение не предлагает SMTP-клиенту никакой новой информации, вернет ответ 250. Ответ 502, когда команда запрашивает невыполненное не специфичное для сайта действие. Уточнение этого является ответом 504 для команды, которая реализована, но которая запрашивает невыполненный параметр.

Текст ответа может быть длиннее одной строки; в этих случаях полный текст должен быть помечен, чтобы SMTP-клиент знал, когда он может прекратить чтение ответа. Для этого требуется специальный формат для указания многострочного ответа.

Формат многострочных ответов требует, чтобы каждая строка, кроме последней, начиналась с кода ответа, после которого следовал бы дефис, «-» (также известный как минус), за которым следовал текст. Последняя строка начинается с кода ответа, за которым сразу следует <SP>, необязательно некоторый текст и <CRLF>. Как отмечено выше, серверам СЛЕДУЕТ отправлять <SP>, если последующий текст не отправляется, но клиенты ДОЛЖНЫ быть готовы к тому, что он будет пропущен.

Например:

123-First line
123-Second line
123-234 text beginning with numbers
123 The last line

Во многих случаях SMTP-клиенту тогда просто нужно найти строку, начинающуюся с кода ответа, за которым следует <SP> или <CRLF>, и игнорировать все предыдущие строки. В некоторых случаях в ответе «текст» содержатся важные данные для клиента. Клиент сможет идентифицировать эти случаи из текущего контекста.

4.2.2 Коды ответов по группам функций

500 Синтаксическая ошибка, команда не распознана (это может включать такие ошибки, как слишком длинная командная строка)
501 Синтаксическая ошибка в параметрах или аргументах
502 Команда не выполнена (см. Раздел 4.2.4)
503 Плохая последовательность команд
504 Параметр команды не реализован
211 Состояние системы или ответ системной помощи
214 Справочное сообщение (информация о том, как использовать приемник или значение конкретной нестандартной команды; этот ответ полезен только для пользователя)
220 <домен> Сервис готов
221 <домен> Служба закрытия канала передачи
421 <домен> Служба недоступна, закрытие канала передачи (это может быть ответ на любую команду, если служба знает, что она должна завершиться)
250 Запрошенное почтовое действие в порядке, выполнено
251 Пользователь не локальный; переадресация на <forward-path> (см. раздел 3.4)
252 Не может VRFY пользователь, но примет сообщение и попытается доставить (см. Раздел 3.5.3)
450 Запрошенное почтовое действие не выполнено: почтовый ящик недоступен (например, почтовый ящик занят)
550 Запрошенное действие не выполнено: почтовый ящик недоступен (например, почтовый ящик не найден, нет доступа или команда отклонена по соображениям политики)
451 Запрошенное действие прервано: ошибка в обработке
551 Пользователь не локальный; пожалуйста попробуйте <forward-path> (см. раздел 3.4)
452 Запрошенное действие не выполнено: недостаточно системного хранилища
552 Запрошенное действие почты прервано: превышено выделение памяти
553 Запрошенное действие не выполнено: имя почтового ящика не разрешено (например, неверный синтаксис почтового ящика)
354 Начать ввод почты; заканчивается <CRLF>. <CRLF>
554 Транзакция не удалась (или, в случае ответа об открытии соединения, «здесь нет службы SMTP»)

4.2.3 Коды ответов в числовом порядке

211 Состояние системы или ответ системной помощи
214 Справочное сообщение (информация о том, как использовать приемник или значение конкретной нестандартной команды; этот ответ полезен только для пользователя)
220 <домен> Сервис готов
221 <домен> Служба закрытия канала передачи
250 Запрошенное почтовое действие в порядке, выполнено
251 Пользователь не локальный; переадресация на <forward-path> (см. раздел 3.4)
252 Не может VRFY пользователь, но примет сообщение и попытается доставить (см. Раздел 3.5.3)
354 Начать ввод почты; заканчивается <CRLF>. <CRLF>
421 <домен> Служба недоступна, закрытие канала передачи (это может быть ответ на любую команду, если служба знает, что она должна завершиться)
450 Запрошенное почтовое действие не выполнено: почтовый ящик недоступен (например, почтовый ящик занят)
451 Запрошенное действие прервано: локальная ошибка в обработке
452 Запрошенное действие не выполнено: недостаточно системного хранилища
500 Синтаксическая ошибка, команда не распознана (это может включать такие ошибки, как слишком длинная командная строка)
501 Синтаксическая ошибка в параметрах или аргументах
502 Команда не выполнена (см. Раздел 4.2.4)
503 Плохая последовательность команд
504 Параметр команды не реализован
550 Запрошенное действие не выполнено: почтовый ящик недоступен (например, почтовый ящик не найден, нет доступа или команда отклонена по соображениям политики)
551 Пользователь не локальный; пожалуйста попробуйте <forward-path> (см. раздел 3.4)
552 Запрошенное действие почты прервано: превышено выделение памяти
553 Запрошенное действие не выполнено: имя почтового ящика не разрешено (например, неверный синтаксис почтового ящика)
554 Транзакция не удалась (или, в случае ответа об открытии соединения, «здесь нет службы SMTP»)

4.2.4 Код ответа 502

Были заданы вопросы о том, когда код ответа 502 (команда не реализована) ДОЛЖЕН быть возвращен в предпочтении другим кодам. 502 СЛЕДУЕТ использовать, когда команда фактически распознается SMTP-сервером, но не реализована. Если команда не распознана, ДОЛЖЕН быть возвращен код 500. Расширенные SMTP-системы НЕ ДОЛЖНЫ перечислять возможности в ответ на EHLO, для которых они будут возвращать 502 (или 500) ответов.

4.2.5 Коды ответа после DATA и последующего <CRLF>. <CRLF>

Когда SMTP-сервер возвращает положительное состояние завершения (код 2yz) после выполнения команды DATA с помощью <CRLF>. <CRLF>, он принимает на себя ответственность за:

• доставка сообщения (если почтовый ящик получателя существует), или
• если попытка доставить сообщение не удалась из-за переходных условий, повторите попытку доставки разумное количество раз с интервалами, как указано в разделе 4.5.4.
• если попытки доставить сообщение потерпели неудачу из-за постоянных условий, или если повторные попытки доставить сообщение потерпели неудачу из-за переходных условий, возвращать соответствующее уведомление отправителю исходного сообщения (используя адрес в команде SMTP MAIL).

Когда SMTP-сервер возвращает код состояния постоянной ошибки (5yz) после выполнения команды DATA с помощью <CRLF>. <CRLF>, он НЕ ДОЛЖЕН предпринимать какие-либо последующие попытки доставить это сообщение. SMTP-клиент сохраняет ответственность за доставку этого сообщения и может либо вернуть его пользователю, либо повторно запросить его для последующей попытки (см. Раздел 4.5.4.1).

Пользователь, создавший сообщение, ДОЛЖЕН иметь возможность интерпретировать возвращение статуса временного сбоя (по почтовому сообщению или иным образом) как указание о недоставке, так же как будет интерпретирован постоянный сбой. То есть, если клиент SMTP успешно обрабатывает эти условия, пользователь не получит такой ответ.

Когда SMTP-сервер возвращает код состояния постоянной ошибки (5yz) после того, как команда DATA полностью соответствует <CRLF>. <CRLF>, он НЕ ДОЛЖЕН предпринимать какие-либо последующие попытки доставить сообщение. Как и с временными кодами ошибок, SMTP-клиент сохраняет ответственность за сообщение, но СЛЕДУЕТ снова не пытаться доставить его на тот же сервер без проверки и вмешательства пользователя.

4.3 Последовательность команд и ответов

4.3.1 Обзор последовательности

Связь между отправителем и получателем представляет собой чередующийся диалог, контролируемый отправителем. Таким образом, отправитель выдает команду, а получатель отвечает ответом. Если другие соглашения не согласованы с помощью расширений службы, отправитель ДОЛЖЕН дождаться этого ответа, прежде чем отправлять дальнейшие команды.

Одним из важных ответов является приветствие соединения. Обычно получатель отправляет ответ 220 «Service ready» после завершения соединения. Отправителю СЛЕДУЕТ подождать это приветственное сообщение, прежде чем отправлять какие-либо команды.

Примечание: все ответы приветствующего типа имеют официальное имя (полное имя основного домена) хоста сервера в качестве первого слова, следующего за кодом ответа. Иногда у хоста не будет значимого имени. См. 4.1.3 для обсуждения альтернатив в этих ситуациях.

Например:

220 ISIF.USC.EDU Service ready
или
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
или
220 [10.0.0.1] Clueless host service ready

В таблице ниже перечислены альтернативные ответы об успехах и неудачах для каждой команды. К ним СЛЕДУЕТ строго придерживаться: получатель может заменить текст в ответах, но значение и действие, подразумеваемые кодовыми номерами и конкретной последовательностью ответа команды, не могут быть изменены.

4.3.2 Последовательности команд-ответов

Каждая команда указана с ее обычными возможными ответами. Префиксы, используемые перед возможными ответами: «I» для промежуточного, «S» для успеха и «E» для ошибки. Поскольку некоторые серверы могут генерировать другие ответы при особых обстоятельствах и для обеспечения возможности дальнейшего расширения, SMTP-клиенты ДОЛЖНЫ, когда это возможно, интерпретировать только первую цифру ответа и ДОЛЖНЫ быть готовы обрабатывать нераспознанные коды ответов, интерпретируя только первую цифру. Если не расширены с использованием механизмов, описанных в разделе 2.2, SMTP-серверы НЕ ДОЛЖНЫ передавать коды ответа SMTP-клиенту, отличные от трех цифр или не начинающиеся с цифры от 2 до 5 включительно.

Эти правила последовательности и, в принципе, сами коды могут быть расширены или изменены расширениями SMTP, предложенными сервером и принятыми (запрошенными) клиентом.

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

• 500 Для случая «слишком длинная командная строка» или если имя команды не было распознано. Обратите внимание, что создание ошибки «команда не распознана» в ответ на обязательное подмножество этих команд является нарушением этой спецификации.
• 501 Синтаксическая ошибка в команде или аргументах. Для обеспечения будущих расширений командам, указанным в этом документе как не принимающие аргументы (DATA, RSET, QUIT), СЛЕДУЕТ возвращать сообщение 501, если аргументы предоставляются в отсутствие расширений EHLOadvertised.
• 421 Сервисное отключение и закрытие канала передачи

Конкретные последовательности:

CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221

4.4 Информация о трассировке

Когда SMTP-сервер получает сообщение для доставки или дальнейшей обработки, он ДОЛЖЕН вставить информацию трассировки («отметка времени» или «получено») в начало содержимого сообщения, как описано в разделе 4.1.1.4.

Эта строка ДОЛЖНА быть структурирована следующим образом:

• Поле FROM, которое ДОЛЖНО быть предоставлено в среде SMTP, ДОЛЖНО содержать как (1) имя хоста источника, как представлено в команде EHLO, так и (2) литерал адреса, содержащий IP-адрес источника, определенный из TCP соединение.
• Поле идентификатора МОЖЕТ содержать «@», как предлагается в RFC 822, но это не обязательно.
• Поле FOR МОЖЕТ содержать список записей <path>, если было дано несколько команд RCPT. Это может вызвать некоторые проблемы с безопасностью и обычно нежелательно; см. раздел 7.2.

Программа Интернет-почты НЕ ДОЛЖНА изменять строку Received:, которая ранее была добавлена в заголовок сообщения. SMTP-серверы ДОЛЖНЫ добавлять в сообщения полученные строки; они НЕ ДОЛЖНЫ изменять порядок существующих строк или вставлять полученные строки в любое другое место.

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

Когда SMTP-сервер доставки выполняет «окончательную доставку» сообщения, он вставляет строку обратного пути в начало почтовых данных. Это использование return-path обязательно; Почтовые системы ДОЛЖНЫ поддерживать это. Строка обратного пути сохраняет информацию в <reversepath> из команды MAIL. Здесь окончательная доставка означает, что сообщение покинуло среду SMTP. Обычно это означало бы, что оно было доставлено конечному пользователю или связанному удалению почты, но в некоторых случаях оно может быть дополнительно обработано и передано другой почтовой системой.

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

Приведенный выше текст подразумевает, что окончательные данные почты будут начинаться со строки обратного пути, за которой следуют одна или несколько строк меток времени. За этими строками будут следовать заголовки и текст почтовых данных [32].

Иногда SMTP-серверу трудно определить, выполняет ли он окончательную доставку, поскольку пересылка или другие операции могут происходить после того, как сообщение принято для доставки. Следовательно, любые дальнейшие системы (переадресация, шлюз или ретрансляция) МОГУТ удалить путь возврата и перестроить команду MAIL по мере необходимости, чтобы гарантировать, что ровно одна такая строка появляется в доставленном сообщении.

Система SMTP, отправляющая сообщения, НЕ ДОЛЖНА отправлять сообщение, которое уже содержит заголовок Return-path. SMTP-серверы, выполняющие функцию ретрансляции, НЕ ДОЛЖНЫ проверять данные сообщения, особенно в той степени, которая необходима для определения наличия заголовков Return-path. SMTP-серверы, выполняющие окончательную доставку, МОГУТ удалить заголовки Return-path перед добавлением своих собственных.

Основная цель Return-path — указать адрес, по которому должны отправляться сообщения, указывающие на недоставку или другие сбои почтовой системы. Чтобы это было однозначным, при доставке сообщения ДОЛЖЕН присутствовать ровно один обратный путь. Системам, использующим синтаксис RFC 822 с транспортами не-SMTP, СЛЕДУЕТ назначать однозначный адрес, связанный с транспортным конвертом, на который следует отправлять отчеты об ошибках (например, сообщения о недоставке).

Историческая справка: текст в RFC 822, который, по-видимому, противоречит использованию заголовка Return-path (или адреса обратного пути конверта из команды MAIL) в качестве места назначения для сообщений об ошибках, не применяется в Интернете. Адрес обратного пути (как скопировано в Return-path) ДОЛЖЕН использоваться в качестве цели любой почты, содержащей сообщения об ошибках доставки.

Особенно:

• шлюз из SMTP-> в другом месте ДОЛЖЕН вставлять заголовок обратного пути, если только не известно, что транспорт «в другом месте» также использует адреса домена Интернета и поддерживает адрес отправителя конверта отдельно.
• шлюз из другого места-> SMTP ДОЛЖЕН удалить любой заголовок обратного пути, присутствующий в сообщении, и либо скопировать эту информацию в конверт SMTP, либо объединить ее с информацией, присутствующей в конверте другой транспортной системы, для создания аргумента обратного пути к команда MAIL в конверте SMTP.

Сервер должен уделять особое внимание случаям, когда обработка, следующая за указанием конца почтовых данных, является только частично успешной. Это может произойти, если после приема нескольких получателей и почтовых данных SMTP-сервер обнаружит, что почтовые данные могут быть успешно доставлены некоторым, но не всем получателям. В таких случаях ответ на команду DATA ДОЛЖЕН быть ответом OK. Однако SMTP-сервер ДОЛЖЕН составить и отправить отправителю сообщения уведомление о «невозможности доставки почты».

 

НЕОБХОДИМО, чтобы для каждого отказавшего получателя отправлялось одно уведомление со списком всех неудачных получателей или отдельные уведомления. Для экономии обработки отправителем предпочтительнее первое, когда это возможно. Все недоставленные почтовые уведомления отправляются с помощью команды MAIL (даже если они являются результатом обработки устаревших команд SEND, SOML или SAML) и используют нулевой путь возврата, как описано в разделе 3.7.

Линия отметки времени и линия обратного пути формально определяются следующим образом:

Return-path-line = «Return-Path:» FWS Reverse-path <CRLF>
Time-stamp-line = «Received:» FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info «;» FWS date-time
; where «date-time» is as defined in [32]
; but the «obs-» forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
From-domain = «FROM» FWS Extended-Domain CFWS
By-domain = «BY» FWS Extended-Domain CFWS
Extended-Domain = Domain /
( Domain FWS «(» TCP-info «)» ) /
( Address-literal FWS «(» TCP-info «)» )
TCP-info = Address-literal / ( Domain FWS Address-literal )
; Information derived by server from TCP connection
; not client EHLO.
Opt-info = [Via] [With] [ID] [For]
Via = «VIA» FWS Link CFWS
With = «WITH» FWS Protocol CFWS
ID = «ID» FWS String / msg-id CFWS
For = «FOR» FWS 1*( Path / Mailbox ) CFWS
Link = «TCP» / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are registered with the
; Internet Assigned Numbers Authority (IANA). «Via» is
; primarily of value with non-Internet transports. SMTP

; servers SHOULD NOT use unregistered names.
Protocol = «ESMTP» / «SMTP» / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with the
; Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.

4.5 Дополнительные вопросы реализации

4.5.1 Минимальная реализация

Чтобы SMTP работал, для всех получателей требуется следующая минимальная реализация. Следующие команды ДОЛЖНЫ поддерживаться для соответствия этой спецификации:

EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY

Любая система, включающая SMTP-сервер, поддерживающий ретрансляцию или доставку почты, ДОЛЖНА поддерживать зарезервированный почтовый ящик «postmaster» в качестве нечувствительного к регистру локального имени. Этот адрес администратора почты не является строго необходимым, если сервер всегда возвращает 554 при открытии соединения (как описано в разделе 3.1). Требование принимать почту для postmaster подразумевает, что команды RCPT, которые указывают почтовый ящик для postmaster в любом из доменов, для которых SMTP-сервер предоставляет почтовую службу, а также в особом случае «RCPT TO: <Postmaster>» (без домена) спецификация), ДОЛЖЕН поддерживаться.

Ожидается, что SMTP-системы приложат все разумные усилия, чтобы принимать почту, направляемую Postmaster, из любой другой системы в Интернете. В крайних случаях — например, для атаки типа «отказ в обслуживании» или другого нарушения безопасности — SMTP-сервер может блокировать почту, направляемую Postmaster. Однако такие схемы ДОЛЖНЫ быть узко приспособлены, чтобы избежать блокирования сообщений, которые не являются частью таких атак.

4.5.2 Прозрачность

Без некоторого обеспечения прозрачности данных последовательность символов «<CRLF>. <CRLF>» заканчивает текст письма и не может быть отправлен пользователем. Как правило, пользователи не знают о таких «запрещенных» последовательностях. Для обеспечения прозрачной передачи всего пользовательского текста используются следующие процедуры:

• Перед отправкой строки почтового текста SMTP-клиент проверяет первый символ строки. Если это период, один дополнительный период вставляется в начало строки.
• Когда SMTP-сервер получает строку почтового текста, он проверяет эту строку. Если строка состоит из одного периода, она рассматривается как индикатор конца письма. Если первый символ — точка, а в строке есть другие символы, первый символ удаляется.

Почтовые данные могут содержать любой из 128 символов ASCII. Все символы должны быть доставлены в почтовый ящик получателя, включая пробелы, вертикальные и горизонтальные вкладки и другие управляющие символы. Если канал передачи предоставляет 8-битный байтовый (октетный) поток данных, 7-битные коды ASCII передаются в октетах с выравниванием вправо, а биты старшего разряда очищаются до нуля. См. 3.7 для специальной обработки этих условий в системах SMTP, обслуживающих функцию реле.

В некоторых системах может потребоваться преобразовать данные по мере их получения и хранения. Это может быть необходимо для хостов, которые используют другой набор символов, нежели ASCII, в качестве своего локального набора символов, которые хранят данные в записях, а не в строках, или которые используют специальные последовательности символов в качестве разделителей внутри почтовых ящиков. Если такие преобразования необходимы, они ДОЛЖНЫ быть обратимыми, особенно если они применяются к пересылаемой почте.

4.5.3 Размеры и время ожидания

4.5.3.1 Размерные ограничения и минимумы

Есть несколько объектов, которые имеют минимальные / максимальные размеры. Каждая реализация ДОЛЖНА иметь возможность получать объекты как минимум этих размеров. По возможности следует избегать объектов, размер которых превышает эти размеры. Однако для некоторых почтовых конструкций Интернета, таких как закодированные адреса X.400 [16], часто требуются более крупные объекты: клиенты МОГУТ пытаться передавать их, но ДОЛЖНЫ быть готовы к тому, чтобы сервер отклонил их, если они не могут быть обработаны им. В максимально возможной степени должны использоваться методы реализации, которые не накладывают ограничений на длину этих объектов.

local-part (локальная часть). Максимальная общая длина имени пользователя или другой локальной части составляет 64 символа.

domain (домен). Максимальная общая длина доменного имени или номера составляет 255 символов.

path (путь). Максимальная общая длина обратного или прямого пути составляет 256 символов (включая знаки пунктуации и разделители элементов).

command line (командная строка). Максимальная общая длина командной строки, включая командное слово и <CRLF>, составляет 512 символов. Расширения SMTP могут использоваться для увеличения этого предела.

reply line (ответная строка). Максимальная общая длина строки ответа, включая код ответа и <CRLF>, составляет 512 символов. Больше информации может быть передано через многострочные ответы.

text line (текстовая строка). Максимальная общая длина текстовой строки, включая <CRLF>, составляет 1000 символов (не считая начальную точку, дублированную для прозрачности). Это число может быть увеличено за счет использования SMTP-сервисных расширений.

message content (содержание сообщения). Максимальная общая длина содержимого сообщения (включая заголовки и текст сообщения) ДОЛЖНА БЫТЬ не менее 64 КБ. Со времени введения стандартов Интернета для мультимедийной почты [12] длина сообщений в Интернете резко возросла, и следует избегать ограничений на размер сообщений, если это вообще возможно. Системам SMTP-серверов, которые должны налагать ограничения, СЛЕДУЕТ реализовывать расширение службы «SIZE» [18], а клиентским системам SMTP, которые будут отправлять большие сообщения, СЛЕДУЕТ использовать его, когда это возможно.

recipients buffer (буфер получателей). Минимальное общее количество получателей, которое должно быть буферизовано, составляет 100 получателей. Отклонение сообщений (для избыточных получателей) с менее чем 100 командами RCPT является нарушением этой спецификации. Общий принцип, согласно которому ретрансляторы SMTP-серверов НЕ ДОЛЖНЫ, а SMTP-серверы НЕ ДОЛЖНЫ выполнять тесты проверки заголовков сообщений, предполагают, что отклонение сообщения на основе общего числа получателей, указанных в полях заголовка, не рекомендуется. Сервер, который налагает ограничение на количество получателей, ДОЛЖЕН вести себя упорядоченно, например, отклонять дополнительные адреса сверх своего предела, а не молча отбрасывать ранее принятые адреса. Клиент, которому необходимо доставить сообщение, содержащее более 100 команд RCPT, ДОЛЖЕН быть готов к передаче в виде «кусков» из 100 получателей, если сервер отказывается принять более 100 получателей в одном сообщении.

Ошибки из-за превышения этих пределов могут сообщаться с использованием кодов ответа. Некоторые примеры кодов ответов:

500 линия слишком длинная.
или же
501 слишком длинный путь
или же
452 Слишком много получателей (см. Ниже)
или же
552 Слишком много почтовых данных.

RFC 821 [30] неправильно перечислил ошибку, когда SMTP-сервер исчерпал свой предел реализации для числа команд RCPT («слишком много получателей») как имеющий код ответа 552. Правильный код ответа для этого условия — 452. Клиенты ДОЛЖНЫ обрабатывать В этом случае код 552 является временным, а не постоянным, поэтому логика ниже работает.

Когда соответствующий SMTP-сервер сталкивается с этим условием, он имеет по крайней мере 100 успешных команд RCPT в своем буфере получателей. Если сервер сможет принять сообщение, то по крайней мере эти 100 адресов будут удалены из очереди клиента SMTP. Когда клиент пытается повторить передачу тех адресов, которые получили 452 ответа, как минимум 100 из них смогут поместиться в буфер получателей SMTP-сервера. Каждая попытка повторной передачи, которая способна доставить что-либо, сможет избавиться как минимум от 100 из этих получателей.

Если SMTP-сервер имеет предел реализации для числа команд RCPT, и этот предел исчерпан, он ДОЛЖЕН использовать код ответа 452 (но клиент ДОЛЖЕН быть также подготовлен для 552, как отмечено выше). Если на сервере настроено ограничение политики сайта в отношении количества команд RCPT, он МОЖЕТ использовать код ответа 5XX. Это было бы наиболее уместно, если ограничение политики предназначалось для применения, если общее число получателей для определенного тела сообщения было применено, даже если это тело сообщения было отправлено в нескольких почтовых транзакциях.

4.5.3.2 Тайм-ауты

Клиент SMTP ДОЛЖЕН предоставлять механизм тайм-аута. Он ДОЛЖЕН использовать тайм-ауты по команде, а не пытаться рассчитать время всей почтовой транзакции. Тайм-ауты ДОЛЖНЫ быть легко реконфигурируемыми, желательно без перекомпиляции кода SMTP. Чтобы реализовать это, таймер устанавливается для каждой команды SMTP и для каждого буфера передачи данных. Последнее означает, что общее время ожидания по своей сути пропорционально размеру сообщения.

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

Начальное сообщение 220: 5 минут

Клиентский процесс SMTP должен различать сбой TCP-соединения и задержку в получении начального приветствия 220. Многие SMTP-серверы принимают TCP-соединение, но задерживают доставку сообщения 220 до тех пор, пока загрузка их системы не позволит обрабатывать больше почты.

Команда MAIL: 5 минут

Команда RCPT: 5 минут

Более длительное время ожидания требуется, если обработка списков рассылки и псевдонимов не откладывается до тех пор, пока сообщение не будет принято.

Начало DATA: 2 минуты

Это в ожидании ответа «354 Start Input» на команду DATA.

Блок Data: 3 минуты

Это в ожидании завершения каждого вызова TCP SEND, передающего часть данных.

Прекращение DATA: 10 минут.

Это в ожидании ответа «250 OK». Когда получатель получает последний период, заканчивающий данные сообщения, он обычно выполняет обработку для доставки сообщения в почтовый ящик пользователя. Ложный тайм-аут на этом этапе будет очень расточительным и, как правило, приведет к доставке нескольких копий сообщения, поскольку оно было успешно отправлено и сервер принял на себя ответственность за доставку. См. Раздел 6.1 для дополнительного обсуждения.

SMTP-сервер ДОЛЖЕН иметь время ожидания не менее 5 минут, пока он ожидает следующую команду от отправителя.

4.5.4. Стратегии повтора

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

Любая стратегия очередей ДОЛЖНА включать тайм-ауты для всех действий для каждой команды. Стратегия очередей НЕ ДОЛЖНА отправлять сообщения об ошибках в ответ на сообщения об ошибках ни при каких обстоятельствах.

4.5.4.1 Стратегия отправки

Общая модель для SMTP-клиента — это один или несколько процессов, которые периодически пытаются передавать исходящую почту. В типичной системе программа, которая составляет сообщение, имеет некоторый метод для запроса немедленного внимания к новой части исходящей почты, в то время как почта, которая не может быть передана немедленно, ДОЛЖНА быть поставлена в очередь и периодически повторяться отправителем. Запись в почтовой очереди будет включать не только само сообщение, но и информацию о конверте.

Отправитель ДОЛЖЕН отложить повторную попытку конкретного пункта назначения после неудачной попытки. Как правило, интервал повторения ДОЛЖЕН составлять не менее 30 минут; однако более сложные и переменные стратегии будут полезны, когда SMTP-клиент может определить причину недоставки.

Повторные попытки продолжаются до тех пор, пока сообщение не будет передано или отправитель не сдастся; Время отказа должно быть не менее 4-5 дней. Параметры алгоритма повтора ДОЛЖНЫ быть настраиваемыми.

Клиент ДОЛЖЕН хранить список хостов, с которыми он не может связаться, и соответствующие тайм-ауты соединения, а не просто повторять попытки отправки почтовых сообщений в очереди.

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

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

Применение этого принципа во многих случаях может устранить необходимость в явной функции «отправить очереди сейчас», такой как ETRN [9].

Стратегия может быть дополнительно модифицирована в результате нескольких адресов на хост (см. Ниже), чтобы оптимизировать время доставки и использование ресурсов.

Клиент SMTP может иметь большую очередь сообщений для каждого недоступного хоста назначения. Если бы все эти сообщения были повторены в каждом цикле повторных попыток, это привело бы к чрезмерным накладным расходам в Интернете, и отправляющая система была бы заблокирована на длительный период. Обратите внимание, что SMTP-клиент, как правило, может определить, что попытка доставки не удалась только по истечении нескольких минут, и даже один минутный тайм-аут на соединение приведет к очень большой задержке, если повторные попытки повторяются для десятков или даже сотен очередей. сообщения на тот же хост.

В то же время SMTP-клиенты ДОЛЖНЫ проявлять большую осторожность при кэшировании отрицательных ответов от серверов. В крайнем случае, если EHLO выдается несколько раз во время одного и того же SMTP-соединения, сервер может вернуть разные ответы. Что еще более важно, 5yz ответы на команду MAIL НЕ ДОЛЖНЫ кэшироваться.

Когда почтовое сообщение должно быть доставлено нескольким получателям, и SMTP-сервер, на который должна быть отправлена копия сообщения, является одинаковым для нескольких получателей, тогда ДОЛЖНА быть передана только одна копия сообщения. То есть SMTP-клиент ДОЛЖЕН использовать последовательность команд: MAIL, RCPT, RCPT, … RCPT, DATA вместо последовательности: MAIL, RCPT, DATA, …, MAIL, RCPT, DATA. Однако, если адресов очень много, МОЖЕТ быть установлен предел на число команд RCPT на команду MAIL. Реализация этой функции эффективности настоятельно рекомендуется.

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

4.5.4.2. Получение стратегии

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

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

4.5.5 Сообщения с нулевым обратным путем

Существует несколько типов уведомительных сообщений, которые согласно существующим и предлагаемым стандартам должны отправляться с нулевым обратным путем, а именно уведомления о недоставке, как описано в разделе 3.7, другие виды уведомлений о состоянии доставки (DSN) [24], а также Уведомления о расположении сообщений (MDN) [10]. Все эти виды сообщений являются уведомлениями о предыдущем сообщении и отправляются по обратному пути к предыдущему почтовому сообщению. (Если доставка такого уведомления не удалась, это обычно указывает на проблему с почтовой системой хоста, которому адресовано сообщение уведомления. По этой причине на некоторых хостах MTA настроен на пересылку таких сообщений уведомления о сбое кто-то, кто может исправить проблемы с почтовой системой, например, с помощью псевдонима postmaster.)

Все другие типы сообщений (то есть любое сообщение, которое не требуется в RFC для отслеживания стандартов, имеет нулевой обратный путь), ДОЛЖНО отправляться с допустимым ненулевым обратным путем.

Разработчики автоматизированных процессоров электронной почты должны быть осторожны, чтобы убедиться, что различные виды сообщений с нулевым обратным путем обрабатываются правильно, в частности, такие системы НЕ ДОЛЖНЫ отвечать на сообщения с нулевым обратным путем.

5. Разрешение адресов и обработка почты

Как только SMTP-клиент лексически идентифицирует домен, в который будет доставляться почта для обработки (как описано в разделах 3.6 и 3.7), поиск DNS ДОЛЖЕН быть выполнен для разрешения имени домена [22]. Предполагается, что имена будут полностью определенными доменными именами (FQDN): механизмы вывода FQDN из частичных имен или локальных псевдонимов выходят за рамки этой спецификации и, как правило, из-за проблем не рекомендуются. Сначала поиск пытается найти запись MX, связанную с именем. Если вместо этого найдена запись CNAME, результирующее имя обрабатывается так, как если бы оно было начальным именем. Если записи MX не найдены, но A RR найден, A RR обрабатывается так, как если бы он был связан с неявным MX RR с предпочтением 0, указывающим на этот хост. Если для данного имени найдены один или несколько MX RR, системы SMTP НЕ ДОЛЖНЫ использовать какие-либо A RR, связанные с этим именем, если только они не расположены с использованием MX RR; вышеприведенное правило «неявного MX» применяется только в том случае, если отсутствуют записи MX. Если присутствуют записи MX, но ни одна из них не может быть использована, об этой ситуации ДОЛЖНО быть сообщено как ошибка.

При успешном поиске сопоставление может привести к появлению списка альтернативных адресов доставки, а не одного адреса, из-за нескольких записей MX, множественной адресации или обоих. Чтобы обеспечить надежную передачу почты, клиент SMTP ДОЛЖЕН иметь возможность попробовать (и повторить попытку) каждый из соответствующих адресов в этом списке по порядку, пока попытка доставки не будет успешной. Однако МОЖЕТ также быть настраиваемое ограничение на количество альтернативных адресов, которые можно попробовать. В любом случае SMTP-клиент ДОЛЖЕН попробовать как минимум два адреса.

Два типа информации используются для ранжирования адресов хостов: несколько записей MX и хосты с несколькими адресами.

Несколько записей MX содержат указание предпочтения, которое ДОЛЖНО использоваться при сортировке (см. Ниже). Более низкие числа более предпочтительны, чем более высокие. Если существует несколько получателей с одинаковыми предпочтениями и нет явных причин для предпочтения одного (например, путем распознавания легко достижимого адреса), то SMTP-отправитель ДОЛЖЕН рандомизировать их, чтобы распределить нагрузку по нескольким почтовым обменникам для конкретного организация.

Хост назначения (возможно, взятый из предпочтительной записи MX) может быть многосетевым, и в этом случае распознаватель доменного имени выдаст список альтернативных IP-адресов. Ответственность за упорядочение этого списка лежит на интерфейсе распознавателя доменных имен, уменьшая при необходимости предпочтения, и SMTP ДОЛЖЕН пробовать их в указанном порядке.

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

Если SMTP-сервер получает сообщение с адресатом, для которого он является назначенным почтовым отправителем, он МОЖЕТ ретранслировать сообщение (возможно, после перезаписи адресов MAIL FROM и / или RCPT TO), выполнить окончательную доставку сообщения или передать его отключить использование какого-либо механизма вне транспортной среды, предоставляемой SMTP. Конечно, ни один из последних не требует дальнейшего изучения списка записей MX.

Если он определяет, что должен ретранслировать сообщение, не переписывая адрес, он ДОЛЖЕН сортировать записи MX, чтобы определить кандидатов для доставки. Записи сначала упорядочены по предпочтению, при этом записи с наименьшим номером являются наиболее предпочтительными. Узел ретрансляции ДОЛЖЕН затем проверить список на наличие имен или адресов, по которым он может быть известен в почтовых транзакциях. Если совпадающая запись найдена, все записи на этом уровне предпочтения и записи с более высоким номером ДОЛЖНЫ быть исключены из рассмотрения. Если в этой точке не осталось записей, это является ошибкой, и сообщение ДОЛЖНО быть возвращено как недоставленное. Если записи остаются, они ДОЛЖНЫ быть опробованы, в первую очередь предпочтительнее, как описано выше.

6. Обнаружение и устранение проблем

6.1 Надежная доставка и ответы по электронной почте

Когда SMTP-получатель принимает кусок почты (отправляя сообщение «250 OK» в ответ на DATA), он принимает на себя ответственность за доставку или ретрансляцию сообщения. Он должен относиться к этой ответственности серьезно. Он НЕ ДОЛЖЕН терять сообщение по необоснованным причинам, например, из-за сбоя хоста или из-за предсказуемой нехватки ресурсов.

Если после принятия сообщения произойдет сбой доставки, получатель-SMTP ДОЛЖЕН сформулировать и отправить уведомление по почте. Это уведомление ДОЛЖНО быть отправлено с использованием нулевого (<> «) обратного пути в конверте. Получателем этого уведомления ДОЛЖЕН быть адрес из пути возврата конверта (или строки Return-Path:). Однако, если этот адрес нулевой («<>»), SMTP-получатель НЕ ДОЛЖЕН отправлять уведомление. Очевидно, что ничто в этом разделе не может или не должно запрещать локальным решениям (то есть, как часть той же системной среды, что и SMTP-приемник) регистрировать или иным образом передавать информацию о событиях с нулевым адресом локально, если это необходимо. Если адрес является явным исходным маршрутом, он ДОЛЖЕН быть сокращен до его последнего перехода.

Например, предположим, что уведомление об ошибке должно быть отправлено для сообщения, которое пришло с:

MAIL FROM:<@a,@b:user@d>

Уведомление ДОЛЖНО быть отправлено с использованием:

RCPT TO:<user@d>

Некоторые ошибки доставки после того, как сообщение будет принято SMTP, будут неизбежны. Например, для принимающего SMTP-сервера может оказаться невозможным проверить все адреса доставки в командах RCPT из-за «мягкой» системной ошибки домена, поскольку целью является список рассылки (см. Предыдущее обсуждение RCPT), или потому что сервер действует как ретранслятор и не имеет немедленного доступа к доставляющей системе.

Чтобы избежать получения повторяющихся сообщений в результате таймаутов, SMTP-получатель ДОЛЖЕН стремиться минимизировать время, необходимое для ответа на окончательный индикатор конца данных <CRLF>. <CRLF>. См. RFC 1047 [28] для обсуждения этой проблемы.

6.2 Обнаружение петли

Простой подсчет количества заголовков «Received:» в сообщении оказался эффективным, хотя и редко оптимальным, методом обнаружения петель в почтовых системах. SMTP-серверам, использующим эту технику, СЛЕДУЕТ использовать большой порог отклонения, обычно не менее 100 полученных записей. Какие бы механизмы ни использовались, серверы ДОЛЖНЫ содержать положения для обнаружения и остановки тривиальных циклов.

6.3 Компенсация за нарушения

К сожалению, вариации, творческие интерпретации и откровенные нарушения почтовых протоколов в Интернете все же случаются; некоторые предполагают, что они происходят довольно часто. Дискуссия о том, должен ли добросовестный SMTP-получатель или ретранслятор отклонять искаженное сообщение, пытаться передать его без изменений или пытаться исправить его, чтобы увеличить шансы на успешную доставку (или последующий ответ), начался почти с рассветом структурированной сетевой почты. и не показывает никаких признаков ослабления. Сторонники отклонения утверждают, что попытки ремонта редко бывают полностью адекватными и что отказ от плохих сообщений — единственный способ починить нарушающее программное обеспечение. Сторонники «ремонта» или «доставки независимо от того, что» утверждают, что пользователи предпочитают, чтобы почта проходила через нее, если это вообще было возможно, и что в этом направлении существует значительное давление на рынке. На практике это давление рынка может быть более важным для конкретных поставщиков, чем строгое соответствие стандартам, независимо от предпочтений реальных разработчиков.

Проблемы, связанные с плохо сформированными сообщениями, усугубились введением протоколов чтения почты split-UA [3, 26, 5, 21]. Эти протоколы поощряют использование SMTP в качестве протокола регистрации и SMTP-серверов в качестве систем ретрансляции для этих клиентских хостов (которые часто только периодически подключаются к Интернету). Исторически, многим из этих клиентских машин не хватало некоторых механизмов и информации, предполагаемых SMTP (и действительно, протоколом почтового формата [7]). Некоторые не могли следить за временем; другие не имели понятия о часовых поясах; третьи не могли идентифицировать свои собственные имена или адреса; и, конечно, никто не мог удовлетворить предположения, которые лежат в основе концепции аутентифицированных адресов в RFC 822.

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

Следующие изменения в обрабатываемом сообщении МОГУТ быть применены при необходимости исходным SMTP-сервером или тем, который используется в качестве целевого SMTP-сервера в качестве исходного протокола публикации:

• Добавление поля идентификатора сообщения, когда ничего не появляется
• Добавление даты, времени или часового пояса, когда ни один не появляется
• Исправление адресов в правильном формате FQDN

Чем меньше информации о клиенте имеет сервер, тем меньше вероятность того, что эти изменения будут правильными, и тем больше осторожности и консерватизма следует применять при рассмотрении вопроса о том, следует ли выполнять исправления и каким образом. Эти изменения НЕ ДОЛЖНЫ применяться SMTP-сервером, который обеспечивает промежуточную функцию ретрансляции.

Во всех случаях правильно работающие клиенты, предоставляющие правильную информацию, предпочитаются SMTP-серверу для исправлений. Во всех случаях настоятельно рекомендуется документировать действия, выполняемые серверами (в полях трассировки и / или комментариях к заголовкам).

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

7.1 Безопасность почты и спуфинг

Почта SMTP по своей природе небезопасна, поскольку даже довольно случайные пользователи могут напрямую договариваться с получающими и ретранслирующими SMTP-серверами и создавать сообщения, которые заставят наивного получателя поверить, что они пришли откуда-то еще. Построить такое сообщение так, чтобы эксперт не мог обнаружить «поддельное» поведение, несколько сложнее, но недостаточно, чтобы быть сдерживающим фактором для того, кто решителен и осведомлен. Следовательно, с ростом знаний об электронной почте в интернете растет и тот факт, что SMTP-почта по своей сути не может быть аутентифицирована или предоставлена проверка целостности на транспортном уровне. Реальная защита почты заключается только в сквозных методах, включающих тела сообщений, таких как те, которые используют цифровые подписи (см. [14] и, например, PGP [4] или S / MIME [31]).

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

Усилия, направленные на то, чтобы пользователям было сложнее установить путь возврата конверта и поля заголовка «От» для указания на действительные адреса, отличные от их собственных, в значительной степени ошибочны: они расстраивают легитимные приложения, в которых почта отправляется одним пользователем от имени другого или в какие ответы об ошибках (или нормальные) должны быть направлены на специальный адрес. (Системы, которые предоставляют пользователям удобные способы изменения этих полей для каждого сообщения, должны пытаться установить для пользователя основной и постоянный адрес почтового ящика, чтобы поля Sender в данных сообщения могли быть сгенерированы разумно.)

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

7.2 «Слепые» копии

Адреса, которые не отображаются в заголовках сообщений, могут появляться в командах RCPT на SMTP-сервере по ряду причин. Два наиболее распространенных включают использование почтового адреса в качестве «списка рассылки» (один адрес, который преобразуется в несколько адресов) и появление «слепых копий». Особенно, когда присутствует более одной команды RCPT, и чтобы избежать поражения некоторых целей этих механизмов, SMTP-клиентам и серверам НЕ СЛЕДУЕТ копировать полный набор аргументов команды RCPT в заголовки, либо как часть заголовков трассировки, либо как заголовки информационных или частных расширений. Поскольку это правило часто нарушается на практике и не может быть применено, отправка SMTP-систем, которые знают об использовании «bcc», МОЖЕТ найти полезным отправлять каждую слепую копию как отдельную транзакцию сообщения, содержащую только одну команду RCPT.

В транзакции SMTP («конверт») и адресах в заголовках нет внутренней связи между «обратными» (из команд MAIL, SAML и т. Д., Командами) или «прямыми» (RCPT) адресами. Приемным системам НЕ СЛЕДУЕТ пытаться вывести такие отношения и использовать их для изменения заголовков сообщения для доставки. Популярный заголовок «Видимо для» является нарушением этого принципа, а также общим источником непреднамеренного раскрытия информации и НЕ ДОЛЖЕН использоваться.

7.3 VRFY, EXPN и безопасность

Как обсуждалось в разделе 3.5, отдельные сайты могут хотеть отключить один или оба из VRFY или EXPN по соображениям безопасности. Как следствие вышесказанного, реализации, которые позволяют это, НЕ ДОЛЖНЫ иметь проверенные адреса, которые на самом деле не проверены. Если сайт отключает эти команды по соображениям безопасности, SMTP-сервер ДОЛЖЕН вернуть ответ 252, а не код, который можно спутать с успешной или неудачной проверкой.

Возвращение кода ответа 250 с адресом, указанным в команде VRFY после проверки его только на синтаксис, нарушает это правило. Конечно, реализация, которая «поддерживает» VRFY, всегда возвращая 550 независимо от того, является ли адрес действительным, также не соответствует.

За последние несколько лет содержимое списков рассылки стало популярным в качестве источника адресной информации для так называемых «спаммеров». Использование EXPN для «сбора» адресов расширилось, поскольку администраторы списков установили защиту от нецелевого использования самих списков. Реализации ДОЛЖНЫ по-прежнему обеспечивать поддержку EXPN, но сайты ДОЛЖНЫ тщательно оценивать компромиссы. Поскольку механизмы аутентификации введены в SMTP, некоторые сайты могут сделать EXPN доступным только для аутентифицированных запросчиков.

7.4 Раскрытие информации в объявлениях

Продолжаются дебаты о компромиссах между преимуществами отладки объявления типа и версии сервера (и иногда даже доменного имени сервера) в ответном приветствии или в ответ на команду HELP и недостатками раскрытия информации, которая может быть полезна в потенциальной враждебной атаке. Полезность отладочной информации не вызывает сомнений. Те, кто настаивает на том, чтобы сделать его доступным, отмечают, что гораздо лучше на самом деле защитить SMTP-сервер, чем надеяться, что попытка скрыть известные уязвимости, скрывая точную идентификацию сервера, обеспечит большую защиту. Участкам рекомендуется оценивать компромисс с учетом этой проблемы; Реализациям настоятельно рекомендуется минимально предоставлять информацию о типе и версии, доступную каким-либо образом для других сетевых хостов.

7.5 Раскрытие информации в полях трассировки

В некоторых случаях, например, когда почта отправляется из локальной сети, чьи хосты не находятся непосредственно в общедоступном Интернете, поля трассировки («полученные»), созданные в соответствии с этой спецификацией, могут раскрывать имена хостов и аналогичную информацию, которая обычно недоступна. Обычно это не представляет проблемы, но сайты с особыми опасениями относительно раскрытия имени должны знать об этом. Кроме того, необязательное предложение FOR следует вводить с осторожностью или вообще не указывать, если в нем участвуют несколько получателей, чтобы оно случайно не раскрыло личности получателей «слепой копии» другим.

7.6 Раскрытие информации при пересылке сообщений

Как обсуждалось в разделе 3.4, использование кодов ответа 251 или 551 для идентификации замещающего адреса, связанного с почтовым ящиком, может непреднамеренно раскрыть конфиденциальную информацию. Сайты, которые обеспокоены этими проблемами, должны гарантировать, что они выбирают и настраивают серверы соответствующим образом.

7.7 Объем работы SMTP-серверов

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

В последние годы использование функции ретрансляции через произвольные сайты использовалось как часть враждебных попыток скрыть фактическое происхождение почты. Некоторые сайты решили ограничить использование функции ретрансляции известными или идентифицируемыми источниками, и реализации ДОЛЖНЫ предоставлять возможность выполнять этот тип фильтрации. Когда почта отклоняется по тем или иным причинам политики, в ответ на EHLO, MAIL или RCPT СЛЕДУЕТ использовать код 550.

 

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

IANA будет поддерживать три реестра в поддержку этой спецификации. Первый состоит из расширений службы SMTP со связанными ключевыми словами и, при необходимости, параметров и глаголов. Как указано в разделе 2.2.2, в этот реестр нельзя вносить записи, начинающиеся с «X». Записи могут быть сделаны только для расширений услуг (и связанных ключевых слов, параметров или глаголов), которые определены в стандарте или экспериментальных RFC, специально одобренных IESG для этой цели.

Второй реестр состоит из «тегов», которые идентифицируют формы литералов домена, отличных от форм для адресов IPv4 (указанных в RFC 821 и в этом документе) и адресов IPv6 (указанных в этом документе). Дополнительные литеральные типы требуют стандартизации перед использованием; никто не ожидается в это время.

Третий, созданный в RFC 821 и обновленный в соответствии с этой спецификацией, представляет собой реестр идентификаторов каналов и протоколов, которые должны использоваться с подпунктами «через» и «с» метки времени («Получено: заголовок»), описанной в разделе 4.4. Идентификаторы ссылок и протоколов в дополнение к указанным в этом документе могут быть зарегистрированы только путем стандартизации или посредством документально подтвержденного RFC, одобренного IESG расширения экспериментального протокола.

 

9. Ссылки

[1] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, «USA Code for Information Interchange». ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.

[2] Braden, R., «Requirements for Internet hosts — application and support», STD 3, RFC 1123, October 1989.

[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, «Post Office Protocol — version 2», RFC 937, February 1985.

[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, «OpenPGP Message Format», RFC 2440, November 1998.

[5] Crispin, M., «Interactive Mail Access Protocol — Version 2», RFC 1176, August 1990.

[6] Crispin, M., «Internet Message Access Protocol — Version 4», RFC 2060, December 1996.

[7] Crocker, D., «Standard for the Format of ARPA Internet Text Messages», RFC 822, August 1982.

[8] Crocker, D. and P. Overell, Eds., «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[9] De Winter, J., «SMTP Service Extension for Remote Message Queue Starting», RFC 1985, August 1996.

[10] Fajman, R., «An Extensible Message Format for Message Disposition Notifications», RFC 2298, March 1998.

[11] Freed, N, «Behavior of and Requirements for Internet Firewalls», RFC 2979, October 2000.

[12] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, December 1996.

[13] Freed, N., «SMTP Service Extension for Command Pipelining», RFC 2920, September 2000.

[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, «Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted», RFC 1847, October 1995.

[15] Gellens, R. and J. Klensin, «Message Submission», RFC 2476, December 1998.

[16] Kille, S., «Mapping between X.400 and RFC822/MIME», RFC 2156, January 1998.

[17] Hinden, R and S. Deering, Eds. «IP Version 6 Addressing Architecture», RFC 2373, July 1998.

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

[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, «SMTP Service Extensions», STD 10, RFC 1869, November 1995.

[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, «SMTP Service Extension for 8bit-MIMEtransport», RFC 1652, July 1994.

[21] Lambert, M., «PCMAIL: A distributed mail system for personal computers», RFC 1056, July 1988.

[22] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987. Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[23] Moore, K., «MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text», RFC 2047, December 1996.

[24] Moore, K., «SMTP Service Extension for Delivery Status Notifications», RFC 1891, January 1996.

[25] Moore, K., and G. Vaudreuil, «An Extensible Message Format for Delivery Status Notifications», RFC 1894, January 1996.

[26] Myers, J. and M. Rose, «Post Office Protocol — Version 3», STD 53, RFC 1939, May 1996.

[27] Partridge, C., «Mail routing and the domain system», RFC 974, January 1986.

[28] Partridge, C., «Duplicate messages and SMTP», RFC 1047, February 1988.

[29] Postel, J., ed., «Transmission Control Protocol — DARPA Internet Program Protocol Specification», STD 7, RFC 793, September 1981.

[30] Postel, J., «Simple Mail Transfer Protocol», RFC 821, August 1982.

[31] Ramsdell, B., Ed., «S/MIME Version 3 Message Specification», RFC 2633, June 1999.

[32] Resnick, P., Ed., «Internet Message Format», RFC 2822, April 2001.

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

[34] Vaudreuil, G., «Enhanced Mail System Status Codes», RFC 1893, January 1996.

10. Адрес редактора

John C. Klensin
AT&T Laboratories
99 Bedford St

Boston, MA 02111 USA

Phone: 617-574-3076
EMail: klensin@research.att.com

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

Многие люди долго и усердно работали над многими итерациями этого документа. В Рабочей группе IETF DRUMS состоялись широкие дискуссии, как по списку рассылки, так и по очным дискуссиям, по многим техническим вопросам и роли пересмотренного стандарта для транспортировки почты в Интернете, и многие участники помогли сформировать формулировку в этой Спецификация. Сотни участников многих дискуссий с момента выпуска RFC 821 слишком многочисленны, чтобы упоминать их, но все они помогли этому документу стать тем, чем он является.

Приложения

A. Транспортная служба TCP

Соединение TCP поддерживает передачу 8-битных байтов. Данные SMTP — это 7-битные символы ASCII. Каждый символ передается в виде 8-битного байта, причем старший бит сбрасывается в ноль. Расширения службы могут изменить это правило, чтобы разрешить передачу полных 8-битных байтов данных как части тела сообщения, но не в командах или ответах SMTP.

B. Генерация SMTP-команд из заголовков RFC 822

Некоторые системы используют заголовки RFC 822 (только) в протоколе отправки почты или иным образом генерируют команды SMTP из заголовков RFC 822, когда такое сообщение передается в адаптер MTA из UA. Хотя протокол MTA-UA является частным делом, не охваченным каким-либо Интернет-стандартом, с этим подходом есть проблемы. Например, неоднократно возникали проблемы с правильной обработкой копий «bcc» и списков перераспределения, когда информация, которая концептуально принадлежит почтовым конвертам, не отделялась на раннем этапе обработки от информации заголовка (и хранилась отдельно).

Рекомендуется, чтобы UA предоставил своему начальному («клиенту представления») MTA конверт, отдельный от самого сообщения. Однако, если конверт не указан, команды SMTP ДОЛЖНЫ быть сгенерированы следующим образом:

1. Каждый адрес получателя из поля заголовка TO, CC или BCC ДОЛЖЕН быть скопирован в команду RCPT (создание нескольких копий сообщений, если это требуется для постановки в очередь или доставки). Это включает любые адреса, перечисленные в «группе» RFC 822. Любые поля BCC ДОЛЖНЫ быть затем удалены из заголовков. После завершения этого процесса ДОЛЖНЫ проверяться оставшиеся заголовки, чтобы убедиться, что остался хотя бы один заголовок To :, Cc: или Bcc :. Если этого не происходит, то заголовок bcc: без дополнительной информации ДОЛЖЕН быть вставлен, как указано в [32].
2. Адрес возврата в команде MAIL ДОЛЖЕН, если возможно, быть получен из системного идентификатора отправляющего (локального) пользователя и поля заголовка «From:» в противном случае. Если имеется системный идентификатор, он ДОЛЖЕН также быть скопирован в поле заголовка отправителя, если он отличается от адреса в поле заголовка «От». (Любое поле Отправителя, которое уже было там, ДОЛЖНО быть удалено.) Системы могут предоставить отправителям возможность переопределить обратный адрес конверта, но могут захотеть ограничить его использование привилегированными пользователями. Это не предотвратит подделку почты, но может уменьшить ее частоту; см. раздел 7.1.

Когда MTA используется таким образом, он несет ответственность за обеспечение достоверности передаваемого сообщения. Механизмы для проверки этой достоверности и для обработки (или возврата) сообщений, которые не действительны во время прибытия, являются частью интерфейса MUA-MTA и не охватываются настоящей спецификацией.

Протокол передачи, основанный только на стандартной информации RFC 822, НЕ ДОЛЖЕН использоваться для передачи сообщения из чужой (не SMTP) почтовой системы в среду SMTP. Дополнительная информация для создания конверта должна поступать из какого-либо источника в другой среде, будь то дополнительные заголовки или конверт сторонней системы.

Попытки шлюзовать сообщения, используя только их заголовочные поля «to» и «cc», неоднократно вызывали зацикливание почты и другое поведение, препятствующее надлежащему функционированию почтовой среды Интернета. Эти проблемы были особенно распространены, когда сообщение исходит из списка рассылки в Интернете и распространяется во внешнюю среду с использованием информации конверта. Когда эти сообщения затем обрабатываются отправителем только в заголовке, возврат к среде Интернет (и списку рассылки) практически неизбежен.

C. Исходные маршруты

Исторически <обратный путь> был списком маршрутизации хостов с обратным источником и почтовым ящиком источника. Первый хост в <reverse-path> ДОЛЖЕН быть хостом, отправляющим команду MAIL. Точно так же <forward-path> может быть исходной списком маршрутизации хостов и почтовым ящиком назначения. Однако в общем случае <forward-path> ДОЛЖЕН содержать только почтовый ящик и доменное имя, полагаясь на систему доменных имен для предоставления информации о маршрутизации, если это необходимо. Использование исходных маршрутов не рекомендуется; в то время как серверы ДОЛЖНЫ быть готовы принимать и обрабатывать их, как описано в разделах 3.3 и F.2, клиенты НЕ ДОЛЖНЫ передавать их, и этот раздел был включен только для обеспечения контекста.

В целях ретрансляции прямой путь может быть исходным маршрутом в форме «@ ONE, @ TWO: JOE @ THREE», где ONE, TWO и THREE ДОЛЖНЫ БЫТЬ полностью квалифицированными доменными именами. Эта форма используется, чтобы подчеркнуть различие между адресом и маршрутом. Почтовый ящик является абсолютным адресом, а маршрут — это информация о том, как туда добраться. Эти два понятия не следует путать.

Если используются исходные маршруты, следует обратиться к RFC 821 и тексту ниже, чтобы узнать о механизмах построения и обновления прямого и обратного путей.

SMTP-сервер преобразует аргументы команды путем перемещения своего собственного идентификатора (своего доменного имени или имени любого домена, для которого он выступает в качестве почтового обменника), если он появляется, из прямого пути в начало обратного пути.

Обратите внимание, что прямой и обратный путь появляются в командах и ответах SMTP, но не обязательно в сообщении. То есть нет необходимости, чтобы эти пути и особенно этот синтаксис появлялись в полях «Кому:», «От:», «CC:» и т. Д. Заголовка сообщения. И наоборот, SMTP-серверы НЕ ДОЛЖНЫ получать окончательную информацию о доставке сообщения из полей заголовка сообщения.

Когда список хостов присутствует, он является «обратным» исходным маршрутом и указывает, что почта была ретранслирована через каждый хост в списке (первый хост в списке был самым последним ретранслятором). Этот список используется в качестве исходного маршрута для возврата уведомлений о недоставке отправителю. Поскольку каждый узел ретрансляции добавляет себя в начало списка, он ДОЛЖЕН использовать свое имя, известное в транспортной среде, в которую он ретранслирует почту, а не в транспортной среде, из которой пришла почта (если они отличаются).

D. Сценарии

В этом разделе представлены полные сценарии нескольких типов сеансов SMTP. В примерах «C:» указывает, что говорит SMTP-клиент, а «S:» указывает, что говорит SMTP-сервер.

D.1 Типичный сценарий транзакции SMTP

В этом примере SMTP показана почта, отправленная Смитом с хоста bar.com, Джонсу, Грину и Брауну с хоста foo.com. Здесь мы предполагаем, что хост bar.com напрямую связывается с хостом foo.com. Почта принимается за Джонс и Браун. У Грина нет почтового ящика на хосте foo.com.

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>

S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah…
C: …etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.2 Прерванный сценарий транзакции SMTP

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.3 Сценарий ретранслированной почты

Шаг 1 — Исходный хост для ретрансляции хоста

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700

C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

Шаг 2 — ретрансляция хоста на хост назначения

S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.4 Проверка и отправка сценария

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN

S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: SEND FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah…
C: …etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

E. Другие проблемы шлюза

В общем, шлюзы между Интернетом и другими почтовыми системами ДОЛЖНЫ пытаться сохранить любую семантику многоуровневой пересекающей границы между двумя задействованными почтовыми системами. Подходы GatewayTranslation, которые пытаются использовать ярлыки путем сопоставления (например, информация конверта из одной системы в заголовки сообщений или тело другой), как правило, оказываются неадекватными в важных отношениях. Системы, переводящие между средами, которые не поддерживают как конверты, так и заголовки и электронную почту, должны быть написаны с пониманием, что некоторая потеря информации почти неизбежна.

F. Устаревшие функции RFC 821

Некоторые функции RFC 821 оказались проблематичными и НЕ ДОЛЖНЫ использоваться в Интернет-почте.

F.1 TURN

Эта команда, описанная в RFC 821, поднимает важные проблемы безопасности, поскольку в отсутствие строгой аутентификации хоста, запрашивающего переключение ролей клиента и сервера, ее можно легко использовать для перенаправления почты из ее правильного места назначения. Его использование устарело; Системам SMTP НЕ СЛЕДУЕТ использовать его, если сервер не может аутентифицировать клиента.

F.2 Source Routing

RFC 821 использовал концепцию явной маршрутизации от источника для получения почты от одного хоста к другому через серию ретрансляторов. Требование использования исходных маршрутов в обычном почтовом трафике было устранено введением записи системы доменных имен «MX», а последнее существенное обоснование для них было устранено введением в RFC 1123 четкого требования, касающегося «после». @ «должны быть полностью квалифицированными доменными именами. Следовательно, единственным оставшимся оправданием использования исходных маршрутов является поддержка очень старых SMTP-клиентов или MUA и отладка почтовой системы. Однако они могут быть полезны в последнем случае и для маршрутизации почты вокруг серьезных, но временных проблем, таких как проблемы с соответствующими записями DNS.

SMTP-серверы ДОЛЖНЫ продолжать принимать синтаксис исходного маршрута, как указано в основном тексте этого документа и в RFC 1123. Они МОГУТ при необходимости игнорировать маршруты и использовать только целевой домен в адресе. Если они действительно используют исходный маршрут, сообщение ДОЛЖНО быть отправлено в первый домен, указанный в адресе. В частности, сервер НЕ ДОЛЖЕН угадывать ярлыки в исходном маршруте.

Клиенты НЕ ДОЛЖНЫ использовать явную маршрутизацию источника, за исключением необычных обстоятельств, таких как отладка или возможная ретрансляция ошибок межсетевого экрана или почтовой системы.

F.3 HELO

Как обсуждалось в разделах 3.1 и 4.1.1, EHLO настоятельно предпочтительнее HELO, когда сервер примет первый. Серверы должны продолжать принимать и обрабатывать HELO для поддержки старых клиентов.

F.4 #-literals

В RFC 821 предусмотрено указание интернет-адреса в виде десятичного целого номера хоста с префиксом знака решетки «#». На практике эта форма устарела с момента появления протокола TCP / IP. Это устарело и НЕ ДОЛЖНО использоваться.

F.5 Dates and Years

Когда даты вставляются в сообщения клиентами или серверами SMTP (например, в полях трассировки), ДОЛЖНЫ использоваться четырехзначные годы. Двузначные годы устарели; трехзначные годы никогда не были разрешены в почтовой системе Интернета.

F.6 Sending versus Mailing

Помимо указания механизма доставки сообщений в почтовые ящики пользователя, RFC 821 предоставил дополнительные, необязательные команды для доставки сообщений непосредственно на экран терминала пользователя. Эти команды (SEND, SAML, SOML) применялись редко, а изменения в технологии рабочих станций и внедрение других протоколов могли сделать их устаревшими даже там, где они реализованы.

Клиенты НЕ ДОЛЖНЫ предоставлять SEND, SAML или SOML в качестве услуг. Серверы МОГУТ их реализовать. Если они реализованы серверами, модель реализации, указанная в RFC 821, ДОЛЖНА использоваться, а имена команд ДОЛЖНЫ быть опубликованы в ответ на команду EHLO.

Заявление об авторском праве

Copyright (C) Интернет-общество (2001). Все права защищены.

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

Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут отменены Обществом Интернета или его правопреемниками или правопреемниками.

Этот документ и информация, содержащаяся в настоящем документе, предоставляются на условиях «КАК ЕСТЬ», и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖЕНЕРНАЯ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО ОГРАНИЧИВАЕТСЯ НИКАКИХ ГАРАНТИЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШИТЬ ЛЮБЫЕ ПРАВА ИЛИ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

Подтверждение

Финансирование функции RFC Editor в настоящее время обеспечивается Обществом Интернета.