RFC: 5321
Оригинал: Simple Mail Transfer Protocol
Предыдущие версии: RFC 772, RFC 780, RFC 788, RFC 821, RFC 974, RFC 1425, RFC 1651, RFC 1869, RFC 2821
Категория: Проект стандарта
Дата публикации:
Автор:
Перевод: Николай Малых

4.2. Отклики SMTP

Отклики на команды 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 / address-literal)
              [ SP textstring ] CRLF ) /
              ( "220-" (Domain / address-literal)
              [ SP textstring ] CRLF
              *( "220-" [ textstring ] CRLF )
              "220" [ SP textstring ] CRLF )

textstring    = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII

Reply-line    = *( Reply-code "-" [ textstring ] CRLF )
              Reply-code [ SP textstring ] CRLF

Reply-code    = %x32-35 %x30-35 %x30-39

где Greeting появляется только в откликах с кодом 220, анонсирующих открытие сервером своей части соединения. Другие возможные варианты откликов сервера на открытие соединения следуют синтаксису Reply-line.

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

Клиенты SMTP должны определять свои действия только на основе кода отклика, а не его текста (за исключением "change of address" 251 и 551, а при необходимости и 220, 221, 421). В общем случае клиент должны воспринимать любой текст и отклики без текста (хотя серверам не следует передавать откликов, содержащих только код). Пробел после кода отклика рассматривается как часть текста. По возможности клиенту SMTPSMTPSMTPSMTP следует проверять первую цифру кода отклика (индикация важности).

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

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

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