Команды пересылаются как 4-символьные мнемонические названия. Многие команды сопровождаются параметрами.
Сеанс между партнерами SMTP напоминает соединение telnet в режиме NVT: используются те же самые правила, например пересылаются 7-битные символы ASCII в виде 8-разрядных байтов, а каждая строка оканчивается символами перевода строки и возврата каретки.
16.10 Коды ответов
Коды ответов SMTP имеют структуру, подобную кодам ответов FTP. Код состоит из трех цифр. Первая цифра указывает статус команды:
| 1yz | Положительный предварительный (Positive Preliminary) ответ (в настоящее время в SMTP не используется) |
| 2yz | Положительный дополненный (Positive Completion) ответ |
| 3yz | Положительный промежуточный (Positive Intermediate) ответ |
| 4yz | Кратковременный отрицательный (Transient Negative) ответ ("повторить попытку") |
| 5yz | Постоянный отрицательный (Permanent Negative) ответ |
Вторая цифра классифицирует сам ответ:
| x0z | В ответ на возникновение проблемы указывает на синтаксическую ошибку или неизвестную команду |
| x1z | Ответ на информационный запрос (например, help) |
| x2z | Ответ с информацией о соединении |
| x3z | В настоящее время не определен |
| x4z | В настоящее время не определен |
| x5z | В ответе указываются сведения о почтовой системе получателя |
Значение третьей цифры меняется в зависимости от команды и первых двух цифр кода.
16.11 Формат сообщений Интернета
Стандарт для формата сообщений Интернета определен в RFC 822. Сообщение состоит из (в порядке списка):
■ Набора полей заголовка (многие из них необязательны)
■ Пустой строки
■ Текста, или тела (body), сообщения
Поле заголовка имеет вид:
Имя_поля: Содержимое_поля
Имена полей и их содержимое записываются символами ASCII. Существуют разнообразные поля заголовка. К наиболее распространенным можно отнести:
Received (получено)
Date (дата)
From (от)
То (кому)
cc (система cc-Mail)
bcc (blind cc — неявный формат cc-Mail)
Message-Id (идентификатор сообщения)
Reply-To (кому ответить)
Sender (отправитель, если он не является автором сообщения)
In-Reply-To (в ответ на)
References (ссылка на идентификатор более раннего сообщения)
Keywords (ключевые слова для поиска)
Subject (тема)
Comments (комментарии)
Encrypted (шифровано)
Можно ожидать, что каждый заголовок сообщения содержит поля Date, From и To. Добавленные поля (received field) формируются на основе временных меток, собираемых при переходе через промежуточные почтовые агенты пересылки. По большей части почтовое программное обеспечение может создавать идентификатор, который вставляется в сообщение. Например:
Message-Id: <199508271201.AA02330@PASCAL.MATH.YALE.EDU>
Поле Message-Id должно быть уникально для сети. Для этого в поле наряду с уникальным буквенно-цифровым идентификатором обычно включается имя хоста отправителя. Отметим, что показанный выше идентификатор содержит дату (1995 08 27), универсальное время (12 01) и дополнительную строку, обеспечивающую уникальность идентификатора для данного хоста и времени отправки.
Поля Resent (пересылка) добавляются на промежуточных системах. Например: Resent-To (куда переслать), Resent-From (откуда переслать), Resent-cc (переслать в систему cc-Mail), Resent-bcc (переслать в blind cc-Mail), Resent-Date (когда переслать), Resent-Sender (от кого переслать), Resent-Message-Id (с каким идентификатором переслать) и Resent-Reply-To (переслать в ответ на что).
Очень важна пустая строка за заголовком сообщения. По ней пользовательский агент определяет, что заголовок завершился и начинается тело сообщения.
16.12 Почтовые расширения файлов и MIME
Простота SMTP и формата почты облегчает реализацию почтовых систем Интернета и приводит к широкому распространению этих средств. Однако пользователям неудобно работать с простыми и ограниченными по своим возможностям текстовыми сообщениями. Ясно, что SMTP нуждался в переработке. Но как это можно было сделать без изменения уже установленных базовых почтовых приложений?
Было выбрано очень практичное решение. Новые клиенты MIME должны создаваться с учетом возможности получать сообщения из нескольких частей, содержащих много полезных типов информации. Эти сообщения позволяют проводить обмен:
■ Эффективно — через новый улучшенный агент пересылки сообщений SMTP.
■ Менее эффективно — через старый стандарт SMTP. Перед пересылкой нетекстовой части сообщения старому агенту SMTP эта часть должна быть преобразована так, чтобы она выглядела как обычный текст NVT.
На рис. 16.7 показана работа такой архитектуры.
Рис. 16.7. Доставка сообщения MIME
16.12.1 Улучшенный агент пересылки почты
Улучшенный агент пересылки почты (Extended Message Transfer Agent) должен поддержать одну дополнительную команду. Вместо HELO он посылает сообщение-приветствие EHLO. Если ответ положителен, партнер также является улучшенным агентом пересылки почты (Extended MTA). Но если ответом будет сообщение об ошибке, значит MTA должен вернуться к протоколу SMTP и послать команду HELO.
Потребность поддержки MIME была основным поводом для улучшения агентов пересылки почты MTA. Кроме этого, можно добавить поддержку дополнительных служб посредством введения новых ключевых слов для EHLO. Для пересылки сообщения увеличенного размера имеется новая служба, позволяющая отправителю декларировать размер сообщения перед его отправкой. Приемник может указать, готов ли он принять сообщение такого размера. Он также может указать наибольший доступный для него размер.