2015-08-21
365
SMTP commands and replies have a rigid syntax. All commands begin
with a command verb. All replies begin with a three digit numeric
code. In some commands and replies, arguments are required following
the verb or reply code. Some commands do not accept arguments (after
the verb), and some reply codes are followed, sometimes optionally,
by free form text. In both cases, where text appears, it is
separated from the verb or reply code by a space character. Complete
definitions of commands and replies appear in Section 4.
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That is,
a command verb, an argument value other than a mailbox local-part,
and free form text MAY be encoded in upper case, lower case, or any
mixture of upper and lower case with no impact on its meaning. The
local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts. In particular, for some hosts, the user
"smith" is different from the user "Smith". However, exploiting the
case sensitivity of mailbox local-parts impedes interoperability and
is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.
A few SMTP servers, in violation of this specification (and RFC 821)
require that command verbs be encoded by clients in upper case.
Implementations MAY wish to employ this encoding to accommodate thoseservers.
The argument clause consists of a variable-length character string
ending with the end of the line, i.e., with the character sequence
<CRLF>. The receiver will take no action until this sequence is received.
The syntax for each command is shown with the discussion of that
command. Common elements and parameters are shown in Section 4.1.2.
Commands and replies are composed of characters from the ASCII
character set [6]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted,
right justified, in an octet with the high-order bit cleared to zero.
More specifically, the unextended SMTP service provides 7-bit
transport only. An originating SMTP client that has not successfully
negotiated an appropriate extension with a particular server (see the
next paragraph) MUST NOT transmit messages with information in the
high-order bit of octets. If such messages are transmitted in
violation of this rule, receiving SMTP servers MAY clear the high-
order bit or reject the message as invalid. In general, a relay SMTP
SHOULD assume that the message content it has received is valid and,
assuming that the envelope permits doing so, relay it without
inspecting that content. Of course, if the content is mislabeled and
the data path cannot accept the actual content, this may result in
the ultimate delivery of a severely garbled message to the recipient.
Delivery SMTP systems MAY reject such messages, or return them as
undeliverable, rather than deliver them. In the absence of a server-
offered extension explicitly permitting it, a sending SMTP system is
not permitted to send envelope commands in any character set other
than US-ASCII. Receiving systems SHOULD reject such commands,
normally using "500 syntax error - invalid character" replies.
8-bit message content transmission MAY be requested of the server by
a client using extended SMTP facilities, notably the "8BITMIME"
extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
servers. However, it MUST NOT be construed as authorization to
transmit unrestricted 8-bit material, nor does 8BITMIME authorize
transmission of any envelope material in other than ASCII. 8BITMIME
MUST NOT be requested by senders for material with the high bit on
that is not in MIME format with an appropriate content-transfer
encoding; servers MAY reject such messages.
The metalinguistic notation used in this document corresponds to the
"Augmented BNF" used in other Internet mail system documents. The
reader who is not familiar with that syntax should consult the ABNF
specification in RFC 5234 [7]. Metalanguage terms used in running
text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
The reader is cautioned that the grammar expressed in the
metalanguage is not comprehensive. There are many instances in which
provisions in the text constrain or otherwise modify the syntax or
semantics implied by the grammar.
Статус документа
Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа "Internet Official Protocol Standards" (STD 1). Допускается свободное распространение документа.
Тезисы
Этот документ является спецификацией базового протокола доставки электронной почты Internet. Документ консолидирует, обновляет и проясняет несколько предшествующих документов, отменяя их полностью или частично. Документ включает механизмы расширения SMTP и обобщение накопленного опыта для современного состояния Internet, но не содержит деталей отдельных расширений протокола. Хотя протокол SMTP разработан для обеспечения почтового транспорта и доставки, в данной спецификации содержится также информация, которая важна для протокола подачи сообщений в пользовательских почтовых агентах чтения почты и мобильных средах.
1. Введение
1.1. Транспортировка электронной почты
Целью протокола SMTP является обеспечение надежной и эффективной доставки электронной почты.
Протокол SMTP не зависит от конкретных подсистем передачи и требует для работы лишь канал с гарантированной и упорядоченной доставкой потока данных. Хотя в этом документе обсуждается использование транспорта TCP, возможно использование и других транспортных протоколов. Описания некоторых потоколов этого типа даны в приложениях к RFC 821 [1].
Важным свойством протокола SMTP является возможность транспортировки почты через множество сетей, которые обычно называют «почтовыми трансляторами SMTP» (см. параграф 3.6). Сети состоят из обоюдно доступных по протоколу TCP хостов публичной сети Internet, обоюдно доступных по TCP хостов приватных сетей TCP/IP, находящихся на межсетевыми экранами, или хостов некоторых иных локальных и распределенных сред, использующих на транспортном уровне протоколы, отличные от TCP. Используя протокол SMTP, процесс может передавать почту другому процессу в той же сети или некоторых других сетях через трансляторы или шлюзы, доступные из обеих сетей.
Таким путем почтовые сообщения можно передавать через множество промежуточных трансляторов (relay) или шлюзов на пути между отправителем и конечным адресатом. Для определения следующего промежуточного получателя (next-hop) на пути к адресату используется механизм Mail eXchanger (MX) системы доменных имен (RFC 1035 [2], RFC 974 [12], раздел 5 данного документа).
1.2. Предыстория и контекст документа
Документ содержит спецификацию базового протокола передачи электронной почты в сети Internet. Документ консолидирует, обновляет и разъясняет перечисленные ниже спецификации, не изменяя их функциональности:
исходная спецификация SMTP (Simple Mail Transfer Protocol) — RFC 821 [1];
требования к системе доменных имен и ее использованию для передачи электронной почты — RFC 1035 [2] и RFC 974 [12];
пояснения и вопросы применимости RFC 1123 [3];
материалы из механизмов расширения SMTP Extension — RFC 1869 [13];
редакторские правки и разъяснения к RFC 2821 [14] для повышения статуса до Draft Standard.
Данный документ отменяет действие RFC 821, RFC 974, RFC 1869, RFC 2821 и обновляет RFC 1123 (замена материалов по доставке электронной почты в RFC 1123). Однако в RFC 821 приведены спецификации некоторых свойств, которые не стали достаточно значимыми в среде Internet середины 1990-х, и (в приложениях) некоторые дополнительные транспортные модели. Эти разделы опущены здесь с целью снижения объема документа, интересующиеся читатели могут обратиться к RFC 821.
Документ также включает некоторые дополнительные материалы из RFC 1123, которые требовалось усилить. Такие материалы определены разными путями — прежде всего просмотром популярных списков рассылки и телеконференций, а также идентификацией проблем и разночтений, которые появлялись в разрабатываемых расширениях SMTP. В тех случаях, где настоящая спецификация выходит за пределы консолидации сведений из более ранних документов и реально отличается от них, приведенные здесь сведения имеют более высокий приоритет, как в техническом, так и в текстовом отношении.
Хотя SMTP разрабатывался как протокол транспортировки и доставки электронной почты, данная специффикация содержит также информацию, которая важна для использования протокола в качестве средства представления сообщений, как рекомендовано спецификациями протоколов POP (RFC 937 [15], RFC 1939 [16]) и IMAP (RFC 3501 [17]). В общем случае предпочтительно использовать для представления почтовых сообщений отдельный протокол, описанный в RFC 4409 [18]; далее в документе этот вопрос рассматривается более подробно.
В параграфе 2.3 приводятся определения специфических для данного документа терминов. За исключением тех случаев, когда исторически сложившаяся терминология нужна для понимания, в данном документе применяются современные трактовки терминов «клиент» и «сервер» для обозначения передающих и принимающих процессов SMTP, соответственно.
В дополнительном документе RFC 5322 [4] обсуждаются разделы заголовков и тел почтовых сообщений, а также их структура и форматы.
1.3. Соглашение о терминах
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [5]. Такие термины в документе используются очень аккуратно в целях повышения уровня интероперабельности систем электронной почты. Каждое использование таких терминов должно трактоваться как уровнеь требований в части соответствия данной спецификации.
Поскольку этот документ имеет длинную предысторию, во избежание возникновения ошибок и заблуждений у читателей, большая часть примеров и упомянутых в них доменных имен заимствована из RFC 2821. Читателям следует быть осторожными с приведенными примерами и не использовать их напрямую в программном коде или конфигурационных файлах.
2. Модель SMTP
2.1. Базовая структура
Структура SMTP показана на рисунке:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
Когда у клиента SMTP имеется сообщение для передачи, он организует двухсторонний канал связи с сервером SMTP. Клиент SMTP отвечает за доставку почтовых сообщений одному или множеству серверов SMTP или возврат сообщения об отказе.
Способ представления почтовых сообщений клиенту SMTP и способ определения клиентом идентификаторов (имен) доменов, в которые данное сообщение будет передаваться, определяются локальными условиями и не рассматриваются в этом документе. В некоторых случаях указанный или определенный клиентом SMTP домен идентифицирует конечного получателя сообщения. В других случаях, когда клиенты SMTP связаны с реализациями протоколов POP (RFC 937 [15], RFC 1939 [16]) или IMAP (RFC 3501 [17]) или клиент располагается внутри изолированной транспортной среды, идентифицированный домен будет определять промежуточного получателя, через которого будут транслироваться все почтовые сообщения. Клиенты SMTP, которые передают весь трафик, независимо от домена адресата, связанного с конкретным сообщением, или не поддерживают очередей для повтора попыток передачи сообщений при неудаче, могут соответствовать данной спецификации, но не обеспечивать всех возможностей. Предполагается, что полнофункциональные реализации SMTP, включая трансляторы, которые используются неполными системами и их получателями, будут поддерживать очереди, повторы и альтернативную адресацию, рассматриваемые в данном документе. Во многих случаях упомянутым выше неполнофункциональным клиентам СЛЕДУЕТ использовать протокол представления сообщений (RFC 4409 [18]) взамен SMTP.
Способ, с помощью которого клиент SMTP после определения домена адресата, находит сервер SMTP для передачи сообщения, а также процесс передачи определяются данной спецификацией. Для передачи почты SMTP-серверу клиент SMTP организует двухсторонний канал связи с сервером. SMTP-клиент определяет адрес подходящего хоста, на котором работает сервер SMTP, преобразуя доменное имя получателя в MX-запись (Mail exchanger) промежуточного или конечного хоста-получателя.
Сервер SMTP может быть конечным или промежуточным транслятором (после приема письма сервер выполняет функции клиента SMTP, пересылая сообщение дальше) или шлюзом (может передавать сообщение дальше, используя отличный от SMTPSMTPSMTPSMTP протокол). Команды SMTP генерируются клиентом SMTP и передаются серверу SMTP. Сервер SMTP передает отклики в ответ на команды клиента SMTP.
Иными словами, передача сообщения может осуществляться в один прием путем соединения исходного отправителя SMTP с конечным получателем SMTP или через цепочку промежуточных систем. В любом случае после того, как сервер сообщил об успешном завершении операции в конце передачи почтовых данных, происходит формальная передача ответственности — в соответствии с требованиями протокола сервер ДОЛЖЕН принять на себя ответственность за доставку сообщения или должным образом предоставить отчет о невозможности доставки (см. параграфы 6.1, 6.2 и 7.8 ниже).
После организации коммуникационного канала и согласования параметров клиент SMTP обычно инициирует почтовую транзакцию. Такая транзакция состоит из последовательности команд, задающих отправителя и получателя сообщения, а также передачи содержимого письма (включая все заголовки и прочие структуры). Если одно сообщение передается множеству адресатов, разумно передавать одну копию сообщения для всех получателей, доставка которым осуществляется на один хост или через один промежуточный транслятор.
Сервер обеспечивает отклик на каждую полученную команду — отклик может показывать восприятие команды (в таких случаях ожидаются дополнительные команды), а также содержать сообщение о временной или постоянной ошибке. Команды, задающие отправителя или получателей, могут включать поддерживаемые сервером SMTP расширения, описанные в параграфе 2.2. Диалог между клиентом и сервером осуществляется поэтапно (команда — отклик — команда...), хотя можно использовать по взаимному согласию конвейерную обработку (RFC 2920 [19]).
После завершения передачи сообщения клиент может запросить разрыв соединения или инициировать следующую почтовую транзакцию. Кроме того, клиент SMTP может использовать соединение с сервером для доступа к дополнительному сервису типа проверки корректности почтовых адресов или получения адресов из списка рассылок.
Как сказано выше, протокол обеспечивает механизм передачи электронной почты. Эта передача обычно осуществляется непосредственно с хоста отправителя на хост получателя, когда оба хоста используют один транспортный сервис. Если же хосты не подключены к общей транспортной системе, передача осуществляется с использованием одного или нескольких промежуточных серверов SMTP. Сегодня в Internet обычной практикой является представление исходного сообщения промежуточному серверу «представления сообщений», который похож на транслятор, но выполняет некоторые дополнительные функции; такие серверы рассматриваются в параграфе 2.3.10 и RFC 4409 [18]. Промежуточный хост в таких случаях действует как транслятор (SMTP relay) или шлюз в другие среды передачи и выбирается обычно с использованием MX-записей DNS (служба доменных имен).
Обычно промежуточные хосты определяются по записям DNS MX, а не путем явного задания маршрута отправителем (см. раздел 5, приложение C и параграф F.2).
2.2. Модель расширений
2.2.1. Базовые вопросы
В рамках программы, начатой в 1990, приблизительно через 10 лет после выпуска RFC 821, протокол был обновлен за счет добавления модели «расширения услуг», позволяющей клиентам и серверам согласовать использование общих функций, выходящих за пределы исходной спецификацити SMTP. Механизм расширения SMTP определяет способ согласования расширенных возможностей клиента и сервера SMTP; сервер может информировать клиента о поддерживаемых расширениях.
Современные реализации SMTP должны поддерживать базовые механизмы расширения. Например, сервер должен поддерживать команды EHLO, даже если в нем не реализовано соответствующее расширение, а клиентам следует использовать команду EHLO вместо HELO. В тех случаях, когда для интероперабельности не требуется явное использование HELO, настоящая спецификация всегда рассматривает только команда EHLO.
Протокол SMTP широко распространен и высококачественные реализации обеспечивают высокий уровень устойчивости к ошибкам. Однако сообщество Internet сейчас считает достаточно важными некоторые службы, которых просто не было в момент создания протокола. При добавлении поддержки таких служб должна обеспечиваться возможность приемлемой работы старых реализаций протокола. К числу таких расширений относятся:
команда EHLO взамен прежней команды HELO;
реестр расширений сервиса SMTP;
дополнительные параметры команд MAIL и RCPT;
возможность замены команд, определенных в данном протоколе (таких, как DATA) при передаче символов, отличных от ASCII (RFC 3030 [20]).
Сильные стороны протокола SMTP обусловлены, прежде всего, его простотой. Опыт использования множества протоколов показывает, что протоколы с меньшим числом опций получают более широкое распространение, нежели усложненные протоколы.
Каждое расширение, независимо от обеспечиваемых им преимуществ, должно быть тщательно проверено в части его реализации, развертывания и интероперабельности. Во многих случаях стоимость расширения сервиса SMTP может многократно превысить достигаемые преимущества.
2.2.2. Определение и регистрация расширений
Реестр расширенных служб SMTP поддерживается агентством IANA. С каждым расширением связано соответствующее ключевое значение EHLO. Каждая дополнительная служба, регистрируемая IANA, должна быть определена на основе стандартного протокола или одобренного IESG экспериментального протокола. Определение должно включать:
текстовое имя расширенного сервиса SMTP;
ключевое значение EHLO связанное с этим расширением;
синтаксис и возможные значения параметров, связанных с ключевым значением EHLO;
все дополнительные команды SMTP, связанные с расширением (такие команды обычно используются, но не являются обязательными, как и ключевое значение EHLO);
все новые параметры расширения, связанные с командами MAIL или RCPT;
описание воздействия поддержки расширения на поведение клиентов и серверов SMTP;
размер увеличения максимальной длины команд MAIL и/или RCPT сверх заданного настоящим стандартом.
Кроме того, все ключевые значения EHLO, начинающиеся с X или x, указывающие на локальные расширения сервиса SMTP, используются только на основе двухсторонних соглашений. Ключевые слова, начинающиеся с X (независимо от регистра) НЕДОПУСТИМО использовать в регистрируемых расширениях сервиса. И наоборот, ключевые значения, представляемые в отклике EHLO, который не начинается с X, ДОЛЖНЫ соответствовать стандарту, проекту стандарта или одобренному IESG экспериментальному расширению SMTP, зарегистрированному IANA. Для соответствующих требованиям стандарта серверов НЕДОПУСТИМО предлагать начинающиеся с отличных от X символов расширения сервиса, если они не зарегистрированы.
Имена дополнительных команд и параметров подчиняются тем же правилам, что используются для ключевых значений EHLO; в частности, команды, начинающиеся с X, являются локальным расширением и могут использоваться без регистрации и стандартизации. И наоборот, все команды, которые начинаются с символов, отличных от X, должны регистрироваться.
2.2.3. Дополнительные вопросы, связанные с расширениями
Допускаются расширения, которые могут существенно изменять базовые операции SMTP. Текст в остальных параграфах данного документа следует трактовать с учетом этого обстоятельства. В частности, расширения могут изменять минимальные пределы, указанные в параграфе 4.5.3, отменять требование по использованию набора символов ASCII, упомянутое выше, или вводить некие дополнительные режимы обслуживания сообщений.
В частности, если расширение предполагает, что на пути доставки обычно поддерживаются особые возможности данного расширения, а промежуточная система SMTP определеяет, что на следующем этапе такие возможности не поддерживаются, эта система МОЖЕТ выбрать с учетом конкретного расширения и обстоятельств попытку более поздней доставки и/или выбора другого хоста MX. При использовании такое стратегии тайм-аут возврата к формату без расширения (если таковой имеется) СЛЕДУЕТ задавать меньше обычного тайм-аута, используемого для возврата почты в случае невозможности доставки (например, если обычный тайм-аут составляет три дня, тайм-аут для попытки передачи почты без использования расширения может составить один день).
2.3. Терминология SMTP
2.3.1. Почтовые объекты
Протокол SMTP обеспечивает транспортировку объектов электронной почты. Каждый объект состоит из конверта (envelope) и содержимого.
Конверт SMTP передается как серия протокольных элементов SMTP (см. главу 3). Конверт содержит адрес отправителя (по которому должны возвращаться отчеты об ошибках) и один или более адресов получателей, а также дополнительную информацию для расширений протокола. В силу исторических причин возможно использование вариаций задания адреса возврата (адреса отправителя) в команде MAIL для указания альтернативных режимов доставки; использование таких вариаций в настоящее время осуждается (см. Приложение F и параграф F.6).
Содержимое SMTP передается в виде протокольного элемента SMTP DATA и состоит из двух частей — заголовков и тела. Если содержимое соответствует другим современным стандартам, заголовок состоит из набора полей, каждое из которых включает имя заголовка, двоеточие (;) и данные, структурированные в соответствии со спецификацией формата сообщения (RFC 5322 [4]); тело сообщения, при наличии в нем структуры, соответствует спецификации MIME (RFC 2045 [21]). Содержимое является текстовым по своей природе и выражается с использованием набора символов US-ASCII [6]. Хотя расширения SMTP (типа 8BITMIME, RFC 1652 [22]) могут обходить это ограничение для содержимого, заголовки всегда должны кодироваться с использованием набора символов US-ASCII. Два расширения MIME (RFC 2047 [23] и RFC 2231 [24]) определяют алгоритм представления в заголовках символов, не входящих в US-ASCII, с использованием комбинаций символов набора US-ASCII.
2.3.2. Отправители и получатели
В RFC 821 два хоста, принимающие участие в транзакции SMTP, были описаны как SMTP-sender (отправитель) и SMTP-receiver (получатель). В настоящей спецификации используются иные термины, отражающие сложившуюся практику — SMTP client (иногда просто client) и SMTP server (или просто server) для отправителя и получателя, соответственно. Поскольку в режиме трансляции один хост может выступать в качестве клиента и сервера, продолжается использование терминов «получатель» (receiver) и «отправитель» (sender) там, где это нужно для понимания.
2.3.3. Почтовые агенты и хранилища сообщений
В данной спецификации используется современная терминология, устоявшаяся с момента публикации RFC 821. В частности, клиенты и серверы SMTP обеспечивают почтовый транспортный сервис и, следовательно, называются «агентами доставки почты» — АДП (Mail Transfer Agent или MTA). Пользовательские почтовые агенты — ППА (Mail User Agent, MUA или UA) выступают в качестве исходных отправителей и конечных получателей почтовых сообщений. На стороне отправителя ППА может собирать почту от пользователя для передачи ее АДП; агент АДП на стороне получателя передает почту ППА (по крайней мере, передает этому агенту ответственность за доставку почты; например, помещая ее в «почтовое хранилище» — message store). Однако, хотя эти термины достаточно точно выражают суть и применимы к другим средам, границы между ППА (MUA) и АДП (MTA) определены недостаточно четко. Следовательно, читатель должен внимательно относиться к терминологии.
2.3.4. Хост
В рамках данной спецификации термин «хост» обозначает компьютерную систему, подключенную к Internet (или, в некоторых случаях, к частной сети TCP/IP) и поддерживающую протокол SMTP. Хосты обозначаются именами (см. следующий параграф); НЕ СЛЕДУЕТ использовать для идентификации хостов полные адреса (см. параграф 4.1.2).
2.3.5. Доменные имена
Доменное имя (или просто домен) состоит из одной или нескольких разделенных точками компонент. В случае использования в качестве адреса домена верхнего уровня, строка доменного имени не содержит точек. Это ведет к возникновению требования, более подробно рассмотренного ниже, об использовании при транзакциях SMTP в публичной сети Internet только полных доменных имен (FQDN), что особенно важно при использовании доменов верхнего уровня. Компоненты доменных имен (метки в терминах DNS RFC 1035 [2]) при транзакциях SMTP могут содержать только последовательности букв, цифр, дефиса (-) и знака подчеркивания (_) из набора символов ASCII [6]. Доменные имена используются для обозначения хостов и других объектов иерархии доменных имен. Например, доменное имя может указывать на псевдоним (метка CNAME RR) или метку записи MX (Mail exchanger), которая будет использоваться для доставки почты вместо представленного имени хоста. Дополнительные сведения о доменных именах можно найти в RFC 1035 [2] и разделе 5 данной спецификации.
Доменное имя, как описано в данном документе и RFC 1035 [2], представляет собой полное имя (fully-qualified domain name или FQDN). Доменные имена, не являющиеся FQDN, есть ни что иное, как локальные псевдонимы. В транзакциях SMTP появление локальных псевдонимов НЕДОПУСТИМО.
При использовании доменных имен в SMTP допускаются только полные (FQDN), преобразуемые DNS имена. Иными словами, разрешено использовать имена, которые могут быть преобразованы в записи MX RR или адреса (RR типа A или AAAA, как сказано в разделе 5), а также CNAME RR, псевдонимы которых могут быть преобразованы в MX или адреса. Локальные псевдонимы и неполные имена использовать НЕДОПУСТИМО. Указанное правило имеет два исключения:
доменное имя, указываемое в команде EHLO должно быть основным именем хоста (именем, преобразуемым в адрес) или, если у хоста нет имени, полным адресом, описанным в параграфе 4.1.3 и дополнительно рассмотренным при обсуждении команды EHLO в параграфе 4.1.4;
зарезервированное имя почтового ящика postmaster может использоваться в команде RCPT без полного доменного имени (см. параграф 4.1.1.3) и, в случае такого использования, должно приниматься.
2.3.6. Буфер и таблица состояний
Сессии SMTP имеют разные состояния и обе стороны аккуратно поддерживают общее представление о текущем состоянии сессии. В этом документе мы будем представлять это состояние виртуальным буфером и таблицей состояний на сервере, которые могут использоваться клиентом (например, клиент может очистить буфер, сбросить таблицу состояния — в результате чего информация из буфера удаляется, а таблица переходит в некое начальное состояние).
2.3.7. Команды и отклики
Команды SMTP и (если расширение сервиса не задает иного) данные сообщений передаются от отправителя к получателю через коммуникационный канал в форме строк.
Отклик SMTP представляет собой подтверждение (или отказ), передаваемое в форме строк от получателя к отправителю через коммуникационный канал в ответ на полученную команду. Общей формой отклика является цифровой код результате (отказ или успешное завершение), за которым обычно следует текстовая строка. Коды служат для использования программами, а текст обычно предназначен для человека. В RFC 3463 [25] содержится спецификация дополнительного структурирования текстовых строк, включая использование дополнений и более специфических кодов завершения (см. также RFC 5248 [26]).
2.3.8. Строки
Строка состоит из некоторого (возможно, нулевого) числа символов данных и завершается символами ASCII для возврата каретки (CR - 0Dh) и перевода строки (LF - 0Ah). Последовательность завершения строки в этом документе будет обозначаться <CRLF>. Для реализаций, соответствующих требованиям данной спецификации, НЕДОПУСТИМО принимать или генерировать в качестве завершения строки любые другие символы или последовательности символов. Серверы МОГУТ вносить ограничения на длину строк (см. раздел 4).
В дополнение отметим, что использование в тексте отдельных символов CR или LF (не в комбинации <CRLF>) имеет долгую историю проблем в реализациях почтовых систем и приложениях, работающих с электронной почтой. Для клиентов SMTP НЕДОПУСТИМА передача этих символов за исключением тех случаев, когда комбинация символов служит для завершения строки, а в этом случае ДОЛЖНА применяться только стандартная последовательность <CRLF>.
2.3.9. Содержимое сообщения и почтовые данные
Термины «содержимое сообщения» (message content) и «почтовые данные (mail data) в этом документе являются взаимозаменяемыми и служат для обозначения информации, передаваемой после восприятия команды DATA до завершения передачи. Содержимое сообщения включает заголовки и (возможно структурированное) тело сообщения. Спецификация MIME (RFC 2045 [21]) обеспечивает стандартные механизмы структурирования тела сообщений.
2.3.10. Отправитель, система доставки, транслятор, шлюз
В данной спецификации различаются четыре типа систем SMTP на основе выполняемых ими функций передачи электронной почты. Система-отправитель (SMTP originator) вносит сообщение в Internet или, в более общем случае, в среду транспортного сервиса. Система доставки (delivery) SMTP принимает почту от транспортного сервиса и передает ее пользовательскому почтовому агенту или размещает в хранилище сообщений, из которого пользовательский агент может взять почту впоследствии. Транслятор (relay) SMTP получает почту от клиента SMTP и передает ее другому серверу SMTP (для доставки или следующей трансляции) без изменения данных, добавляя лишь трассировочную информацию в заголовок.
Шлюзами (gateway) SMTP называют системы, получающие почту от клиентов из одной транспортной среды и передающие ее серверу другой среды. Различия в протоколах и семантике сообщения по разные стороны шлюза могут потребовать преобразования, которое не может быть выполнено трансляторами SMTP. В контексте данной спецификации межсетевые экраны (firewall), переписывающие адреса, следует рассматривать как шлюзы, даже если по обе стороны экрана используется среда SMTP (см. RFC 2979 [27]).
2.3.11. Почтовый ящик и адрес
В данной спецификации термин «адрес» означает текстовую строку, идентифицирующую пользователя, которому предназначено сообщение, или место, в котором почта будет сохранена. Термин «почтовый ящик» (mailbox) обозначает место хранения почты. Обычно эти термины взаимозаменяемы, если не имеет значения разница между местом хранения почты (почтовый ящик) и ее конкретным получателем (адрес). Адрес обычно состоит из пользовательской и доменной части. Стандартные соглашения об именах почтовых ящиков предполагают использование формата local-part@domain — современная терминология поддерживает значительно более широкий спектр применений, нежели просто имена пользователей. По этой причине, а также в результате исторической проблемы, связанной с попытками промежуточных хостов менять локальную часть адреса в целях оптимизации, эта часть адреса ДОЛЖНА интерпретироваться только хостом, указанным в доменной части адреса.
2.4. Общие синтаксические принципы и модель транзакции
Команды и отклики SMTP подчиняются жестким синтаксическим правилам. Все команды начинаются с «командного глагола» (command verb), а все отклики — с 3-значного цифрового кода. В некоторых командах и откликах за командой или кодом должны следовать аргументы. Некоторые команды не принимают аргументов (после команды), а за некоторыми кодами откликов может следовать произвольный текст. Во всех случаях присутствия текста он отделяется от команды или кода символом пробела. Полные описания команд и откликов приведены в разделе 4.
Регистр символов в командах и значениях аргументов не имеет значения (т. е., TO: и to: в команде RCPT не различаются), однако это правило имеет исключения для локальной части названия почтового ящика (расширения SMTP могут явно указывать чувствительные к регистру символов элементы). Команды, значения аргументов (кроме локальной части имени почтового ящика) и свободный текст МОГУТ содержать произвольную комбинацию символов верхнего и нижнего регистра. Для локальной части имен почтовых ящиков регистр символов ДОЛЖЕН приниматься во внимание. Следовательно, реализации SMTP ДОЛЖНЫ пытаться сохранить регистр символов в локальной части имени почтового ящика. В частности, для некоторых хостов пользователь smith может отличаться от пользователя Smith. Однако использование чувствительных к регистру локальных частей в именах почтовых ящиков снижает уровень интероперабельности — следует избегать такого применения локальных имен. Домены в почтовых адресах сответствуют обычным правилам DNS и, следовательно, не чувствительны к регистру символов.
Некоторые серверы SMTP в нарушение данной спецификации (и RFC 821) требуют от клиентов представления команд в верхнем регистре. В реализациях МОГУТ приниматься меры для представления команд в соответствии с требованиями таких серверов.
Поле аргументов содержит текстовую строку переменной длины, заканчивающуюся символами <CRLF>. Принимающая сторона не будет предпринимать никаких действий до получения стандартного завершения строки.
Синтаксис каждой команды рассматривается ниже вместе с описаниями команд. Общие элементы и параметры рассмотрены в параграфе 4.1.2.
Команды и отклики состоят из символов ASCII [6]. Когда транспортный сервис обеспечивает 8-битовый (байты или октеты) канал передачи, каждый 7-битовый символ передается с выравниванием по правому краю (старший бит октета имеет нулевое значение). Стандартный сервис SMTP обеспечивает поддержку только 7-битовых символов. Клиенту-отправителю SMTP, который не смог согласовать подходящее расширение с сервером (см. следующий параграф), НЕДОПУСТИМО передавать сообщения, содержащие информацию в старших битах октетов. Если в нарушение этого правила такое сообщение передается, принимающий сервер SMTP МОЖЕТ сбросить старший бит или отвергнуть сообщение как некорректное. В общем случае транслятору SMTP СЛЕДУЕТ предполагать, что содержимое принятого сообщения корректно и, в предположении что конверт позволяет это сделать, транслировать сообщение без проверки его содержимого. Конечно, если содержимое некорректно и путь передачи не может его воспринять, такое решение может привести к доставке конечному адресату искаженного сообщения. Системы доставки SMTP могут отвергать такие сообщения или возвращать их, как недоставляемые, вместо попытки доставки. В отсутствии предлагаемого сервером расширения, явно позволяющего делать это, никаким передающим системам SMTP не дозволяется передавать envelope-команды, содержащие символы, не включенные в набор US-ASCII; принимающим системам следует отвергать такие команды, используя стандартный отклик 500 syntax error - invalid character.
Клиент может запросить у сервера передачу 8-битового содержимого сообщений с использованием расширенных возможностей SMTP, прежде всего 8BITMIME RFC 1652 [22]. Серверам SMTP следует поддерживать режим 8BITMIME. Однако это недопустимо трактовать, как разрешение на неограниченную передачу 8-битовых символов и не позволяет передавать в конвертах сообщений символы, отличные от ASCII. Для отправителя недопустимо запрашивать режим 8BITMIME при передачи данных, где в качестве старшего бита не используется соответствующий формат MIME с подходящим транспортным кодирование; серверы могут отвергать такие сообщения.
Используемая в этом документе металингвистическая нотация соответствует нотации Augmented BNF, принятой в документах других почтовых систем Internet. Читателям, которые незнакомы с этим синтаксисом, следует прочесть спецификацию ABNF в RFC 5234 [7]. Для ясности термины метаязыка, используемые в тексте, обозначены угловыми скобками (например, <CRLF>). Читателям следует отдавать отчет в том, выражения метаязыка могут быть неполными. Имеется множество случаев, когда представленная в тексте информация ограничивает или иначе меняет синтаксис или семантику метаязыка.
