RFC: 5321
Оригинал: Simple Mail Transfer Protocol
Предыдущие версии: RFC 772, RFC 780, RFC 788, RFC 821, RFC 974, RFC 1425, RFC 1651, RFC 1869, 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).

2007 - 2017 © Русские переводы RFC, IETF, ISOC.