SMTP (Simple Mail Transfer Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:28, 23 января 2019.
SMTP
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Назначение протокола: Отправка электронной почты
Спецификация: RFC 5321
Основные реализации (клиенты): MUA (The Bat!, MS Outlook, MS Outlook Express, Mozilla Thunderbird, Claws Mail и др.)
Основные реализации (серверы): MTA (sendmail, postfix, OpenSMTPD, qmail, exim, Microsoft Exchange Server, MDaemon)
Расширяемость: Доп. команды (RFC 2449)
Вступил в силу с: 1982
SMTP (англ. Simple Mail Transfer Protocol) – протокол передачи сообщений с компьютера на почтовый сервер для доставки конечному получателю. Этот протокол обеспечивает перенаправление почтовых сообщений (с помощью записей MX, или записей программы обмена электронной почтой, и записей А, или записей хоста в системе DNS), форматирование почтовых сообщений и установление сеансов между почтовыми клиентами и почтовыми серверами. В протоколе SMTP в качестве транспортного протокола обычно используется TCP, но могут применяться и другие протоколы, как определено в документе RFC 821.

История

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

В 1971 г. появился Mail Box Protocol и SNDMSG, который был «изобретён» Рэем Томлинсоном из BBN Technologies для TOPS-20/TENEX-компьютеров, посылающих сообщения по ARPANET (в то время к ней были подсоединены менее 50 хостов). Данный протокол можно считать истоком протокола SMTP.

SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321 (2008) включает масштабируемое расширение – ESMTP (англ. Extended SMTP). В настоящее время под «протоколом SMTP», как правило, подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием порта TCP 25.

Архитектура

Рисунок 1 – Схема взаимодействия по протоколу SMTP

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

Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течении нескольких секунд после отправки. [Источник 1]

Принцип работы

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

Но в спецификации SMTP определен формат электронной почты и указано, какие наборы символов могут применяться в сообщениях электронной почты. Первоначально в спецификации SMTP было определено использование только 7-битовых символов ASCII. Но с появлением [MIME (Multipurpose Internet Mail Extensions)|стандарта многоцелевых почтовых расширений Internet (Multipurpose Internet Mail Extensions – MIME)]] и превращением Internet во всемирную сеть было предложено включить в дополнительные спецификации другие наборы символов. Благодаря этому в настоящее время электронное письмо может быть отправлено практически на любом национальном языке, а к письму могут прилагаться в закодированном виде данные почти любого типа, даже такие как изображения или исполняемые файлы. После внедрения всех этих дополнений протокол SMTP стал более сложным, но вместе с тем и более гибким.

Задачи

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры Mail Forwarding, проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней - его закрытие.

Команды SMTP указывают серверу, какую операцию хочет произвести клиент. Команды состоят из ключевых слов, за которыми следует один или более параметров. Ключевое слово состоит из 4-х символов и разделено от аргумента одним или несколькими пробелами. Каждая командная строка заканчивается символами CRLF. Вот синтаксис всех команд протокола SMTP (SP - пробел):

 HELO <SP> <domain> <CRLF>
 MAIL <SP> FROM:<reverse-path> <CRLF> 
 RCPT <SP> TO:<forward-path> <CRLF> 
 DATA <CRLF>
 RSET <CRLF> 
 SEND <SP> FROM:<reverse-path> <CRLF> 
 SOML <SP> FROM:<reverse-path> <CRLF> 
 SAML <SP> FROM:<reverse-path> <CRLF> 
 VRFY <SP> <string> <CRLF> 
 EXPN <SP> <string> <CRLF> 
 HELP <SP> <string> <CRLF> 
 NOOP <CRLF> 
 QUIT <CRLF>

Обычный ответ SMTP сервера состоит из номера ответа, за которым через пробел следует дополнительный текст. Номер ответа служит индикатором состояния сервера.[Источник 2]

Команды

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

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

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

Конец строк в протоколе SMTP обозначается последовательностью символов "возврат каретки" (шестнадцатеричный код 0 D ) и "перевод строки" (шестнадцатеричный код 0А). Эта последовательность обозначается CRLF. Сервер начинает выполнение команды только получив от клиента строку, завершающуюся последовательностью CRLF.

Сервера SMTP должны принимать командные строки длинной до 512 символов. Это значение может быть увеличено по желанию разработчиков. Для серверов, поддерживающих расширения ESMTP, требующие дополнительных параметров, максимально допустимая длина командной строки увеличивается. Соответствующие требования приведены в RFC, описывающих эти расширения.

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

Рассмотрим команды SMTP, необходимые для отправки сообщения.

EHLO (Расширенное HELO)

Формат команды:

EHLO полное_доменное_имя_клиента CRLF

или

EHLO адрес_отправителя CRLF

Диалог клиента и сервера, как правило, начинается с приветствия. В RFC 821 в качестве приветствия предлагалась команда HELO. Однако с введением расширений ESMTP, эта команда была заменена на EHLO. Использование расширений ESMTP возможно только после выполнения команды EHLO.

Передача почты возможна только после выполнения одной из двух названых команд. Другие команды, не связанные с передачей почты ( NOOP, HELP, EXPN, VRFY, RSET и QUIT ), в принципе могут быть исполнены и без приветствия.

В качестве аргумента клиент передает серверу свое полное доменное имя, если таковое имеется. Если клиент не имеет доменного имени, например, если в качестве клиента выступает MUA, установленный на компьютере, получающем адрес динамически, то в качестве аргумента передается адрес электронной почты отправителя. Желательно, чтоб полученная от клиента информация была исчерпывающей для его идентификации.

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

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

Если устаревшее программное обеспечение сервера не поддерживает команду EHLO, то выдается сообщение об ошибке. В этом случае клиент должен попытаться повторить приветствие, используя команду HELO. Естественно, расширениями ESMTP уже не удастся воспользоваться.

HELO (Приветствие)

Формат команды:

HЕLO полное_доменное_имя_клиента CRLF

или

HЕLO адрес_отправителя CRLF

RFC 2821 рекомендует использовать команду HELO, только если программное обеспечение не поддерживает команду EHLO. Отличие этой команды только в том, что она делает невозможным использование расширений ESMTP.

В ответ на эту команду сервер сообщает, готов ли он к продолжению диалога.

MAIL (Отправитель)

Формат команды:

MAIL FROM : адрес_отправителя дополнительные_параметры CRLF

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

Команда MAIL может быть выполнена только после успешного выполнения команды EHLO или H E LO.

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

MAIL FROM : <> CRLF

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

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

Базовый протокол SMTP не предусматривает дополнительных параметров для команды MAIL, но такие параметры использует ряд расширений ESMTP.

RCPT (Получатель)

Формат команды:

RCPT TO: адрес_получателя дополнительные_параметры CRLF

Доставка сообщения возможна, только если указан хотя бы один доступный адрес получателя. Команда RCPT принимает в качестве аргумента только один адрес. Если нужно послать письмо большему числу адресатов, то команду RCPT следует повторять для каждого. Согласно RFC 2821, сервера SMTP должны быть готовы принять до ста команд RCPT на одно сообщение. Если письмо адресовано большему числу получателей, то для оставшихся клиент должен передать сообщение повторно. Максимальное число получателей может быть изменено администратором.

Команда RCPT может быть выполнена только после успешного выполнения команды MAIL.

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

Базовый протокол SMTP не предусматривает дополнительных параметров для команды RCPT, но такие параметры использует ряд расширений ESMTP.

DATA (Текст сообщения)

Формат команды:

DATA CRLF

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

Команда DATA может быть выполнена только после успешного выполнения хотя бы одной команды RCPT.

Команда DATA не требует никаких параметров и завершается последовательностью CRLF.

В ответ на правильно введенную команду DATA сервер сообщает о готовности к приему или об ошибке, если прием сообщения невозможен.

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

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

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

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

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

QUIT (Выход)

Формат команды:

QUIT CRLF

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

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

HELP (Помощь)

Формат команды:

HELP команда CRLF

или

HELP CRLF

Если команда HELP вызывается без параметров, сервер посылает клиенту список доступных команд. Если в качестве параметра передано название команды, то клиенту посылается описание этой команды. Серверам SMTP рекомендуется поддерживать эту команду без параметров. Описание отдельных команд посылать не обязательно.

VRFY (Проверить), EXPN (Раскрыть)

Формат команд:

VRFY адрес CRLF

EXPN адрес CRLF

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

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

Для получения адресов, внесенных в список рассылки, используется команда EXPN.

Используя эти команду, злоумышленники могут получить список адресов пользователей сервера.

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

Согласно RFC 821, команды VRFY и EXPN не являются обязательными. Поэтому, если сервер их поддерживает, они должны быть перечислены в ответе сервера на команду EHLO, как расширения ESMTP.

NOOP (Пустая команда)

Формат команды:

NOOP параметры CRLF

В ответ на команду NOOP сервер посылает подтверждение выполнения. Никаких действий на сервере не производится, параметры команды игнорируются.

RSET (Сброс)

Формат команды:

RSET CRLF

Команда RSET аннулирует все переданные до нее на сервер данные. Процесс передачи сообщения следует начать заново.

SEND, SOML, SAML (Передача сообщения на терминал пользователя)

Формат команд:

SEND FROM: адрес_отправителя CRLF

SOML FROM: адрес_отправителя CRLF

SAML FROM: адрес_отправителя CRLF

Перечисленные команды используются вместо команды MAIL для передачи сообщения на терминал получателя (SEND) или в его почтовый ящик, если пользователь не активен или запретил прием сообщений ( SOML ) или и на терминал, и в почтовый ящик (SAML).

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

TURN (Смена направления передачи)

Формат команды:

TURN CRLF

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

Команда TURN представляет потенциальную опасность, так как она может быть использована для перехвата чужой почты. Потому RFC 2821 категорически не рекомендует ее использовать. Хорошими альтернативами команде TURN являются расширения ESMTP ETRN и ATRN, рассматриваемые ниже.

Ответы сервера SMTP

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

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

Согласно RFC 2821, код ответа состоит из трех цифр. Первая цифра кода может принимать следующие значения:

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

  • Команда выполнена успешно.
  • Промежуточный положительный результат. Команда принята, но сервер ожидает от клиента дополнительные данные для завершения операции. Дополнительными данными может, например, быть текст сообщения в команде DATA.
  • Исполнение команды временно невозможно. Команда не может быть выполнена, но проблема может быть устранена. Клиенту следует попытаться повторить попытку через некоторое время.
  • Исполнение команды невозможно.

Вторая цифра может принимать следующие значения:

  • 0 Синтаксическая ошибка, неправильное или недопустимое использование команды.
  • 1 Ответ содержит запрошенную информацию.
  • 2 Ответ о состоянии канала передачи.
  • 5 Ответ информирует о состоянии принимающей почтовой системы.

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

В таблице ниже собраны ответы, предусмотренные для команд SMTP.

Код Расшифровка Команды
211 Состояние системы HELP
214 Информация об использовании команд HELP
220 Готовность к работе Установление соединения
221 Канал передачи закрыт QUIT
250 Команда выполнена успешно EHLO, HELO, MAIL, RCPT DATA, RSET, VRFY, EXPN, NOOP
251 Почта для данного пользователя переадресована и будет доставлена по новому адресу RCPT, VRFY
252 Команда не будет выполнена, но доставка сообщения возможна. Ответ свидетельствует о том, что выполнение команд заблокировано из соображений безопасности, и не может быть интерпретирован как информация об опрашиваемом почтовом ящике VRFY, EXPN
354 Команда DATA принята, ожидается текст сообщения, заканчивающийся строкой, состоящей из одной точки DATA
421 Служба недоступна, связь прекращается. Ответ выдается при прекращении работы сервера во время сеанса связи Любая
450 Доставка сообщения в данный момент не возможна: почтовый ящик не доступен RCPT
451 Выполнение команды прервано: ошибка сервера MAIL, RCPT, DATA
452 Команда не выполнена: недостаточно памяти MAIL, RCPT, DATA
500 Синтаксическая ошибка, команда не понята (возможно, превышена допустимая длина строки) Несуществующая команда
501 Синтаксическая ошибка в параметрах или аргументах (например, использование параметров в командах, не допускающих параметров) Любая
502 Команда не поддерживается (отключена администратором) VRFY, EXPN, HELP
503 Неправильный порядок команд MAIL, RCPT, DATA
504 Параметр команды не поддерживается EHLO, HELO, VRFY, EXPN, HELP
550 Команда не выполнена: почтовый ящик недоступен (не найден, доступ запрещен, выполнение команды запрещено администратором) EHLO, HELO, MAIL, RCPT, VRFY, EXPN
551 Адрес пользователя изменился RCPT, VRFY
552 Выполнение команды прервано: превышен выделенный объем памяти MAIL, RCPT, DATA
553 Неправильный синтаксис адреса MAIL, RCPT, VRFY
554 Служба SMTP на вызываемой машине не запущена Установление соединения
554 Доставка не может быть осуществлена ни по одному адресу D ATA

В случае переадресации почты допускается также использование ответа 250. В этом случае клиент о переадресации не информируется. Сервер может также отказать в приеме почты для уже не существующего пользователя и послать ответ 551 с указанием нового адреса или ответ 550.[Источник 3]

Источники

  1. Протокол обмена почтой SMTP (Simple Mail Transfer Protocol) // CIT Forum [2001–2015]. Дата изменения: 24.02.1997. URL: http://citforum.ru/nets/services/services0305.shtml (дата обращения: 2.12.2018).
  2. Описание протокола SMTP // CodeNet [2018]. Дата изменения: 14.03.2017. URL: http://www.codenet.ru/webmast/smtp.php (дата обращения: 2.12.2018).
  3. Протокол SMTP // Лаборатория обработки и передачи данных [2018]. Дата изменения: 04.05.2014. URL: http://opds.sut.ru/old/electronic_manuals/mail/3_SMTP.htm#3_1_12 (дата обращения: 2.12.2018).