Простой протокол электронной почты (SMTP — Simple Mail Transfer Protocol)
Протокол SMTP был разработан для обмена почтовыми сообщениями в сети Internet. SMTP не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и Х.25.
SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321 (2008) включает масштабируемое расширение — ESMTP (англ. Extended SMTP). В настоящее время под «протоколом SMTP», как правило, подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием порта TCP 25.
Взаимодействие в рамках SMTP строится по принципу двусторонней связи, которая устанавливается между отправителем и получателем почтового сообщения. При этом отправитель инициирует соединение и посылает запросы на обслуживание, а получатель - отвечает на эти запросы. Фактически, отправитель выступает в роли клиента, а получатель - сервера.
Когда сессия открыта, сервер и клиент обмениваются её параметрами. Сессия может включать ноль и более SMTP-операций (транзакций).
SMTP-операция состоит из трёх последовательностей команда/ответ:
MAIL FROM — устанавливает обратный адрес (т. е. Return-Path, 5321.From, mfrom). Это адрес для возвращённых писем.
RCPT TO — устанавливает получателя данного сообщения. Эта команда может быть дана несколько раз, по одному на каждого получателя. Эти адреса также являются частью оболочки.
DATA — для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделенных пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо.
Команды и отклики
SMTP использует команды и отклики для передачи сообщения между почтовыми агентами (MTA) клиента и сервера.
Команды
Команду посылают от клиента к серверу. Она содержит ключевое слово и следующие за ним ноль или более аргументов. В SMTP определяется 14 команд. Первые пять — обязательные команды; любая реализация почты должна поддерживать эти пять команд. Следующие три часто используются и очень рекомендуются. Последние шесть команд применяются редко. Команды перечислены в таблице 14.1 и ниже рассмотрены более детально.
| Ключевое слово | Аргумент(ы) |
| HELLO | Имя хоста отправителя |
| MAIL FROM | Отправитель сообщения |
| RCPT TO | Предназначенный получатель сообщения |
| DATA | Содержание (тело сообщения) |
| QUIT | Завершение соединения |
| RSET | Прерывание текущего действия |
| VRFY | Проверяемое имя получателя |
| NOOP | Проверка состояния получателя |
| TURN | Смена положения отправителя и получателя (в настоящее время не используется) |
| EXPN | Почтовый список расширения |
| HELP | Имя команды |
| SEND FROM | Предназначенный получатель сообщения |
| SMOL FROM | Предназначенный получатель сообщения |
| SMAL FROM | Предназначенный получатель сообщения |
· HELLO. Эта команда используется клиентом для идентификации самого себя. Аргумент — доменное имя хоста клиента.
· MAIL FROM. Эта команда используется клиентом для идентификации отправителя сообщения. Аргумент содержит адрес отправителя электронной почты (локальную часть и доменное имя).
MAIL FROM: berlin@sut.ru
· RCPT. Команда используется клиентом для идентификации получателя сообщения. Аргумент — адрес электронной почты получателя. Если имеется много получателей, команда повторяется. Формат показан ниже.
RCPT TO: jenifer@edu.com
· DATA. Команда используется для посылки реального сообщения. Все строки, следующие за символами, рассматриваются как почтовое сообщение.
· DATA
· Этим письмом я подтверждаю
свое согласие на издание книги.
· QUIT. Команда, завершающая соединение. Ее формат:
QUIT
· RSET. Команда (reset), прерывающая текущее действие почты. Накопленная информация об отправителе и получателе удаляется.
· VRFY. Команда (verify), используемая для верификации адреса получателя, который посылается как аргумент. Отправитель может запрашивать подтверждение получателя, что имя получателя идентифицировано правильно. Ее формат:
VRFY: jenifer@edu.com
· NOOP. Команда (operation), используемая клиентом для проверки состояния получателя. Это требует ответа от получателя. Ее формат:
NOOP
· TURN. Команда позволяет отправителю и получателю перейти в положение, при котором отправитель становится получателем и наоборот. Однако большинство современных реализаций SMTP не поддерживает этой команды. Ее формат:
TURN
· EXPN. Команда (expand) запрашивает хост получателя, чтобы расширить список, как это указано в аргументах, и вернуть адреса почтовых ящиков получателей, которые включаются в этот лист. Ее формат:
EXPN: x,y,z
· HELP. Команда запрашивает получателя, чтобы получить информацию о команде, содержащейся в аргументе. Ее формат:
HELP: mail
· SEND FROM. Команда, определяющая, что почта может быть доставлена терминалу получателя, а не в почтовый ящик. Если получатель не зарегистрирован, то почта возвращается обратно. Аргументом является адрес отправителя. Формат показан ниже:
SEND FROM: berlin@edu.com
· SMOL FROM. Команда (посылается в почтовый ящик или терминал), определяющая, что почта может быть доставлена терминалу или в почтовый ящик получателя. Это означает, что если получатель зарегистрирован, то доставка осуществляется в терминал, если получатель не зарегистрирован — только в почтовый ящик. Аргумент — адрес отправителя. Формат показан ниже:
SMOL FROM: berlin@edu.com
· SMAL FROM. Команда (посылается в почтовый ящик и терминал), определяющая, что почта может быть доставлена терминалу получателя и в почтовый ящик. Если получатель зарегистрирован, почта будет доставлена в почтовый ящик и терминал. Почта доставляется только в почтовый ящик, если отправитель не зарегистрирован. Аргумент — адрес отправителя. Формат показан ниже:
SMAL FROM: berlin@edu.com
Отклики
Отклики посылаются от сервера к клиенту. Отклик содержит три десятичных кода, которые могут дополняться текстовой информацией. Смысл первых цифр следующий:
· 2yz (положительное подтверждение завершения). Первая цифра 2 (цифра 1 сейчас не используется) показывает, что требуемая команда успешно завершена и можно передавать следующую команду.
· 3yz (положительное промежуточное подтверждение). Если первая цифра 3, это означает, что требуемая команда принята, но получатель нуждается в большей информации для завершения обработки.
· 4yz (отрицательное переходное подтверждение). Если первая цифра 4, это означает, что требуемая команда должна быть отклонена, но состояние ошибки временное. Команда может быть передана опять.
· 5yz (отрицательное постоянное подтверждение завершения). Если первая цифра 5, это означает, что требуемая команда должна быть отклонена. Команда не может быть передана повторно.
Вторые и третьи цифры сообщают дополнительные детали об отклике. Табл. 14.2 содержит список некоторых откликов.
| Таблица 14.2. Отклики | |
| Код | Описание |
| Положительное подтверждение завершения | |
| Системное состояние или отклик на справку | |
| Справочное сообщение | |
| Готовность к обслуживанию | |
| Завершение обслуживания передающего канала | |
| Требуемая команда завершена | |
| Пользователь не местный: сообщение должно быть передано далее | |
| Положительное промежуточное подтверждение | |
| Начало ввода почты | |
| Отрицательное переходное подтверждение | |
| Обслуживание не доступно | |
| Почтовый ящик недоступен | |
| Команда прервана: местная ошибка | |
| Команда прервана: недостаточно памяти | |
| Отрицательное постоянное подтверждение завершения | |
| Синтаксическая ошибка: неопознанная команда | |
| Синтаксическая ошибка в параметрах или аргументах | |
| Команда не выполнена | |
| Неправильная последовательность команд | |
| Команда временно не выполнена | |
| Команда не выполнена: почтовый ящик недоступен | |
| Пользователь не местный | |
| Требуемое действие прервано: переполнение местной памяти | |
| Требуемое действие не принято к исполнению: недопустимое имя почтового ящика | |
| Неудавшийся переход |
Фазы передачи почты
Процесс передачи почтовых сообщений осуществляется в три фазы: установление соединения, передача почты и подключение оконечного устройства.
Установление соединения
После того как клиент установит соединение TCP к заранее известному порту 25, сервер SMTP начинает фазу соединения. Эта фаза включает следующие три ступени, которые иллюстрируются на рисунке 14.6.:
Рис. 14.6. Установление соединения
1. Сервер посылает код 220 (Готов к обслуживанию), чтобы сказать клиенту, что он готов принять почту. Если сервер не готов, то он посылает код 421 (Обслуживание не готово).
2. Клиент посылает сообщение HELLO, чтобы идентифицировать себя, используя доменное имя адреса. Этот шаг необходим, чтобы информировать сервер доменного имени клиента. Напомним, что во время установления TCP отправитель и получатель знает друг друга только по IP-адресам.
3. Сервер отвечает кодом 250 – "Требуемая команда завершена" или другим кодом в зависимости от ситуации.
Передача сообщения
После того как соединение будет установлено между SMTP-клиентами и сервером, можно обменяться одиночным сообщением между отправителем и одним или более получателями. Эта фаза включает восемь шагов. Шаги 3 и 4 повторяются, если есть более чем один получатель (рисунке 14.7.).
Рис. 14.7. Передача сообщения
1. Клиент посылает сообщение MAIL FROM, чтобы представить отправителю почтовый адрес отправителя (имя почтового ящика и доменное имя). Этот шаг необходим, чтобы дать серверу адрес для возврата ошибок или для доклада о продвижении сообщений.
2. Сервер отвечает кодом 250 или другим соответствующим кодом.
3. Клиент посылает сообщение RCPT TO (получатель), который включает почтовый адрес получателя.
4. Сервер отвечает кодом 250 или другим соответствующим сообщением.
5. Клиент посылает сообщение DATA, чтобы инициализировать передачу сообщений.
6. Сервер отвечает кодом 354 (Начало ввода почты) или другим подходящим сообщением.
7. Клиент посылает содержание сообщения в виде последовательности строк. Каждая строка завершается двумя символами конец строки (возврат каретки и продвижение на другую линию). Конец сообщения содержит только метку окончания строки.
8. Сервер отвечает кодом 250 или соответствующим кодом.
Окончание соединения
После того как сообщение будет успешно передано, клиент заканчивает соединение. Эта фаза имеет два шага (рис. 14.8.).
Рис. 14.8. Окончание соединения
1. Клиент посылает команду QUIT.
2. Сервер отвечает кодом 221 или соответствующим другим кодом.
3. После фазы окончания соединения TCP-соединение должно быть завершено.
Многоцелевое расширение интернет-почты
Многоцелевое расширение интернет-почты (Multipurpose Internet Mail Extensions – MIME) улучшает возможности протокола SMTP. Этот протокол может посылать в терминалы только 7-битовые форматы в коде ASCII. Другими словами, он имеет ограничения. Например, не могут быть использованы языки, которые не поддерживают 7-битовые символы (французский, немецкий, иврит, русский, китайский, японский). Также нельзя использовать его для посылки двоичных файлов или посылки видео- или аудиоинформации.
Многоцелевое расширение интернет-почты (MIME) — дополняющий протокол, позволяющий передавать сообщения, используя SMTP-данные, которые не имеют вид ASCII. MIME — не почтовый протокол и не отменяет SMTP; он только его расширяет.
MIME преобразовывает данные, отличающиеся от ASCII, к виду ASCII и доставляет их клиенту SMTP через Интернет. Сервер SMTP на приемной стороне получает данные в виде ASCII и доставляет к MIME, чтобы преобразовать данные в первоначальный вид.
Можно упрощенно сказать, что MIME — это набор программного обеспечения, который преобразует данные, не представленные в ASCII, в данные ASCII и, соответственно, наоборот.
MIME определяет пять заголовков, которые могут быть дополнены к исходной секции заголовков SMTP для определения параметров преобразования:
· MIME – Version (MIME – Версия).
· Content – Type (Содержание – Тип).
· Content — Transfer – Encoding (Содержание – Передача – Кодирование).
· Content – Id (Содержание – Идентификатор).
· Content – Description (Содержание — Описание).
Рисунок 14.9. показывает исходный заголовок и расширенный заголовок. Рассмотрим их более детально.
Рис. 14.9. Заголовок MIME
MIME – Version
В заголовке определяется используемая версия многоцелевого расширения. Если текущая версия 1.1, то:
MIME – Version 1.1
Content – Type
Этот заголовок определяет тип данных в используемом информационном блоке сообщения. Тип содержания и подтип содержания разделяется наклонной чертой ("слеш"). В зависимости от подтипа, заголовок может содержать другие параметры.
Content – Type: <type/subtype; parameters>
MIME позволяет семь различных типов данных. Они перечислены в таблице 14.3 и рассмотрены ниже более детально.
| Таблица 14.3. Типы и подтипы MIME | ||
| Тип | Подтип | Описание |
| Текст | Обычный | Неформатированный текст |
| Из многих частей | Смешанный | Информационный блок содержит упорядоченные различные типы данных |
| Параллельный | То же самое, что выше, но неупорядоченное | |
| Обзорный | Похожий на смешанный, но по умолчанию /RFC822* | |
| Альтернативный | Часть различных версий в одинаковом сообщении | |
| Сообщение | RFC822 | Информационный блок включает в себя сообщение |
| Частичный | Информационный – это фрагмент большого сообщения | |
| Внешний блок | Информационный блок является только ссылкой на другое сообщение | |
| Изображение | JPEG | Изображение в формате JPEG |
| GIF | Изображение в формате GIF | |
| Видео | MPEG | Видео в MPEG-формате |
| Аудио | Базовое | Одиночный канал кодированной речи на 8 кГц |
| Прикладной текст | PostScript | Язык описаний страниц, разработанный фирмой Adobe Systems |
| Поток октетов | Двоичные данные общего вида (восьмибитовые байты) |
Доставка почты
Доставка почты от отправителя к получателю проходит через три стадии (рис. 14.12.).
Рис. 14.12. Использование POP3 и IMAP
Первая стадия
На первой стадии электронная почта проходит через пользовательского агента в локальный сервер. Почта, возможно, сразу не посылается на удаленный сервер, поскольку он может быть недоступен к этому моменту. Поэтому почта накапливается в локальном сервере, пока ее не удастся отправить. Пользовательский агент использует программное обеспечение SMTP-клиента, локальный сервер использует программное обеспечение SMTP-сервера.
Вторая стадия
На втором шаге электронная почта идет с помощью локального сервера, который теперь действует как клиент SMTP. Электронная почта доставляется удаленному серверу, но не к удаленному агенту пользователя. Если бы SMTP был принятым сервером, всегда можно было бы обработать прибывшую почту в любой момент времени. Однако люди часто выключают свой компьютер до конца дня, а мини-компьютер или переносные компьютеры зачастую нормально не работают. Обычно организации предназначают свой компьютер для принятия электронной почты и постоянной работы в качестве программного сервера. Электронная почта получается с помощью такого сервера и накапливается в почтовом ящике для дальнейшего использования.
Третья стадия
На третьей ступени удаленный агент пользователя применяет протокол POP3 или IMAP4 (оба протокола обсуждаются в следующих секциях), чтобы запустить почтовый ящик и получить почту.