Электронная почта как сервис глобальной сети. Протоколы передачи почты
Категория реферата: Рефераты по информатике, программированию
Теги реферата: решебник класс, курение реферат
Добавил(а) на сайт: Венедикт.
Предыдущая страница реферата | 3 4 5 6 7 8 9 10 11 12 13 | Следующая страница реферата
Усилия по усовершенствованию электронной почты прилагаются в трех
направлениях. Они затрагивают доставку (организация информации в служебных
полях упаковки сообщения), обработку агентами пользователя (информация в
заголовке сообщения) и тело сообщения. Наиболее интересные возможности
предоставляет модификация тела почтового сообщения. Тело сообщения может
переносить мультимедиа-объекты, то есть являться двоичным файлом с
графической, звуковой или видеоинформацией.В этом разделе рассматриваются
существующие методы кодирования таких данных в почтовых сообщениях
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: 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-Bod|Указатель на действительное почтовое |
| |y |сообщение (не включенное в тело данного |
| | |сообщения). |
|Applicati|Octet-Stream|Произвольные двоичные данные. |
|on | | |
| |Postscript |Программа на языке Postscript. |
|Image |JPEG |Формат ISO 10918. |
| |GIF |Графический формат фирмы Compuserve. |
|Audio |Basic |Звук в 8-битном ISDN-формате mu-law. |
|Video |MPEG |Формат ISO11172 |
Поля заголовка Content-ID и Content-Description могут отсутствовать.
Первое служит для идентификации MIME-содержимого электронного письма, а
второе может содержать дополнительное описание. Например, если MIME-
содержимым является графический образ, в поле Content-Description можно
поместить описание этого образа. В табл. 5 перечислены возможные значения
Content-Transfer-Encoding, доступные в настоящее время.
Таблица 5
Допустимые значения поля Content-Tfansfer-Encoding
|Content-Transfer|Описание |
|-Encoding | |
|7bit |Формат NVT-ASCII – стандартный формат почтовых |
| |сообщений. |
|Quoted-printable|Полезен в случае, если текст содержит небольшое |
| |количество восьмибитных символов. |
|Base64 |Формат, в котором три байта данных упакованы в четыре|
| |шестибитных значения. |
|8bit |Содержит текст, в котором не все символы принадлежат |
| |стандартному набору ASCII (то есть в некоторых |
| |установлен восьмой бит). |
|Binary |Восьмибитные данные без символов окончания строки. |
По умолчанию формат почтовых сообщений удовлетворяет кодовому набору
NVT-ASCII. 8-битные агенты МТА сейчас практически отсутствуют, но как
только они получат широкое распространение, вероятно, передача бинарной и
текстовой информации в 8-битной кодировке возрастет. В настоящий момент для
передачи 8-битной информации по 7-битным каналам Internet лучше всего
использовать кодировки quoted-printable или base64.
Рекомендуем скачать другие рефераты по теме: решебник по геометрии класс, рассказ язык.
Предыдущая страница реферата | 3 4 5 6 7 8 9 10 11 12 13 | Следующая страница реферата