3.3. Почтовые транзакции
Почтовая транзакция SMTP состоит из трех этапов. Началом транзакции служит команда MAIL, дающая идентификацию отправителя (в общем случае команда MAIL может быть введена только при отсутствии незавершенных почтовых транзакций; см. параграф 4.1.4.). После этого следует одна или несколько команд RCPT, указывающих получателей сообщения. Последний этап транзакции начинается командой DATA, которая инициирует передачу почтовых данных и завершается индикатором end of mail, который также подтверждает транзакцию.
Первым этапом транзакции является команда MAIL.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
Эта команда говорит получателю SMTP о начале новой почтовой транзакции и сбрасывает все таблицы состояний и буферы, включая любые данные получателя или почтовые данные. Часть <reverse-path> (обратный путь) первого или единственного аргумента команды содержит название почтового ящика отправителя (между скобками < и >), которое может использоваться для передачи отчетов об ошибках (см. параграф 4.2). Восприняв команду, сервер SMTP возвращает отклик 250 OK. Если указанный почтовый ящик по каким-то причинам неприемлем, сервер должен возвратить отклик, показывающий временной тип отказа — постоянная (т. е., повторится при повторе команды клиентом) или временная (т. е., адрес клиента может быть принят при следующем вызове) ошибка. Несмотря на очевидность этого требования, существуют обстоятельства, при которых возможность восприятия обратного пути невозможно определить, пока не будет получен по крайней мере один прямой путь (в команде RCPT). В таких случаях сервер может воспринять обратный путь (отклик 250) и сообщить о возникновении проблем после получения и проверки прямых путей. Обычно это делается с помощью откликов 550 или 553.
Исторически <reverse-path> может содержать больше данных, нежели просто имя почтового ящика, но современным системам не следует использовать маршрутизацию почты отправителем — source routing (см. Приложение C).
Дополнительные параметры <mail-parameters> связываются с согласованным расширением сервиса SMTP (см. 2.2).
Вторым этапом транзакции является команда RCPT. Данный этап может повторяться много раз.
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
Первый или единственный аргумент этой команды включает прямой путь forward-path (обычно имя почтового ящика и домена, обязательно заключенные в скобки <>), идентифицирующий получателя. Восприняв команду, сервер SMTP возвращает отклик 250 OK и сохраняет прямой путь. Если известно, что почта не может быть доставлена адресату, сервер SMTP возвращает отклик 550, обычно сопровождаемый строкой типа "no such user - " с именем почтового ящика, для которого невозможна доставка (возможны также другие обстоятельства и коды возврата).
Параметр <forward-path> может содержать не только адрес получателя. Исторически <forward-path> может включать маршрут (source routing) к получателю в виде списка промежуточных хостов, однако современным клиентам SMTP не рекомендуется использовать маршрутизацию почты отправителем (см. Приложение C). Сервер должен быть готов к восприятию списка source route в прямом пути, но рекомендуется игнорировать эти маршруты и можно отклонять предлагаемую таким маршрутом трансляцию. Подобно этому, сервер может отказаться от приема почты, предназначенной для других хостов или систем. Эти ограничения делают сервер бесполезным в качестве транслятора для клиентов, не полностью поддерживающих функциональность SMTP. Следовательно, для клиентов с ограниченными возможностями недопустимо предполагать, что любой SMTP-сервер в Internet можно использовать для обработки (трансляции) почты. Если команда RCPT принята без предшествующей команды MAIL, сервер должен возвращать отклик 503 "Bad sequence of commands". Дополнительные параметры <rcpt-parameters> связываются с согласованным расширением сервиса SMTP (см. параграф 2.2).
Поскольку такая ошибка встречается достаточно часто, подчеркнем, что не допускается включение пробелов с любой стороны от знака двоеточия (:) после FROM в команде MAIL или после TO в команде RCPT. Точный синтаксис показан выше.
Третьим этапом транзакции является команда DATA (или соответствующая команда протокольного расширения).
DATA <CRLF>
Восприняв команду, сервер SMTP возвращает промежуточный отклик 354 Intermediate и рассматривает все последующие строки, вплоть (но не включая) до индикатора завершения почтовых данных, как текст сообщения. При успешном приеме всего текста сервер сохраняет полученные данные и возвращает отправителю отклик 250 OK.
Поскольку почтовые данные передаются через коммуникационный канал, завершение данных должно быть указано таким образом, чтобы можно было возобновить командный диалог. Протокол SMTP использует для обозначения конца почтовых данных точку в пустой строке. Для предотвращения ошибок при наличии такой последовательности в пользовательских данных применяется специальная процедура (transparency), описанная в параграфе 4.5.2.
Индикатор завершения почтовых данных также подтверждает почтовую транзакцию и говорит серверу SMTP, что нужно обрабатывать сохраненные пользовательские и почтовые данные. Восприняв данные, сервер SMTP возвращает отклик 250 OK. Сбой при обработке команды DATA может происходить только на двух этапах обмена данными.
Если команды MAIL и RCPT не были введены или были отвергнуты, сервер может возвращать отклик command out of sequence (503) или no valid recipients (554 — нет корректных получателей) в ответ на команду DATA. При получении одного из таких откликов (или любого отклика 5yz) для клиента недопустима передача данных серверу (точнее, передача данных недопустима, пока не будет получен отклик 354).
Если команда воспринята и передан отклик 354, невыполнение команды DATA может быть связано только с неполнотой почтовой транзакции (например, не указан адресат), недоступностью ресурсов (включая и неожиданнуюнедоступность сервера) или отказом сервера от обработки сообщения в соответствии с заданной политикой или по иным причинам.
Однако на практике некоторые серверы не проверяют адресата после приема текста сообщения. Таким серверам следует трактовать отказ для одного или нескольких получателей как «отказ обусловленный другим отказом» (subsequent failure) и возвращать почтовое сообщение, как указано в главе 6 и, в частности, в параграфе 6.1. Использование отклика 550 mailbox not found (или его эквивалента) после восприятия данных делает для клиента сложной или невозможной диагностику причины отказа.
При использовании формата RFC 822 ([28], [4]) почтовые данные включают элементы заголовка, такие как Date, Subject, To, Cc, From. Серверам SMTP не рекомендуется отвергать сообщения на основе дефектов в заголовках RFC 822 и MIME (RFC 2045 [21]) или в теле сообщения. В частности, недопустимо отвергать сообщения, в которых число полей Resent не соответствует или Resent-to появляется без Resent-from и/или Resent-date.
Команды почтовых транзакций должны использоваться в приведенном выше порядке.