RFC 2821: Протокол SMTP

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

• Исходная спецификация SMTP (Simple Mail Transfer Protocol) — RFC 821 [30],
• Требования к системе доменных имен и ее использованию для передачи электронной почты — RFC 1035 [22] и RFC 974 [27],
• Пояснения и вопросы применимости RFC 1123 [2],
• Механизмы SMTP Extension [19].

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

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

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

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

Задачей протокола SMTP (Simple Mail Transfer Protocol — простой протокол передачи электронной почты) является надежная и эффективная доставка сообщений электронной почты.
Протокол SMTP не связан с конкретными подсистемами передачи и требует только надежных каналов передачи потока данных с сохранением порядка. Хотя этот документ обсуждает вопросы доставки применительно к протоколу TCP,
возможно использование иного транспорта. Некоторые из альтернативных вариантов рассмотрены в приложениях к RFC 821.

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

Таким путем почтовые сообщения можно передавать через множество промежуточных трансляторов (relay) или шлюзов на пути между отправителем и конечным адресатом. Для определения следующего «промежуточного получателя1» (next- hop) на пути к адресату используется механизм Mail eXchanger (MX) системы доменных имен (DNS) [22, 27], рассмотренный в главе 5.

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

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

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

Сервер SMTP может быть конечным или промежуточным транслятором2 (relay) или шлюзом3 (gateway). Команды SMTP генерируются и передаются серверу SMTP. Сервер SMTP передает отклики в ответ на команды клиента SMTP. Иными словами, передача сообщения может осуществляться в один прием путем соединения исходного отправителя SMTP с конечным получателем SMTP или через цепочку промежуточных систем. В любом случае протокол требует от сервера доставить сообщение адресату или предоставить отчет о невозможности доставки.

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

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

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

Как сказано выше, протокол обеспечивает механизм передачи электронной почты. Эта передача обычно осуществляется непосредственно с хоста отправителя на хост получателя, когда оба хоста используют один транспортный сервис. Если же хосты подключены к разным системам транспортного сервиса, передача осуществляется с использованием одного или нескольких промежуточных серверов SMTP. Промежуточные хосты в таких случаях действуют как трансляторы (SMTP relay) или шлюзы в другие среды передачи и выбираются обычно с использованием MX-записей DNS (служба доменных имен). В некоторых случаях, однако, используется явное задание маршрута отправителем (см. главу 5 и приложения C, F.2).

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

Современные реализации SMTP должны поддерживать базовые механизмы расширения. Например, сервер должен поддерживать команды EHLO, даже если в нем не реализовано соответствующее расширение, а клиентам рекомендуется использовать команду EHLO вместо HELO4. В тех случаях, когда для интероперабельности не требуется явное использование HELO, настоящая спецификация всегда рассматривает только EHLO.

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

• Команда EHLO взамен прежней команды HELO;
• Реестр расширений сервиса SMTP;
• Дополнительные параметры команд MAIL и RCPT;
• Возможность замены команд, определенных в данном протоколе (таких, как DATA) при передаче символов, отличных от ASCII [33].

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

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

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

Кроме того, все ключевые значения EHLO, начинающиеся с X или x, указывающие на локальные расширения сервиса SMTP, используются на основе двухсторонних соглашений. Ключевые слова, начинающиеся с X (независимо от регистра) не могут использоваться в регистрируемых расширениях сервиса. И наоборот, ключевые значения, представляемые в отклике EHLO, который не начинается с X, должны соответствовать стандарту, предложенному стандарту или одобренному IESG экспериментальному расширению SMTP, зарегистрированному IANA. Для соответствующих требованиям стандарта серверов недопустимо предлагать начинающиеся с отличных от X символов расширения сервиса, если они не зарегистрированы.

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

Ключевые слова MUST (необходимо), MUST NOT (недопустимо), REQUIRED (требуется), SHALL (должно), SHALL NOT (не должно), SHOULD (следует), SHOULD NOT (не следует), RECOMMENDED (рекомендуется), MAY (возможно), OPTIONAL (необязательно) в данном документе трактуются следующим образом:

1. MUST — необходимо
Это слово, а также термины требуется (REQUIRED) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

2. MUST NOT — недопустимо
Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

3. SHOULD — следует
Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

4. SHOULD NOT — не следует
Эта фраза и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

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

Протокол SMTP обеспечивает транспортировку объектов электронной почты. Каждый объект состоит из конверта (envelope) и содержимого.

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

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

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

В данной спецификации используется современная терминология, устоявшаяся с момента публикации RFC 821. А В частности, клиенты и серверы SMTP обеспечивают почтовый транспортный сервис и называются «агентами доставки почты" - АДП (Mail Transfer Agent или MTA). Пользовательские почтовые агенты — ППА (Mail User Agent, MUA или UA) выступают в качестве исходных отправителей и конечных получателей почтовых сообщений.

На стороне отправителя ППА может собирать почту от пользователя для передачи ее АДП; агент ППА на стороне получателя передает почту ППА (по крайней мере, передает этому агенту ответственность за доставку почты; например, помещая ее в «почтовое хранилище» — message store). Однако, хотя эти термины и достаточно точно выражают суть и применимы к другим средам, границы между ППА (MUA) и АДП (MTA) определены недостаточно четко. Следовательно, читатель должен внимательно относиться к терминологии.

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

Домен (доменное имя) состоит из одной или нескольких разделенных точками компонент. В контексте SMTP эти компоненты (метки в терминах DNS [22]) могут содержать только последовательности букв5, цифр, дефиса (-) и знака подчеркивания (_) из набора символов ASCII [1]. Доменные имена используются для обозначения хостов и других объектов иерархии доменных имен.

Например, доменное имя может указывать на псевдоним (метка CNAME RR) или метку записи MX (Mail exchanger), которая будет использоваться для доставки почты вместо представленного имени хоста. Дополнительные сведения о доменных именах можно найти в работе [22] и главе 5 данной спецификации.

Доменное имя, как описано в данном документе и работе [22], представляет собой полное имя (fully-qualified domain name или FQDN). Доменные имена, не являющиеся FQDN, есть ни что иное, как локальные псевдонимы. В транзакциях SMTP появление локальных псевдонимов недопустимо.

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

Команды SMTP и (если расширение сервиса не задает иного) данные сообщений передаются как строки (line). Строка состоит из некоторого (возможно, нулевого) числа символов данных и завершается символами ASCII для возврата каретки (CR — 0Dh) и перевода строки (LF — 0Ah). Последовательность завершения строки в документе будет обозначаться <CRLF>. Для реализаций, которые соответствуют требованиям данной спецификации, недопустимо принимать или генерировать для завершения строки любые другие последовательности символов. Серверы могут вносить ограничения на длину строк (см. параграф 4.5.3).

В дополнение отметим, что использование в тексте отдельных символов CR или LF (не в комбинации <CRLF>) имеет долгую историю проблем в реализациях почтовых систем и приложениях, работающих с электронной почтой. Для клиентов SMTP недопустима передача этих символов за исключением тех случаев, когда комбинация символов служит для завершения строки, а в этом случае должна применяться только стандартная последовательность <CRLF>.

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

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

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

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

Адрес обычно состоит из пользовательской и доменной части. Стандартные соглашения об именах почтовых ящиков предполагают использование формата local — part @ domain — современная терминология поддерживает значительно более широкий спектр применений, нежели просто имена пользователей.

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

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

Команды и отклики SMTP подчиняются жестким синтаксическим правилам. Все команды начинаются с «командного глагола" (command verb), а все отклики — с 3-значного цифрового кода. В некоторых командах и откликах за командой или кодом должны следовать аргументы. Некоторые команды не принимают аргументов (после названия команды), а за некоторыми кодами откликов может следовать произвольный текст. Во всех случаях присутствия текста он отделяется от команды или кода символом пробела. Полные описания команд и откликов приведены в главе 4.

Регистр символов в командах и значениях аргументов не имеет значения (т. е., TO: и to: в команде RCPT не различаются), однако это правило имеет исключения для локальной части названия почтового ящика (расширения SMTP могут явно указывать чувствительные к регистру символов элементы). Названия команд, значения аргументов (кроме локальной части имени почтового ящика) и свободный текст может содержать произвольную комбинацию символов верхнего и нижнего регистра. Для локальной части имен почтовых ящиков регистр символов должен приниматься во внимание. Следовательно, реализации SMTP должны пытаться сохранить регистр символов в локальной части имени почтового ящика. В частности, для некоторых хостов пользователь smith может отличаться от пользователя Smith.
Однако, использование чувствительных к регистру локальных частей в именах почтовых ящиков снижает уровень интероперабельности — следует избегать такого применения локальных имен.

Некоторые серверы SMTP в нарушение данной спецификации (и RFC 821) требуют от клиентов представления команд в верхнем регистре (заглавные буквы). В реализации серверов могут приниматься меры для представления команд в соответствии с требованиями таких серверов.
Поле аргументов содержит текстовую строку переменной длины, заканчивающуюся символами <CRLF>. Принимающая сторона не будет предпринимать никаких действий до получения стандартного завершения строки.

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

Если в нарушение этого правила такое сообщение передается, принимающий сервер SMTP может сбросить старший бит или отвергнуть сообщение как некорректное. В общем случае транслятору SMTP рекомендуется предполагать, что содержимое принятого сообщения корректно и, предполагая, что конверт позволяет это сделать, транслировать сообщение без проверки его содержимого. Конечно, если содержимое некорректно и путь передачи не позволяет его воспринять, такое решение может привести к доставке конечному адресату искаженного сообщения. Системы доставки SMTP могут отвергать (возвращать — bounce) такие сообщения, не доставляя их. Никаким передающим системам SMTP не дозволяется передавать envelope-команды, содержащие символы, не включенные в набор US-ASCII; принимающим системам рекомендуется отвергать такие команды, используя стандартный отклик 500 syntax error — invalid character.

Клиент может у сервера передачу 8-битового содержимого сообщений с использованием расширенных возможностей SMTP (8BITMIME [20]). Серверам SMTP следует поддерживать режим 8BITMIME. Однако это не должно трактоваться как разрешение на неограниченную передачу 8-битовых символов. Для отправителя недопустимо запрашивать режим 8BITMIME для передачи данных, в которых для старшего бита не используется соответствующее кодирование MIME; серверы могут отвергать такие сообщения.

Используемая в этом документе металингвистическая нотация соответствует нотации Augmented BNF, принятой в документах почтовой системы Internet. Читателям, которые незнакомы с этим синтаксисом, следует прочесть спецификацию ABNF [8]. Для ясности термины метаязыка, используемые в тексте, обозначены угловыми скобками (например, <CRLF>).

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

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

Протокол SMTP позволяет серверу формально отвергать транзакцию, позволяя по-прежнему изначальные соединения: код 554 может возвращаться в открывающем сообщении взамен кода 220. Сервер, использующий такой вариант, должен по-прежнему ждать, пока клиент передаст команду QUIT (см. параграф 4.1.1.10) перед закрытием соединения, а на любую мешающую команду следует возвращать отклик 503 bad sequence of commands (некорректная последовательность команд. Поскольку попытка организации SMTP-соединения с такими системами может приводить к ошибке, серверу, возвращающему код 554, следует передавать вместе с кодом информацию, которая позволит передающей системе понять причину ошибки.

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

Старые системы SMTP, неспособные поддерживать расширения сервиса и современные клиенты, которым не требуется расширенный сервис с инициируемом почтовом сеансе, могут использовать HELO взамен EHLO. Для серверов недопустимо возвращать расширенные отклики в стиле EHLO на команду HELO. Для конкретной попытки соединения, если сервер возвращает отклик command not recognized (команда не распознана) на EHLO, клиенту следует начать процесс заново и передать команду HELO.

Хост, передающий команду EHLO, идентифицирует в ней себя; команду можно интерпретировать как «Hello, I am <domain>" (Привет, я домен …), а для случая EHLO — «and I support service extension requests» (я могу …).

После того, как сервер передал приглашающее сообщение и клиент получил его, последний обычно передает серверу команду EHLO, идентифицирующую клиента. А дополнение к открытию сеанса использование EHLO показывает, что клиент способен работать с расширенным сервисом и запрашивает у сервера список поддерживаемых расширений. Старые системы SMTP, неспособные поддерживать расширения сервиса и современные клиенты, которым не требуется расширенный сервис с инициируемом почтовом сеансе, могут использовать HELO взамен EHLO. Для серверов недопустимо возвращать расширенные отклики в стиле EHLO на команду HELO. Для конкретной попытки соединения, если сервер возвращает отклик command not recognized (команда не распознана) на EHLO, клиенту следует начать процесс заново и передать команду HELO.

Хост, передающий команду EHLO, идентифицирует в ней себя; команду можно интерпретировать как «Hello, I am <domain>" (Привет, я домен …), а для случая EHLO — «and I support service extension requests» (я могу …).

Поддержка пересылки чаще всего требуется для консолидации адресов и упрощения адресации в сети предприятия (или применительно к такой сети) и реже для случаев изменения адресов. Пересылка без уведомления отправителя (Silent forwarding) в целях обеспечения безопасности или иных целях весьма распространена сегодня в Internet.

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

В частности:

• Сервер может пересылать сообщения, когда ему известно об изменении адреса. При такой пересылке сервер может предоставлять сведения о смене адреса с кодом 251 или «по-тихому» пересылать сообщение, возвращая код 250. При использовании кода 251 недопустимо предполагать, что клиент будет обновлять информацию об адресе получателя на основе принятого от сервера отклика.
• Сервер может отвергнуть или «завернуть» сообщения, когда их невозможно доставить по указанному адресу. В таких случаях сервер может сообщить о смене адреса в отклике 551 или отвергнуть сообщение как недоставляемое с кодом 550 без дополнительных сведений. При использовании кода 551 недопустимо предполагать, что отправитель будет обновлять адрес на основе полученных сведений или доводить эту информацию до пользователя.

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

Протокол 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 (пользователя не определить однозначно) или ambiguous (неоднозначность), возможно дополненных расширенными кодами отклика (типа рассмотренных в работе [34]), помогает при необходимости обеспечивать автоматический перевод на другие языки. Клиенты с высоким уровнем автоматизации и поддержкой других языков могут попытаться перевести отклик, возвратить пользователю нестандартную индикацию или предпринять некоторые автоматические операции типа обращения к службе каталогов для получения дополнительных данных перед возвратом отклика пользователю.

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

На некоторых хостах различия между списками рассылок и псевдонимами выражены весьма слабо, поскольку оба типа записей могут сохраняться в единой структуре данных и могут существовать списки рассылок, содержащие единственный адрес. Если дается запрос на применение команды VRFY к списку рассылок, позитивный отклик может быть возвращен, если направленное по адресу списка сообщение может быть доставлено кому-либо из списка, в остальных случаях следует возвращать сообщение об ошибке (например, отклик 550 That is a mailing list, not a User – «это список рассылки, а не пользователь» или 252 Unable to verify members of mailing list «невозможно проверить членов списка»). Если делается запрос имени пользователя из списка, сервер может давать позитивный отклик, содержащий список из одного имени, или сообщение об ошибке (например, 550 That is a user name, not a mailing list – «это имя пользователя, а не список рассылки»). При успешном выполнении возвращается многострочный отклик (обычный для EXPN), содержащий имя одного почтового ящика в каждой строке. Ситуации с неоднозначными запросами были рассмотрены выше.

Термин User name (имя пользователя) является недостаточно четким и должен использоваться осмотрительно.
Реализации команд VRFY и EXPN должны, по крайней мере, распознавать локальные почтовые ящики как имена пользователей. Однако в сети Internet зачастую один хост обслуживает почту для множества доменов, хостам (особенно тем, которые работают с разными доменами) следует обеспечивать такую функциональность и воспринимать форму local-part@domain как имя пользователя; хосты также могут распознавать как «имена пользователей» строки других типов.

Случай получения имен почтовых ящиков из списка рассылок требует многострочных откликов типа приведенного ниже (C – клиент, S – сервер; прим. перев.):

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

Когда возвращается нормальный (код 2yz или 551) в результате запроса VRFY или EXPN, отклик обычно включает имя почтового ящика, т. е., должна присутствовать запись вида <local-part@domain>, где domain является полным (fully qualified) доменным именем. В ситуациях, исключающих нарушение требований данной спецификации, может текстовая строка произвольной формы. Для облегчения анализа и разделения имени почтового ящика и данных человека (или компании) адрес следует выводить в угловых скобках. При возврате адресов (а непроизвольной текстовой строки) команды EXPN и VRFY должны возвращать только корректные значения доменной части адреса, которые можно использовать в команде RCPT. Следовательно, если адрес подразумевает доставку программе или другой системе, должно указываться имя почтового ящика, используемого для доступа к адресату. Возврат путей (явные маршруты source route) для команд VRFY и EXPN недопустим.

Реализациям серверов следует поддерживать обе команды VRFY и EXPN.
В Целях безопасности может обеспечиваться локальная возможность отключить эти команды с помощью конфигурационных параметров. Когда эти команды поддерживаются, не требуется работать через трансляторы при разрешенной трансляции. Поскольку обе эти команды были необязательными в спецификации RFC 821, они должны быть указаны как расширения сервиса в отклике EHLO (если команды поддерживаются).

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

Существуют ситуации, когда адрес представляется корректным, но не может быть проверен в реальном масштабе времени (в частности, когда сервер используется при обмене почтой для другого сервера или домена). «Видимая корректность" (Apparent validity) в таких случаях будет включать по крайней мере проверку синтаксиса, и может также включать проверку возможности трансляции для указанного адреса. В таких случаях следует возвращать код 252. Эти ситуации связаны с вопросами проверки RCPT, рассмотренными в параграфе 2.1.

Аналогично ситуации, описанной в 3.4, коды 251 и 551 могут использоваться для команд VRFY и EXPN, чтобы показать адреса, которые распознаны, но почта для них будет пересылаться или была возвращена. Реализациям в общем случае следует быть более жесткими в вопросах проверки адресов для случая VRFY, нежели для команды RCPT, даже если это будет занимать немного больше времени.

Команда EXPN зачастую очень полезна для отладки и поиска проблем, связанных со списками рассылок и псевдонимами ко множеству адресов (multiple-target-address alias). Некоторые системы пытаются использовать поиск отправителя в списке рассылки для предотвращения дубликатов.

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

При использовании доменных имен в SMTP допускаются только преобразуемые (resolvable), полные доменные имена (FQDN). Иными словами, допустимы имена, которые включены в записи MX RR или A RR (см. главу 5), а также имена, указанные в записях CNAME RR серверов имен (DNS). Недопустимо использование локальных имен и неполных доменных имен.

Однако существуют два исключения из правил FQDN:

• Доменное имя в команде EHLO должно быть основным именем хоста (primary host name – доменное имя, включенное в запись A RR) или, есл хост не имеет имени, - «дословным» адресом в соответствии с 4.1.1.1.
• Зарезервированное имя почтового ящика postmaster может использоваться в команде RCPT без указания домена (см. параграф 4.1.1.3) и должно восприниматься сервером.

Доступность записей MX (Mail exchanger) в DNS [22, 27] избавляет от необходимости использования явно заданных маршрутов в почтовой системе Internet. С явной маршрутизацией почты связано множество проблем, делающих такое использование совершенно нежелательным. Клиентам SMTP не следует генерировать явные маршруты source route за исключением особых ситуаций. Серверы SMTP могут отказывать в трансляции или не воспринимать сообщения в указанным отправителем маршрутом. Обнаружив маршрутную информацию, сервер SMTP может игнорировать ее и просто переслать почту конечному адресату, указанному в последнем элементе заданного маршрута (серверам следует поступать именно так).

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

Когда маршруты source route не используются, процесс, описанный в RFC 821 для конструирования обратного пути из прямого, неприменим и обратный путь во время доставки будет просто адресом, указанным в команде MAIL.
Транслирующий сервер SMTP обычно определяется из записи MX и не является системой окончательной доставки почты. Такой сервер может принимать или отвергать трансляцию почты аналогично восприятию или отказу для почты локальных пользователей. Если сервер принял трансляцию, от становится клиентом SMTP, организуя канал передачи следующему серверу SMTP, указанному в DNS (в соответствии с правилами, описанными в главе 5), и передает ему почту. Если сервер отвергает трансляцию почты для какого-либо адреса, ему следует возвращать отклик 550.

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

Важно отметить, что записи MX могут указывать на серверы SMTP, которые действуют как шлюзы в другие среды, а не только выполняют трансляцию и окончательный прием почты (см. параграф 3.8 и главу 5).
Если сервер SMTP принял на себя задачу трансляции почты и позднее обнаружил, что получатель указан некорректно или почту невозможно доставить по каким-либо причинам, этот сервер должен создать уведомление о невозможности доставки почты (undeliverable mail) и переслать его отправителю недоставленного сообщения, указанному в обратном пути. Для уведомления следует (по возможности) использовать стандартные форматы (см., например [24, 25]).

Это уведомление должно посылаться сервером SMTP с хоста-транслятора или хоста, который обнаружил невозможность доставки. Естественно, что для серверов SMTP недопустима отправка уведомлений о невозможности доставки уведомлений (о невозможности доставки почты). Одним из способов предотвращения петель при передаче сообщений об ошибках является использование пустой строки обратного пути (null reverse-path) в команде MAIL при передаче уведомления. При передаче такого сообщения строка обратного пути должна быть пустой – null (см. параграф 4.5.5).

Команда MAIL с пустым обратным путем имеет вид: MAIL FROM:<>
Как обсуждалось в параграфе 2.4.1, транслятор SMTP не обязан проверять и обрабатывать заголовки и тело транслируемых сообщений, а также недопустимы любые действия по отношению к сообщению, за исключением добавления к заголовку строки "Received:" (см. параграф 4.4) и (необязательной) попытки обнаружения петель (см. 6.2).

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

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

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

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

При пересылке сообщения в среду Internet или из нее шлюз должен включить в заголовок свою строку Received:, но недопустимо менять строки Received:, уже имеющиеся в заголовке.

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

Шлюзу следует указывать среду и протокол с помощью поля via в строке Received, создаваемый шлюзом.

Со стороны Internet шлюзу следует воспринимать все корректные форматы адресов в командах SMTP и заголовках RFC 822, а также все корректные сообщения RFC 822. Генерируемые шлюзом адреса и заголовки должны соответствовать применимым стандартам Internet (включая данную спецификацию и RFC 822). Шлюзы подчиняются тем же правилам обработки маршрутов source route, которые описаны в параграфе 3.3 для других систем SMTP.

Шлюз должен обеспечивать соответствие требованиям Internet всех полей заголовков в сообщениях, передаваемых в почтовую среду Internet. В частности, все адреса в полях From:, To:, Cc: и т. п. должны преобразовываться (если нужно) в соответствии с синтаксисом RFC 822, должны указывать только полные доменные имена и должны быть эффективны и полезны для передачи откликов.

Алгоритму, используемому для преобразования почты Internet в другие форматы, следует обеспечивать доставку сообщений об ошибках из чужой почтовой среды по пути возврата из конверта SMTP, а не отправителю, указанному в поле From: (или других полях) заголовка RFC 822.

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

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

Соединение SMTP разрывается при получении от клиента команды QUIT. Сервер возвращает в ответ на эту команду позитивный отклик и закрывает соединение.

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

• Получение команды QUIT и отклик на нее с кодом 221.
• Определение необходимости отключения (shut down) сервиса SMTP и возврат кода 421. Такой отклик может выдаваться после получения сервером любой команды или (при необходимости) асинхронно (независимо от команд) в предположении, что клиент будет получать отклик после ввода следующей команды.

В частности, разрыв соединения сервером в ответ на непонятную команду является нарушением данной спецификации.

Ожидается, что серверы будут терпимы к неизвестным командам, возвращая в ответ на них код 500 и ожидая дальнейших инструкций от клиента.
Серверам SMTP, которые отключаются (shut down) путем внешнего воздействия, следует пытаться передать клиенту строку, содержащую код 421, до завершения работы. Клиент SMTP обычно будет получать код 421 после передачи следующей команды.

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

Хостам SMTP следует поддерживать как псевдонимы, так и списки для обеспечения групповой рассылки сообщений.
Когда сообщение доставляется или пересылается по каждому адресу из списка, адрес возврата в конверте (MAIL FROM:) должен заменяться на адрес администратора списка. Однако в таких случаях заголовок сообщения [32] должен сохраняться неизменным; в частности, не должно меняться поле From.

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

Серверу следует просто использовать адреса из списка, применение эвристики или проверки соответствия для исключения некоторых адресов (например, отправителя исходного сообщения) настоятельно не рекомендуется. Будем называть псевдо-адреса списками (list, mail list) или псевдонимами (alias) в зависимости от способа получения адресов из списка.

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

Почтовые списки обеспечивают перераспределение (redistribution), а не пересылку (forwarding) сообщений. Для преобразования списка почтовая программа-получатель заменяет в конверте псевдо-адрес реальными адресами из списка. Адрес возврата в конверте заменяется на адрес администратора списка (не отправителя сообщения), который обычно контролирует содержимое списков и доставку.

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

Почтовая транзакция включает несколько объектов данных, используемых в качестве аргументов различных команд.
Обратный пути (reverse-path) является аргументом команды MAIL, прямой пути (forward-path) — аргументом RCPT, а данные — аргументом команды DATA. Эти аргументы или объекты данных должны передаваться и сохраняться до завершения приема данных, указывающих окончание почтовой транзакции. Для каждого типа данных (прямой и обратный путь и почтовые данные) используются различные буферы. Конкретная команда приводит к добавлению (append) информацию в конец соответствующего буфера или приводит к созданию одного или нескольких буферов.

Некоторые команды (RSET, DATA, QUIT) не поддерживают параметров. В отсутствие специфических расширений, предлагаемых сервером и принимаемых клиентом, для последних недопустимо передавать параметры таким командам, а серверу следует отвергать команды как в случаях некорректного синтаксиса.

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

Клиентам SMTP следует начинать сессию SMTP с помощью команды EHLO. Если сервер SMTP поддерживает расширенные службы SMTP, он будет передавать позитивный отклик, сообщение о сбое или сообщение об ошибке. Если сервер SMTP (в нарушение данной спецификации) не поддерживает никакого расширенного сервиса SMTP, он будет генерировать в ответ сообщение об ошибке. Старые клиенты SMTP могут (как обсуждалось выше) использовать команду HELO (в соответствии с RFC 821) взамен EHLO, серверы должны поддерживать команды HELO и давать на них правильный отклик. В любом случае клиент должен использовать команду HELO или EHLO до начала почтовой транзакции.

Эти команды и отклики 250 OK на них подтверждают, что клиент и сервер 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)
; строка символов, не содержащая CR или LF
ehlo-line = ehlo-keyword *(SP ehlo-param)
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / «-»)
; дополнительный синтаксис ehlo-params в зависимости от ehlo-keyword
ehlo-param = 1*(%d33−127)
; любые символы, включая <SP> и управляющие коды US-ASCII (0 31)

Хотя в команде EHLO можно использовать любую комбинацию строчных и прописных букв, команда всегда должна распознаваться и обрабатываться как EHLO (заглавные буквы) — это просто расширение практики, указанной в RFC 821 и параграфе 2.4.1.

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

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

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

Синтаксис:
«MAIL FROM:» («<>» / Reverse-Path) [SP Mail-parameters] CRLF

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

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

Подобно этому трансляторам следует пропускать или игнорировать source route, а имена недопустимо копировать в поле обратного пути. Когда почта приходит к конечному адресату (прямой путь содержит только почтовый ящик получателя), сервер 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 может также транслировать почту через другой хост, используя в конверте команды

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 (отказ в соответствии с используемыми правилами — policy reason).

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

Синтаксис:
«RCPT TO:» («<Postmaster@» domain «>» / «<Postmaster>» / Forward-Path) [SP Rcpt-parameters] CRLF

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

Данные завершаются строкой, содержащей только точку и последовательность завершения строки (в потоке символов это будет <CRLF>.<CRLF>, см. параграф 4.5.2). Отметим, что первая последовательность <CRLF> на самом деле завершает последнюю строку почтовых данных (текста сообщения) или (при отсутствии данных) — командную строку DATA. Недопустимо добавление лишних последовательностей <CRLF>, поскольку это будет приводить к вставке пустой строки в сообщение. Единственным исключением из этого правила является обработка сообщений, переданных исходному отправителю без завершающей последовательности <CRLF> в последней строке; в таких случаях отправляющая сообщение система SMTP должна отвергнуть сообщение как некорректное или добавить <CRLF> в конце, чтобы принимающий сервер SMTP смог зафиксировать условие end of data (конец сообщения).

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

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

Когда сервер SMTP воспринимает сообщение для трансляции или окончательной доставки, он помещает трассировочную запись (trace record), которую также называют time stamp line (строка с временной меткой) или строка Received в верхней части почтовых данных. Эта запись показывает хост, передавший сообщение, хост-приемник (сервер), а также дату и время приема сообщения. Транслируемые сообщения могут содержать на финальном этапе множество трассировочных записей. Детальное описание трассировки и синтаксиса записей приводится в параграфе 4.4.
Дополнительную информацию по обработке команд DATA можно найти в параграфе 3.3.

Синтаксис:
«DATA» CRLF

Эта команда служит для прерывания текущей почтовой транзакции. Все сохраненные в буферах данные должны быть отброшены с очисткой буферов. Принимающая сторона в ответ на команду RSET передает отклик 250 OK без дополнительных аргументов. Команду RSET клиент может вводить в любой момент транзакции. Эта команда является эквивалентом NOOP (не выполняется никаких действий) при введении сразу после EHLO, до первого использования EHLO в данном сеансе, после завершения и подтверждения передачи данных или непосредственно перед командой QUIT. Для серверов SMTP недопустимо закрывать соединение в результате получения команды RSET — для разрыва соединения служит команда QUIT (см. параграф 4.1.1.10).

Поскольку обработка команд EHLO требует некоторых дополнительных операций на сервере, использование команды RSET обычно более эффективно, чем повторный ввод EHLO, хотя формальная семантика команд одинакова. Существуют обстоятельства (неконтролируемые данной спецификацией), при которых сервер SMTP может получить индикацию разрыва или сброса соединения на нижележащем уровне TCP. Для сохранения отказоустойчивости почтовых систем серверам SMTP следует быть готовыми к таким ситуациям и трактовать их как получение команды QUIT до потери соединения.

Синтаксис:
«RSET» CRLF

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

Синтаксис:
"VRFY" SP String CRLF

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

Синтаксис:
"EXPN" SP String CRLF

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

Синтаксис:
"HELP" [ SP String ] CRLF

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

Синтаксис:
"NOOP" [ SP String ] CRLF

Получив эту команду сервер должен возвратить отклик и OK закрыть канал передачи.
Для сервера недопустим преднамеренный разрыв соединения, до получения команды QUIT и отклика на нее (даже при возникновении ошибок). Если соединение закрыто преждевременно в нарушение сказанного выше или в результате сетевого сбоя, сервер должен прервать все незавершенные транзакции, не отказываясь от выполненных транзакций, и (в общем случае) должен действовать как при получении информации об ошибке во время выполнения команды или транзакции (т. е., отклик 4yz).
Команда QUIT может быть введена в любой момент.

Синтаксис:
"QUIT" CRLF

Ниже приведен синтаксис полей аргументов перечисленных выше команд (по возможности, следует пользоваться синтаксисом, описанным в работе [8]). Некоторые из приведенных ниже вариантов используются только с маршрутами source route, как описано в Приложении C. Обозначения, не определенные здесь (типа ALPHA, DIGIT, SP, CR, LF, CRLF), описаны в работе [8] (глава 6) или [32].

Reverse-path = Path
Forward-path = Path
Path = «<» [ A-d-l «:» ] Mailbox «>»
A-d-l = At-domain *(«,» A-d-l)
; отметим, что эта форма, называемая source route",
; должна приниматься, ее не следует генерировать и следует игнорировать.
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)
; любые символы кроме =, SP и управляющих кодов
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 «]»
; См. параграф 4.1.3
Mailbox = Local-part «@» Domain
Local-part = Dot-string / Quoted-string
; регистр символов может различаться
Dot-string = Atom *(«.» Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
String = Atom / Quoted-string

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

Недопустимо определять почтовые ящики таким образом, чтобы в SMTP требовалось использование символов, не входящих в набор ASCII (символов, использующих 8-битовую кодировку) или управляющих кодов ASCII (десятичные значения 0−31 и 127). Такие символы недопустимо использовать в командах MAIL и RCPT или других командах, содержащих имена почтовых ящиков.
Отметим, что обратный слэш (\) относится к символам квотирования, используемым для индикации буквального (literally) использования следующего символа (взамен обычной интерпретации). Например, запись «Joe\, Smith» соответствует «Joe, Smith», т. е. Запятая после знака \ трактуется именно как запятая, а не специальный символ.

Для обеспечения интероперабельности и совместимости с DNS в именовании и приложениях (см., например, параграф 2.3.1 базового стандарта DNS — RFC1035 [22]) недопустимо включать в метки доменных имен для клиентов и серверов SMTP никакие символы, кроме букв латиницы, цифр и дефиса. В частности, символ подчеркивания (underscore) использовать нельзя. Серверы SMTP, получающие команды с некорректными символами (при отсутствии других причин для отказа) должны отвергать такие команды с возвратом отклика 501.

Иногда хост не знает доменного имени и почтовая связь (в частности, передача сообщений об ошибках) блокируется.
Для решения этой проблемы в качестве альтернативы доменному имени может использоваться специальная форма адреса (literal address). Для адресов IPv4 эта форма использует десятичное представление байтов IP-адреса с разделением точками. Адреса заключаются в квадратные скобки (например, [123.255.37.2]), которые говорят об использовании адреса IPv4 в десятичном представлении с разделением точками. Для 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; должен быть стандартизован в RFC и зарегистрирован IANA
Snum = 1*3DIGIT; десятичное целое от 0 до 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)]
;: представляет по крайней мере 2 16-битовых последовательности нулей
; в дополнение к: может присутствовать не более 6 групп
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
;: представляет по крайней мере 2 16-битовых последовательности нулей
; в дополнение к: может присутствовать не более 4 групп и
; IPv4-address-literal

Для порядка использования команд существуют некоторые ограничения.
Сеанс, который будет включать почтовую транзакцию, должен быть сначала инициализирован командой 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 access denied to you в ответ на команду EXPN некорректен, если команда EHLO не была введена до EXPN или отказ клиенту не было отказано в обслуживании на основе IP-адреса клиента или по результатам аутентификации или аналогичных механизмов.

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

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

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

Как было сказано в параграфе 2.2.2, команды, начинающиеся с X, могут использоваться в результате двухстороннего соглашения между клиентом (отправитель) и сервером (получатель) SMTP. Предполагается, что сервер SMTP, не распознающий такие команды, будет возвращать отклик 500 Command not recognized. Сервер SMTP с расширенными функциями может перечислить имена, связанные с командами частного использования в своем отклике на команду EHLO.

Команды, переданные или воспринятые системами SMTP и не начинающиеся с X, должны соответствовать требованиям параграфа 2.2.2.

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

Отклик 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 должны определять свои действия только на основе кода отклика, а не его текста (за исключением «change of address» 251 и 551, а при необходимости и 220, 221, 421). В общем случае клиент должны воспринимать любой текст и отклики без текста (хотя серверам не следует передавать откликов, содержащих только код). Пробел после кода отклика рассматривается как часть текста. По возможности получателю следует проверять первую цифру кода отклика (индикация важности).

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

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

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

2yz — позитивный окончательный отклик
Запрошенная операция успешно завершена и могут вводиться новые команды.

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

4yz — негативный отклик о временных проблемах
Команда не принята и запрошенная операция не выполнена. Однако условия, не позволяющие выполнить команду, носят временный характер и операция может быть запрошена вновь. Отправителю следует вернуться к началу последовательности команд (если таковая была). Понятие «временный» (transient) является недостаточно строгим и взаимодействующие стороны (клиент и сервер SMTP) должны одинаково интерпретировать его. Для каждого отклика этой группы время может различаться, но клиенту SMTP ничто не запрещает продолжать попытки. Различия между временными и постоянными проблемами (коды 5yz) достаточно условны и отклики 4yz обычно возвращаются в тех случаях, когда возможен позитивный результат при повторе без изменения формы команды и свойств отправителя или получателя (т. е., команда просто может быть повторена без изменений).

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

Вторая цифра отклика показывает категорию ошибки:
x0z Синтаксис: данный отклик связан с синтаксической ошибкой (синтаксически корректная команда, но отклик не может быть отнесен к другим категориям, нереализованная команда и т. п.).
x1z Информация: отклик на запрос информации (например, справка или состояние).
x2z Соединение: отклики, относящиеся в каналу передачи.
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

В большинстве случаев клиенту достаточно найти строку, в которой за кодом отклика следует <SP> или <CRLF> и пропустить все предшествующие строки. В некоторых случаях текстовый отклик содержит важные для клиента данные, которые клиент может обрабатывать с учетом контекста.

У разработчиков часто возникают вопросы об использовании отклика 502 (Command not implemented – команда не реализована). Код 502 следует использовать в тех случаях, когда сервер SMTP распознал команду, но не умеет ее выполнять. Если команда не распознана, следует возвращать код 500. Для систем SMTP с расширенными функциями в откликах на команду EHLO недопустимо указывать команды, приводящие к отклику 502 или 500.

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

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

Когда сервер SMTP возвращает отклик о временных проблемах7 (4yz) после команды DATA с завершающей последовательностью <CRLF> <CRLF>, недопустимо предпринимать какие-то последующие попытки доставки этого сообщения. Клиент SMTP сохраняет за собой ответственность за доставку этого сообщения и может возвратить его пользователю или снова поставить в очередь на доставку (см. параграф 4.5.4.1).

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

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

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

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

Одним из важных откликов является приветствие при организации соединения. Обычно получатель передает отклик 220 "Service ready" при организации соединения. Отправителю следует дождаться этого отклика и только потом передавать следующие команды.

Все отклики-приветствия включают официальное имя (полное доменное имя) хоста, на котором работает сервер, в качестве первого слова после кода. В некоторых случаях у хоста может не быть собственного имени. Обсуждение альтернативных имен для таких ситуаций приводится в параграфе 4.1.3. Ниже приведены 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

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

Для каждой команды указаны все возможные варианты откликов. Поскольку некоторые серверы могут генерировать иные отклики в соответствующих обстоятельствах и с учетом возможности появления новых кодов, клиентам SMTP следует (по возможности) интерпретировать только первую цифру кода. Кроме того, клиент должен быть готов к работе с неизвестными кодами, также интерпретируя в них только первую цифру. За исключением расширенного использования механизмов, описанных в параграфе 2.2, для серверов SMTP недопустима передача кодов, содержащих что-либо сверх 3 цифр или использующих цифры, не входящие в разрешенный диапазон 2 - 5 (включительно).

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

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

500 - для случая command line too long (слишком длинная команда) или при получении непонятной команды. Отметим, что отклик command not recognized в ответ на команду из обязательного набора является нарушением данной спецификации.

501 - Syntax error in command or arguments (синтаксическая ошибка в команде или аргументах). Для поддержки будущих расширений командам, включенным в данную спецификацию как команды без аргументов (DATA, RSET, QUIT), следует возвращать отклик 501 при получении команды с аргументами, если иное не согласовано в анонсированном EHLO расширении.

421 Service shutting down and closing transmission channel - сервис отключен с разрывом коммуникационного канала.

В нормальных условиях в ответ на команды могут возвращаться следующие отклики:

Когда сервер SMTP получает сообщение для доставки или дальнейшей обработки, он должен вставить трассировочную информацию (time stamp или Received) в начало содержимого, как описано в параграфе 4.1.1.4.

Трассировочная строка должна иметь следующую структуру:

• В поле FROM, которое должно обеспечиваться в среде SMTP, следует включать (1) имя хоста-отправителя, представленное в команде EHLO, и (2) IP адрес отправителя, определенный из соединения TCP.
• Поле ID может включать "@", как предложено в RFC 822, но это необязательно.
• Поле FOR может содержать список элементов <path>, если используется множество команд RCPT. Это может влиять на безопасность системы и обычно нежелательно включать такие списки (см. параграф 7.2).

Для почтовых программ Internet недопустимо внесение изменений в строки Received:, уже присутствующие в заголовке сообщения. Серверы SMTP должны добавлять в начало свою строку Received, но недопустимо менять порядок имеющихся строк или вставлять свою строку Received в другое место заголовка. По мере расширения сети Internet просмотр строк Received становится все более важным средством диагностики почтовых систем, особенно для обнаружения медленно работающих трансляторов.

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

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

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

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

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

Основным назначением Return-path является указание адреса, по которому следует доставлять сообщения об ошибках.

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

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

В частности:

• Шлюзам из SMTP в другие среды следует вставлять обратный путь, если у них нет информации о том, что другая среда также использует в адресах доменные имена Internet и поддерживает отдельный конверт с адресом отправителя.
• Шлюзам из других сред в SMTP следует удалять из заголовка строку обратного пути и копировать эту информацию в конверт SMTP или объединять ее с присутствующей в конверте информацией из другой транспортной системы для построения обратного пути для команды formation present in the envelope of the other transport system to construct the reverse path argument to the MAIL command in the SMTP envelope.

Сервер должен принимать специальные меры в случаях, когда обработка принятых почтовых данных может быть успешной лишь отчасти. Это может произойти, если после приема нескольких адресов получателей и почтовых данных для них сервер 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
; date-time определено в [32], но форма "obs-", особенно для 2-значного указания года
; запрещена в SMTP и ее использование недопустимо.
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 )
; сервер получает информацию из соединения TCP, а не из команды 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
; Дополнительные стандартные имена каналов регистрируются в IANA.
; Поле Via используется прежде всего для чужого транспорта (не Internet).
; Серверам SMTP недопустимо использовать незарегистрированные имена.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom

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

EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY

Любые системы, которые включают сервер SMTP, поддерживающий трансляцию или доставку почты, должны поддерживать зарезервированный почтовый ящик postmaster как независимое от регистра локальное имя. Без такого адреса можно обойтись, если сервер всегда возвращает отклик 554 на открытие соединений (см. параграф 3.1).

Требование принимать почту для адресата postmaster, ведет к тому, что команды RCPT, указывающие адрес postmaster в любом из доменов, для которых сервер SMTP обеспечивает почтовое обслуживание, а также специальный случай команды RCPT TO:<Postmaster> (без указания домена), должны поддерживаться сервером.

Предполагается, что системы SMTP будут прилагать все разумные усилия для восприятия почты в адрес Postmaster от любой другой системы в Internet. В экстремальных случаях (например, при атаках на службы — denial of service attack) или других нарушениях системы безопасности сервер SMTP может блокировать почту, направленную по адресу Postmaster.

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

Без принятия некоторых специальных мер последовательность <CRLF>.<CRLF> будет восприниматься как завершение почтовых данных и не может включаться пользователем в текст. Обычно пользователи даже не знают о таких «скрытых» последовательностях.

Для прозрачной передачи подготовленного пользователем текста служат следующие процедуры:

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

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

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

Существуют некоторые объекты, для которых требуется ограничение размера. Каждая реализация должна быть способна принимать объекты, размеры которых не выходят за эти ограничения. Следует (по возможности) избегать передачи объектов большего размера. Однако некоторые почтовые системы Internet создают такие адреса в формате X.400 [16], которые могут потребовать большего размера объектов — клиенты могут пытаться передать такие объекты, но они должны быть готовы к отказу серверов от обслуживания слишком больших объектов. Для снижения вероятности возникновения проблем в реализациях следует использовать методы, не ограничивающие размеры объектов.

локальная часть адреса
Максимальный размер имени пользователя или локальной части адреса составляет 64 символа.

домен
Максимальный размер доменного имени составляет 255 символов.

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

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

строка отклика
Максимальная длина строки отклика с учетом кода и <CRLF> составляет 512 символов. Дополнительную информацию можно передать, используя многострочный отклик.

текстовая строка
Максимальная длина строки текста с учетом <CRLF> составляет 1000 символов (не учитывая добавляемую в начало точку в случаях обеспечения прозрачности). Расширения SMTP могут использовать более длинные строки.

содержимое сообщения
Ограничение максимального размера содержимого сообщения (включая заголовки и тело) должно быть не менее 64K октетов. После введения стандартов Internet на multimedia-почту [12] размеры почтовых сообщений Internet многократно возросли и по возможности следует избегать ограничения размера сообщений. Системам SMTP, которые не могут отказаться от ограничения размеров следует реализовать сервисное расширение SIZE [18], а клиентам SMTP, передающим большие сообщения, следует по возможности использовать это расширение.

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

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

500 Line too long — слишком длинная строка
501 Path too long — слишком длинный путь
452 Too many recipients — слишком много получателей (см. ниже)
552 Too much mail data — слишком много почтовых данных.

В RFC 821 [30] некорректно указано, что сервер SMTP в случаях превышения числа команд RCPT (too many recipients) генерирует отклик с кодом 552. Корректным кодом для таких откликов является 452.

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

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

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

На основе опыта работы трансляторов с высокой нагрузкой значения тайм-аутов, которые следует использовать составляют:

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

Команда RCPT: 5 минут
Если обработка списков рассылки и псевдонимов не откладывается до приема сообщения, требуется увеличение тайм-аута.

Инициирование команды DATA: 2 минуты
Этот тайм-аут определяет время ожидания отклика 354 Start Input на команду DATA.

Блок данных: 3 минуты
Время ожидания завершения каждого вызова TCP SEND для передачи фрагмента данных.

Завершение приема данных по команде DATA: 10 минут.
Время ожидания отклика 250 OK. Когда получатель принимает завершающую точку в данных, он обычно начинает обработку полученных данных для доставки сообщения в почтовый ящик пользователя. Ложные тайм-ауты в это время крайне нежелательны и обычно приводят к доставке многочисленных копий сообщения, поскольку сообщение может быть уже послано и сервер принял на себя ответственность за его доставку (см. параграф 6.1).
Серверам SMTP следует использовать тайм-аут не менее 5 минут при ожидании от клиента следующей команды.

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

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

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

Отправитель должен делать паузу перед повторной попыткой отправить почту адресату после неудачи. В общем случае интервал ожидания следует делать не менее 30 минут, однако более изощренные подходы с переменным временем ожидания будут давать преимущества в тех случаях, когда клиент SMTP может определить причину неудачи.
Попытки продолжаются до тех пор, пока сообщение не будет доставлено или пока не истечет заданное на попытки повтора время (обычно, не менее 4 — 5 дней). Параметры повтора должны быть настраиваемыми.
Клиенту следует сохранять список хостов, которым не удалось отправить почту и соответствующие значения тайм-аутов для соединений вместо «тупых» попыток повтора.

Опыт показывает, что ошибки обычно носят временный характер (отсутствие связи с системой адресата) и рекомендуется делать две попытки повтора в течение первого часа хранения письма в очереди, а далее повторять попытки передачи каждые 2 — 3 часа.
Клиент SMTP может сократить задержку перед повтором, согласовав такое совращение с сервером SMTP. Например, при получении почты с какого-то адреса, очевидна возможность передачи по этому адресу почты из очереди (если она есть). Используя такой подход, приложение в большинстве случаев может обойтись без явного использования функций «передать сообщения из очереди сейчас» типа ETRN [9].

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

В то же время, клиентам SMTP следует с большой осторожностью использовать кэшированные негативные отклики от серверов. В экстремальном случае, если команда EHLO вводится много раз в течение одного соединения SMTP, сервер может возвращать разные отклики. Очень важно подчеркнуть, что отклики 5yz на команду MAIL недопустимо кэшировать.
Когда сообщение доставляется множеству адресатов и сервер SMTP, на который копируется сообщение для передачи, совпадает для множества получателей, следует передавать единственную копию сообщения для всех таких адресатов. Т. е., клиенту SMTP следует использовать последовательность команд MAIL, RCPT, RCPT,… RCPT, DATA вместо последовательности MAIL, RCPT, DATA, …, MAIL, RCPT, DATA. Однако при большом количестве адресатов может быть превышено допустимое число повторов команды RCPT на одну команду MAIL.

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

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

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

Некоторые типы уведомлений, требуемые существующими или предложенными стандартами передаются с пустым полем обратного пути. К числу таких сообщений относятся уведомления об ошибках при доставке (см. параграф 3.7), другие типы сообщений DSN (Delivery Status Notifications — уведомления о состоянии доставки) [24] и сообщения MDN (Message Disposition Notifications — уведомления о доставке) [10]. Все типы указанных сообщений являются уведомлениями о предыдущем сообщении и посылаются по обратному пути из заголовка сообщения, с которым связано данное уведомление.

Невозможность доставки зачастую связана с проблемами в почтовой системе на хосте адресата, поэтому некоторые АДП настраиваются на пересылку таких уведомлений кому нибудь, кто будет способен исправить проблему с почтой (например, с использованием псевдонима postmaster alias).
Все остальные типы сообщений (т. е., любые сообщения, для которых стандарты RFC не требуют использовать пустой путь возврата) следует посылать с корректным, непустым полем обратного пути.

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

После того, как клиент SMTP лексически идентифицирует домен, для которого предназначена передаваемая на обработку почта (см. параграфы 3.6 и 3.7), должно выполняться обращение к серверу доменных имен (DNS lookup) для преобразования доменного имени [22]. Предполагается, что в адресах используются полные имена (FQDN) — механизм определения FQDN по частичному имени или локальному псевдониму выходит за пределы данной спецификации и, в силу сложившейся практики, в общем случае не должен использоваться. При поиске сначала предпринимается попытка найти локальную запись MX, связанную с именем.

Если взамен этого будет найдена запись CNAME, полученное в результате имя обрабатывается как исходное. При отсутствии записей MX одновременно с наличием записей A, последняя трактуется, как будто она связана с реальной записью MX 0, указывающей на тот же хост. Если найдена одна или несколько записей MX для системы SMTP недопустимо использовать какие бы то ни было записи A, связанные с этим именем, пока они не будут найдены с использованием записей MX — приведенное выше правило «неявных» (implicit) записей MX применимо только в случаях отсутствия реальных MX. Если записи MX присутствуют, но ни одна из них не может быть использована, клиенту должно возвращаться сообщене об ошибке.

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

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

Хост получателя (возможно с предпочтительной записью MX) может оказаться многодомным — в таких случаях доменное имя будет преобразовываться в список адресов IP. Ответственность за упорядочивание этого списка лежит на интерфейсе преобразователя имен (domain name resolver), который должен упорядочивать список в порядке снижения предпочтений, а отправитель SMTP должен пытаться использовать адреса в предложенном порядке.
Хотя поддержка попыток доставки с использованием множества адресов требуется от реализации, возможность таких попыток может быть ограничена или отключена совсем. Вопрос о целесообразности использования разных адресов многодомных хостов остается спорным. Основным аргументом в пользу таких попыток является повышение вероятности своевременной доставки сообщений, а в некоторых случаях — просто обеспечение возможности доставки.

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

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

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

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

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

MAIL FROM:<@a,@b:user@d>
Уведомление должно передаваться с помощью команды:
RCPT TO:<user@d>

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

Во избежание дублирования сообщений в результате тайм-аутов, получатель SMTP должен пытаться минимизировать время отклика на индикатор завершения данных <CRLF>.<CRLF>. Подробное обсуждение этого вопроса приводится в RFC 1047 [28].

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

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

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

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

В ответ на появление «ущербных» клиентов SMTP многие системы SMTP сейчас дополнительно обрабатывают сообщения, полученные от таких клиентов в неполном или некорректном формате. Такая стратегия в общем случае приемлема, когда сервер может идентифицировать и аутентифицировать клиента, на основании чего строится взаимодействие между клиентом и сервером. delivered to them in incomplete or incorrect form. Такое решение значительно лучше по сравнению с исправлениями, которые могут вносить серверы доставки или трансляции для малознакомых или совсем неизвестных пользователей и клиентских машин.

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

• добавление поля message-id при его отсутствии;
• добавление даты, времени и часового пояса при их отсутствии;
• корректировка адреса в соответствии с форматом FQDN.

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

Перечисленные выше изменения недопустимо выполнять на промежуточных трансляторах SMTP.

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

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

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

Реальная безопасность почты обеспечивается только сквозными (end-to-end) методами, включающими тело сообщения, типа использования цифровых подписей (см. [14], PGP [4], S/MIME [31]).

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

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

В передаваемых серверу SMTP командах RCPT могут присутствовать адреса, по тем или иным причинам не указанные в заголовке сообщения. Двумя основными вариантами решения таких задач является использование списков и скрытых копий (blind copies — или bc).

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

Не существует неразрывных отношений между обратным (из команд MAIL, SAML и т. п.) и прямым (RCPT) адресом в транзакции SMTP (конверте) и адресами в заголовка. Принимающим системам не следует пытаться найти такие соотношения и использовать их для изменения заголовков с целью доставки сообщения. Популярный заголовок Apparently-to (видимо для:) является нарушением данного принципа и хорошо известным случаем ненамеренного разглашения информации; не следует пользоваться этим заголовком.

Как обсуждалось в параграфе 3.5, отдельные сайты могут заблокировать использование команд VRFY и EXPN из соображений безопасности. Как следует из сказанного выше, для реализаций, обеспечивающих возможность такой блокировки недопустимо показывать, что они могут проверять адреса, не проверяя их фактически. Если сайт блокирует команды из соображений безопасности, сервер SMTP должен возвращать отклик 252, а не код, который может ввести в заблуждение относительно результатов верификации адреса.
Возврат кода 250 в ответ на команду VRFY после проверки лишь синтаксиса команды (а не указанного адреса), является нарушением этого правила. Естественно, что реализации, «поддерживающие» команду VRFY, которые всегда будут возвращать отклик 550 независимо от корректности адреса, также нарушают это правило.

За последние несколько лет содержимое списков рассылки стало очень популярным среди так называемых «спамеров» (spammer). Использование команды EXPN для «сбора» адресов вынудило администраторов принять меры против недопустимого использования списков.

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

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

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

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

Обычно это не создает проблем, но для сайтов с высокими требованиями к вопросу разглашения имен это может иметь важное значение. Дополнительные операторы FOR также следует использовать с осторожностью или не использовать совсем в тех случаях, когда многочисленные получатели могут непреднамеренно передать информацию о скрытых получателях (blind copy — bc) другим.

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

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

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

В последние годы использование функций трансляции на промежуточных сайтах стало применяться как способ сокрытия истинного происхождения почты. Некоторые сайты в результате стали предоставлять функции трансляции только известным или идентифицируемым отправителям и разработчикам следует обеспечивать в программах возможность такой фильтрации. Когда почта отвергается по тем или иным причинам, определяемых политикой сайте, рекомендуется использовать код 550 в откликах на команды EHLO, MAIL или RCPT.

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

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

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