Рефераты. Электронная почта как сервис глобальной сети. Протоколы передачи почты
Аргументом
команды MAIL является обратный маршрут, включающий имя источника сообщения и
имена всех промежуточных агентов. Аргумент команды RCPT - маршрут доставки,
содержащий имя получателя сообщения. Обратный маршрут описывает путь, который
прошло сообщение, тогда как маршрут доставки идентифицирует место назначения.
Обратный маршрут используется SMTP, когда нужно передать сообщение о
случившейся ошибке или о невозможности доставить сообщение, когда оно уже
прошло через промежуточный агент. По мере продвижения сообщения по Internet
записи о его маршрутах изменяются. В обязанности системных администраторов
входит правильно настраивать местные МТА на передачу сообщений промежуточному
агенту, и наоборот, промежуточные агенты на доставку сообщений местным MTA.
Если у промежуточного МТА изменится имя, то в конфигурации местного МТА нужно
изменить имя компьютера в системе DNS. Другие параметры конфигурации не
изменяются.
Рассмотрим
почтовую транзакцию между промежуточными агентами SMTP. До того как сообщение
будет передано следующему указанному в маршруте (в поле ТО:) компьютеру, имя
данного компьютера удаляется из маршрута доставки и добавляется в начало
обратного маршрута. К тому моменту, когда сообщение достигнет пункта
назначения, маршрут доставки будет содержать только имя почтового ящика.
2.2. Усовершенствования электронной почты.
Усилия
по усовершенствованию электронной почты прилагаются в трех направлениях. Они
затрагивают доставку (организация информации в служебных полях упаковки
сообщения), обработку агентами пользователя (информация в заголовке сообщения)
и тело сообщения. Наиболее интересные возможности предоставляет модификация
тела почтового сообщения. Тело сообщения может переносить мультимедиа-объекты,
то есть являться двоичным файлом с графической, звуковой или видеоинформацией.В
этом разделе рассматриваются существующие методы кодирования таких данных в
почтовых сообщениях Internet.
2.2.1. Расширения SMTP.
Расширенный
SMTP (ESMTP , Extended SMTP) работает почти так же, как и обычный SMTP,
однако, команда-приветствие у него другая: EHLO (Extended hello) вместо HELO.
Чтобы выяснить, поддерживает ли МТА-сервер спецификацию ESMTP, МТА-клиент
посылает команду EHLO. Если сервер поддерживает ESMTP, он отвечает кодом 250.
Если нет, следует сообщение о синтаксической ошибке. В ответ на сообщение об
ошибке, клиент может выдать обычную команду HELO и далее выполнять стандартные
операции SMTP. Если сервер умеет обслуживать ESMTP, в ответ на приветствие, как
правило, он выдает многострочный ответ. Каждая срока ответа содержит
дополнительную команду ESMTP, с которой сервер знает, как работать. Пример
реакции ESMTP-сервера в ответ на команду EHLO:
250-mail.server.com
250-EXPN
250-HELP
250 TURN
Вторая, третья и
четвертая строки ответа содержат названия дополнительных команд сервера. Этот
сервер обеспечивает обработку перечисленных в табл. 1 дополнительных команд.
Первыми шестью расширениями SMTP являются команды: ЕXPN, HELP, TURN, SEND, SOML
и SAML. Существует также расширение SIZE, позволяющее SMTP-клиенту и серверу
сообщать друг другу размеры передаваемого сообщения. Если в ответе на команду
EHLO присутствует ключевое слово SIZE, значит, данное расширение
обрабатывается. Если клиент МТА попытается передать сообщение, превышающее
предел размеров передаваемого сообщения для сервера, почтовая транзакция не
состоится (закончится с ошибкой). Максимальная длина сообщения ограничивается
по нескольким причинам. Основная состоит в том, что размеры жестких дисков сервера
всегда ограничены, и слишком длинное сообщение может не поместиться на них. С
другой стороны, свободное пространство на дисках сервера может со временем
увеличиться, и это сообщение будет принято при следующей попытке. Максимальный
размер сообщения следует сразу за кодом ответа 250. Например:
250 SIZE 100000000
Это пример
ответа SIZE для размера в 100 Мб. Клиент MTA анализирует ответ SIZE и в случае
необходимости предпринимает соответствующие действия. Дополнительно клиент
может указывать длину сообщения в команде MAIL. В следующей ESMTP-команде
клиент объявляет, что длина сообщения равна 500 Кб:
MAIL FROM:<happy@jamsa.com> SIZE=500000
MTA-сервер
ESMTP анализирует аргумент SIZE и решает, принимать ему сообщение такой длины
или сообщить об ошибке. Все это происходит еще до начала передачи. Остальные
несколько расширений SMTP, в общем, подчиняются тем же правилам, что и
рассмотренная только что команда SIZE. То есть команда-расширение выдается в
ответе сервера по запросу клиента EHLO. Расширения можно использовать в ваших
программах в соответствии со спецификацией. В некоторых случаях расширение
является просто дополнительной возможностью. В других случаях расширение -
дополнительный аргумент к существующей команде (как в случае рассмотренной
команды SIZE).
Местным расширением является любое поле,
команда или название опции, начинающееся с буквы X.
При
разработке собственных расширений почтовой системы необходимо, чтобы имена всех
новых объектов начинались с буквы X. Например, пользовательский вариант декодирования
тела сообщения должен называться не DECODE, как можно было бы предположить, a
XDECODE. SMTP-сервер организации при этом должен включить местное расширение
XDECODE в список, выдаваемый по команде EHLO (с кодом ответа 250):
250 XDECODE
2.2.2. MIME .
Система
MIME - наиболее впечатляющее расширение для существующих почтовых систем. Она
не предполагает вмешательства в деятельность агентов передачи почты. Два агента
пользователя, понимающие MIME, могут общаться друг с другом при помощи
обыкновенных МТА. В MIME к сообщению просто добавляются несколько полей
заголовка:
MIME-Version (версия MIME)
Content-Type (тип содержимого)
Content-Transfer-Encoding (тип кодировки содержимого)
Content-ID (идентификатор содержимого)
Content-Description (описание содержимого)
Номера версий MIME меняются по мере
его развития. Поле MIME-Version задает номер версии расширения MIME, которое
данный агент пользователя умеет обрабатывать. Номер версии в заголовке
предохраняет агента от неправильной интерпретации сообщения, в случае, если
версии MIME сообщения агента не совпадают. Вот образец полей заголовка
MIME-Version и Content-Type:
Mime-Version: 1.О
Content-Type: TEXT/PLAIN; charset=US-ASCII
В этом примере
сообщение создано MIME версии 1.0. Тип содержимого – TEXT, подтип - PLAIN,
кодовая таблица (набор символов) US-ASCII. В табл. 4 приведены существующие в
данный момент типы и подтипы MIME.
Таблица 4
Существующие
типы и подтипы MIME
Тип
Подтип
Описание
Text
Plain
Неформатированный текст.
Richtext
Текст с элементами форматирования и
выделениями, например с курсивом, подчеркиваниями, жирными буквами и т.д.
Enriched
Усовершенствованный и упрощенный вариант
подтипа richtext.
Multipart
Mixed
Тело сообщения состоит из нескольких частей;
обрабатывать последовательно.
Parallel
Тело сообщения состоит из нескольких частей;
обрабатывать параллельно.
Digest
Дайджест электронной почты.
Alternative
Тело сообщения состоит из нескольких частей;
все части семантически идентичны.
Message
RFC822
В теле содержится почтовое сообщение
стандарта RFC 822.
Partial
Фрагмент почтового сообщения.
External-Body
Указатель на действительное почтовое
сообщение (не включенное в тело данного сообщения).
Application
Octet-Stream
Произвольные двоичные данные.
Postscript
Программа на языке Postscript.
Image
JPEG
Формат ISO 10918.
GIF
Графический формат фирмы Compuserve.
Audio
Basic
Звук в 8-битном ISDN-формате mu-law.
Video
MPEG
Формат ISO11172