Электронная почта как сервис глобальной сети. Протоколы передачи почты

почтового ящика.

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: 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.

2.2.3. Способы кодирования MIME.

Для кодирования небольшого количества 8-битных данных в 7-битный

формат NVT ASCII лучше всего подходит схема quoted printable. 8-битный

символ в этой схеме представляется в виде последовательности из трех

символов. Последовательность всегда начинается со знака “равно” (=). Сразу

за знаком “равно” следует двузначное шестнадцатиричное число,

представляющее код ASCII кодируемого символа. Рассмотрим закодированную

quoted printable последовательность JAMSA PRESS. Хоть она и не содержит 8-

битных символов, зато позволяет хорошо проиллюстрировать принцип

кодирования. Закодированное сочетание JAMSA PRESS выглядит так:

=4A=41=4D=53=41=20=50=52=45=53=53

Другими словами, буква J имеет шестнадцатиричный код ASCII 0x4A, буква

А – 0х41 и т.д. Схема quoted printable передает ASCII код для каждого

символа последовательности. То есть для знака А (ASCII 0x4A) передается код

знака “равно” (ASCII 0x3D), код цифры 4 (ASCII 0x34) и код знака А (0х41).

Данную схему довольно удобно использовать, но она утраивает общее

количество информации в сообщении. Таким образом, область применения quoted

printable – сообщение с небольшим количеством символов, в которых

установлен старший (восьмой) бит. Основная часть сообщения должна состоять

обычных семибитных символов.

В отличие от quoted printable, кодирование Base-64 увеличивает размер

сообщения всего лишь на одну треть. Каждая последовательность из трех

байтов (24 бита) превращается в четыре шестибитовых (тоже 24 бита).

Шестибитные символы соответствуют формату NVT ASCII и приведены в табл. 6.

Таблица 6

Таблица кодировки Base-64

|USER |Идентифицирует пользователя с указанным именем |

|PASS |Указывает пароль для пары клиент-сервер |

|QUIT |Закрывает TCP-соединение |

|STAT |Сервер возвращает количество сообщений в почтовом ящике |

| |плюс размер почтового ящика |

|LIST |Сервер возвращает идентификаторы сообщений вместе с |

| |размерами сообщений (параметром команды может быть |

| |идентификатор сообщения) |

|RETR |Извлекает сообщение из почтового ящика (требуется указывать|

| |аргумент-идентификатор сообщения) |

|DELE |Отмечает сообщение для удаления (требуется указывать |

| |аргумент-идентификатор сообщения) |

|NOOP |Сервер возвращает положительный ответ, но не совершает |

| |никаких действий |

|LAST |Сервер возвращает наибольший номер сообщения из тех, к |

| |которым ранее уже обращались |

|RSET |Отменяет удаление сообщения, отмеченного ранее командой |

| |DELE |

В протоколе POР3 определено несколько команд, но на них дается только

два ответа: +OK (позитивный, аналогичен сообщению-подтверждению АСК) и -ERR

(негативный, аналогичен сообщению “не подтверждено” NAK). Оба ответа

подтверждают, что обращение к серверу произошло и что он вообще отвечает на

команды. Как правило, за каждым ответом следует его содержательное

словесное описание. Сейчас будут рассмотрены несколько типичных сеансов

РОРЗ, что даст возможность уловить последовательность команд в обмене между

сервером и клиентом.

Авторизация пользователя

После того, как программа установила TCP-соединение с портом протокола

РОРЗ (официальный номер 110), необходимо послать команду USER с именем

пользователя в качестве параметра. Если ответ сервера будет +OK, нужно

послать команду PASS с паролем этого пользователя:

CLIENT: USER kcope

SERVER: +OK

CLIENT: PASS secret

SERVER: +OK kcope's maildrop has 2 messages (320 octets)

...

(B почтовом ящике kcope есть 2 сообщения (320 байтов) ...)

Транзакции РОРЗ

После того, как стадия авторизации окончена, обмен переходит на стадию

транзакции. В следующих примерах демонстрируется возможный обмен

сообщениями на этой стадии. Команда STAT возвращает количество сообщений и

количество байтов в сообщениях:

CLIENT: STAT

SERVER: +ОК 2 320

Команда LIST (без параметра) возвращает список сообщений в почтовом

ящике и их размеры:

CLIENT: LIST

SERVER: +ОК 2 messages (320 octets)

SERVER: 1 120

SERVER: 2 200

SERVER: . ...

Команда LIST с параметром возвращает информацию о заданном сообщении:

CLIENT: LIST 2

SERVER: +ОК 2 200 ...

CLIENT: LIST 3

SERVER: -ERR no such message, only 2 messages in maildrop

Команда TOP возвращает заголовок, пустую строку и первые десять строк

тела сообщения:

CLIENT: TOP 10

SERVER: +OK

SERVER:

(сервер POP высылает заголовки сообщений, пустую строку и первые десять

строк тела сообщения)

SERVER: . ...

CLIENT: TOP 100

SERVER: -ERR no such message

Команда NOOP не возвращает никакой полезной информации, за исключением

позитивного ответа сервера. Однако, позитивный ответ означает, что сервер

находится в соединении с клиентом и ждет запросов:

CLIENT: NOOP

SERVER: +OK

Следующие примеры показывают, как сервер POP3 выполняет действия.

Например, команда RETR извлекает сообщение с указанным номером и помещает

его в буфер местного UA:

CLIENT: RETR 1

SERVER: +OK 120 octets

SERVER:

(РОРЗ-сервер высылает сообщение целиком)

SERVER: .

Команда DELE отмечает сообщение, которое нужно удалить:

CLIENT: DELE 1

SERVER: +OK message 1 deleted...

(сообщение 1 удалено)

CLIENT: DELE 2

SERVER: -ERR message 2 already deleted

(сообщение 2 уже удалено)

Команда RSET снимает метки удаления со всех отмеченных ранее

сообщений:

CLIENT: RSET

SERVER: +OK maildrop has 2 messages (320 octets)

(в почтовом ящике 2 сообщения (320 байтов))

Команда QUIT закрывает соединение с сервером:

CLIENT: QUIT

SERVER: +OK dewey POP3 server signing off

CLIENT: QUIT

SERVER: +OK dewey POP3 server signing off (maildrop empty)

...

CLIENT: QUIT

SERVER: +OK dewey POP3 server signing off (2 messages left) ...

Отмеченные для удаления сообщения не удаляются до тех пор, пока не

выдана команда QUIT и не началась стадия обновления. В любой момент в

течение сеанса клиент имеет возможность выдать команду RSET, и все

отмеченные для удаления сообщения будут восстановлены.

3. Организация службы электронной почты в сети Интернет.

Основную роль в системе электронной почты играют программы трех типов:

. транспортные агенты (MTA - Mail Transport Agent),

. агенты доставки (MDA - Mail Delivery Agent),

. пользовательские агенты (MUA - Mail User Agent).

Взаимодействие этих программ и работа системы электронной почты

представлены на рисунке:

[pic]

Рис. 3 Организация и функционирование службы электронной почты.

Транспортный агент работает, как правило, на почтовом сервере.

Транспортный агент функционирует как маршрутизатор почтовых сообщений. Его

функции следующие:

. анализ и преобразование адресов и заголовков почтовых сообщений, в том

числе:

o разбор списков рассылки, пседонимов, переадресации (форвардинг),

o преобразование адресов в формат другой почтовой системы, если

MTA функционирует как шлюз между двумя почтовыми системами

(например, между Internet Mail и Sprint Mail),

o преобразование имени почтового домена отправителя (маскарад),

o установка служебных заголовков в сообщении, отражающих его

маршрут и процесс обработки;

. опрос DNS на предмет имени и адреса почтового сервера адресата

сообщения;

. определение агента доставки для каждого сообщения и передача сообщения

выбранному агенту доставки;

. управление очередью сообщений, отложенный и повторный вызов агентов

Страницы: 1, 2, 3, 4, 5, 6