Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Команды пересылаются как 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: < [email protected]>
Поле 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. Для пересылки сообщения увеличенного размера имеется новая служба, позволяющая отправителю декларировать размер сообщения перед его отправкой. Приемник может указать, готов ли он принять сообщение такого размера. Он также может указать наибольший доступный для него размер.
Официальные расширения регистрируются в Internet Assigned Numbers Authority (IANА). Отдельные программы включают новые экспериментальные расширения, для которых используются временные названия, начинающиеся с X.
16.12.2 Диалог в улучшенной версии SMTP
Показанный ниже пример демонстрирует, как улучшенный агент пересылки почты формирует транзакцию для отправки сообщения MIME в 8-битном формате:
■ Получатель объявляет о своих улучшенных возможностях, включая 8BITMIME.
■ Команда MAIL FROM имеет параметр BODY = 8BITMIME.
EHLO MATH-GW.CS.YALE.EDU
250-Hello MATH-GW.CS.YALE.EDU, pleased to meet you
250-8BITMIME
250-HELP
250-SIZE
250-XONE
250-XVRB
250-XQUE
MAIL FROM:< [email protected]> BODY = 8BITMIME
250 < [email protected]>... Sender ok
RCPT TO:< [email protected]>
250 < [email protected]>... Recipient ok
DATA
354 Send 8BITMIME message, ending in CRLF.CRLF.
...
.
250 OK QUIT
250 Goodbye
16.13 Формат сообщений MIME
Сообщение MIME содержит набор заголовков и одну или несколько частей тела сообщения (body part). Обычное сообщение почты Интернета начинается заголовками, подобными From:, To: и Date:. Сообщение MIME содержит дополнительные вводные заголовки, описывающие структуру и содержание сообщения.
Если сообщение состоит из нескольких частей, один из вводных заголовков определяет строку, используемую как разделитель. После такого разделителя будут стоять дополнительные заголовки, которые описывают следующую далее часть сообщения.
16.13.1 Заголовки описания типа содержания в MIME
Существует множество различных типов информации, которую можно разместить в сообщении. Общая структура сообщения и типы информации в каждой его части объявляются в заголовке Content-Type (тип содержания). Пример такого заголовка:
Content-Type: MULTIPART/MIXED; BOUNDARY ="ххххххххх"
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: image/gif
Content-Type: audio/basic
В основном заголовок Content-Type имеет форму:
Content-Type: тип/подтип; param — значение; param = значение; ...
Типы, подтипы и имена параметров нечувствительны к регистру символов. Они могут быть записаны в верхнем или нижнем регистре, равно как и в смешанном формате. Однако некоторые значения параметров зависят от регистра символов.
