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

Следующий пример демонстрирует типичную почтовую транзакцию. В примере

фигурирует мистер Smith (на компьютере usc.edu), посылающий сообщения

мистерам Jones, Green и Brown (на компьютере mit.edu). Агент передачи почты

хоста mit.edu принимает почту для мистеров Jones и Brown, однако не знает,

где расположен почтовый ящик мистера Green.

Для целей дальнейшего повествования каждой строке присвоен номер и

обозначено, кому они принадлежат - передатчику или приемнику. Текст справа

от слов “RECEIVER” или “SENDER” содержит действительно передаваемые данные.

Трехзначные цифровые комбинации в начале передаваемых строк обозначают коды

ответа. Ответ SMTP похож на сообщения-подтверждения о доставке, поскольку

появляется лишь в том случае, когда приемник получил данные.

1. RECEIVER: 220 mit.edu Simple Mail Transfer Service Ready

2. SENDER: HELO usc.edu

3. RECEIVER: 250 mit.edu

4. SENDER: MAIL FROM:

5. RECEIVER: 250 OK

6. SENDER: RCPT TO:

7. RECEIVER: 250 OK

8. SENDER: RCPT TO:

9. RECEIVER: 550 No such user here

10. SENDER:: RCPT TO

11. RECEIVER: 250OK

12. SENDER: DATA

13. RECEIVER: 354 Start mail input; end with .

14. SENDER: Blah blah blah...

15. SENDER: ...etc. etc. etc.

16. SENDER: .

17. RECEIVER: 250 OK

18. SENDER: QUIT

19. RECEIVER: 221 mit.edu Service closing transmission channel

Как видно из строки 1, когда SMTP-клиент устанавливает TCP-соединение

с портом протокола 25, SMTP-сервер отвечает кодом 220. Это означает, что

соединение успешно установлено:

1. RECEIVER: 220 mit.edu Simple Mail Transfer Service Ready

После того, как MTA компьютеров mit.edu и usc.edu установили

соединение и обменялись приветствием, первой командой должна быть команда

HELO. Как указано в строке 2, SMTP-клиент передает HELO, называя имя своего

компьютера в качестве аргумента. Команда HELO употребляется с аргументом,

как показано ниже:

2. SENDER: HELO usc.edu

В ответ на HELO приемник выдает код 250, сообщая передатчику о том,

что команда принята и обработана:

3. RECEIVER: 250 mit.edu

После установления TCP-соединения и идентификации (при помощи HELO)

SMTP-клиент приступает к почтовой транзакции. Для начала он выполняет одну

из следующих команд: MAIL, SEND, SOML или SAML. В нашем примере

использована команда MAIL:

4. SENDER: MAIL FROM:Smith@usc.edu

Четыре команды, MAIL, SEND, SOML и SAML, имеют одинаковый синтаксис:

MAIL FROM: line-feed>

Аргумент “обратный путь” (reverse path) указывает серверу, кому в

случае ошибки отослать соответствующее сообщение. В аргументе содержится

адрес источника сообщения (в нашем случае, Smith@usc.edu). После того как

сервер выдал код ответа 250 (строка 5), согласившись обработать сообщение

от Smith@usc.edu, необходимо указать получателя сообщения. Это делается при

помощи команды RCPT. Команда RCPT имеет аргумент - имя получателя. На одну

команду приходится только одно имя, поэтому, если получателей несколько,

команда RCPT выдается несколько раз. В нашем примере команды RCPT

выполняются в строках 6,8 и 10. Синтаксис RCPT похож на синтаксис команды

MAIL:

RCPT TO:

Однако, в отличие от MAIL, аргумент RCPT начинается со слова “TO:”.

Содержимое аргумента - путь передачи сообщения (forward path), а не

обратный путь. В пути передачи сообщения указано имя почтового ящика

получателя. Выдав команду RCPT, МТА-клиент ожидает получить ответ с кодом

250. Однако, в ответ на восьмую строку

8. SENDER: RCPT TO:

сервер отвечает кодом 550:

9. RECEIVER: 550 No such user here

Код ответа 550 означает, что МТА не в состоянии выполнить запрос

клиента, поскольку не знает, как доставить почту указанному пользователю.

То есть скорее всего у мистера по фамилии Green нет почтового ящика

(Green@mit.edu) на этом компьютере. В протоколе SMTP сказано, что сервер

обязан информировать клиента об отсутствии почтового ящика получателя

сообщения.

После того как посланы все команды RCPT, клиент начинает передачу при

помощи команды DATA. В строке 12 показано, как МТА-клиент (передатчик)

высылает команду DATA, в строке 13 - как сервер отвечает кодом 354. Этот

код означает, что передача данных разрешена и должна заканчиваться

комбинацией CRLF-точка-CRLF (новой строкой, содержащей только точку).

12. SENDER: DATA

13. RECEIVER: 354 Start mail input; end with .

После того как получен код 354, клиент может начать передачу данных.

МТА-сервер, в свою очередь, помещает принятые данные в очереди входящих

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

комбинацию CRLF-точка-CRLF от клиента, означающую конец передачи данных.

Как показано в строках 16 и 17, в ответ на полученную комбинацию CRLF-точка-

CRLF, сервер выдает код 250, что означает успешное окончание операции:

16. SENDER: .

17. RECEIVER: 250 OK

Для того, чтобы закончить почтовую транзакцию, клиент, по правилам

SMTP, обязан послать команду QUIT. Сервер, в свою очередь, отвечает кодом

221, который подтверждает клиенту, что соединение будет закрыто, после чего

соединение действительно закрывается:

18. SENDER: QUIT

19. RECEIVER: 221 mit.edu Service closing transmission channel

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

NOОР, HELP, EXPN и VRFY. В ответ на каждую команду сервер высылает клиенту

определенную информацию. В зависимости от ответа клиент может предпринять

определенные действия.

2.1.2. Коды ответов SMTP.

В спецификации SMTP требуется, чтобы сервер отвечал на каждую команду

SMТР-клиента. МТА-сервер отвечает трехзначной комбинацией цифр, называемой

кодом ответа. Вместе с кодом ответа, как правило, передается одна или

несколько строк текстовой информации.

Каждая цифра в коде ответа имеет определенный смысл. Первая цифра

означает, было ли выполнение команды успешно (2), неуспешно (5) или еще не

закончилось (3). Простой клиент может анализировать только первую цифру в

ответе сервера, и на основании ее продолжать свои действия. Вторая и третья

цифры кода ответа разъясняют значение первой. В табл. 2 приведены возможные

значения кодов ответа SMTP.

Таблица 2

Коды ответа SMTP и их значение

|Код |Значение |

|211 |Ответ о состоянии системы или помощь |

|214 |Сообщение-подсказка (помощь) |

|220 | служба готова к работе |

|221 | служба закрывает канал связи |

|250 |Запрошенное действие почтовой транзакции успешно завершилось |

|251 |Данный адресат не является местным; сообщение будет передано по |

| |маршруту |

|354 |Начинай передачу сообщения. Сообщение заканчивается комбинацией |

| |CRLF-точка-CRLF |

|421 | служба недоступна; соединение закрывается |

|450 |Запрошенная команда почтовой транзакции не выполнена, так как |

| |почтовый ящик недоступен |

|451 |Запрошенная команда не выполнена; произошла локальная ошибка при |

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

|452 |Запрошенная команда не выполнена; системе не хватило ресурсов |

|500 |Синтаксическая ошибка в тексте команды; команда не опознана |

|501 |Синтаксическая ошибка в аргументах или параметрах команды |

|502 |Данная команда не реализована |

|503 |Неверная последовательность команд |

|504 |У данной команды не может быть аргументов |

|550 |Запрошенная команда не выполнена, так как почтовый ящик и |

| |недоступен |

|551 |Данный адресат не является местным; попробуйте передать сообщение |

| |по маршруту |

|552 |Запрошенная команда почтовой транзакции прервана; дисковое |

| |пространство, доступное системе, переполнилось |

|553 |Запрошенная команда не выполнена; указано недопустимое имя |

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

|554 |Транзакция не выполнена |

Значения первой цифры в коде ответа SMTP

Цифра 1 означает, что сервер МТА принял команду, от клиента требуется

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

информацию о том, продолжать или прервать выполнение запрошенной команды.

Из табл. 2 видно, что SMTP не имеет в составе таких команд, то есть коды

ответа, начинающиеся с единицы, отсутствуют. В настоящее время команд SMTP,

которые бы потребовали дополнительного подтверждения, нет. Разработчики

ориентировались на то, что такие команды появятся, и зарезервировали для

них коды, начинающиеся с цифры 1.

Коды ответа, начинающиеся с цифры 2, означают, что сервер МТА успешно

завершил выполнение команды и ожидает появления новой. Код ответа,

начинающийся на 3, означает, что команда начала выполняться, но серверу

необходима дополнительная информация для ее завершения. Пример такого кода

- 354. В ответ на него клиент МТА должен приступить к передаче почтового

сообщения. Код, начинающийся с цифры 4, означает, что сервер не принял

команду, и она не выполнена. Во всех ответах серии 400 предполагается, что

ошибка временная и клиент может попытаться ее исправить. Коды ответа серии

500 также сообщают, что команда не выполнена. Кроме того, клиент не должен

пытаться повторить ту же команду еще раз (по крайней мере в составе той же

последовательности).

Значения второй цифры кода ответа SMTP

Вторая цифра кода ответа обозначает категорию ошибки. Цифра 0

обозначает синтаксическую ошибку. Команда может быть слишком длинной, иметь

неправильный аргумент или отсутствовать в списке команд сервера.

У сообщений с кодами 211 и 214 из табл. 2 вторая цифра кода равна

единице и оба они информационного характера. У команд с кодами 220, 221 и

421 вторая цифра — двойка, и все они имеют дело с передачей данных или с

коммуникационным каналом. Коды ответов, у которых вторая цифра равна пяти

(250, 450 и 550) связаны непосредственно с почтовой системой. В настоящее

время в SMTP не определены значения кодов, вторая цифра которых равна трем

или четырем.

Третья цифра кода ответа SMTP

Каждая отдельная строка сообщения должна иметь собственную третью

цифру в коде ответа. Рассмотрим, например, сообщения с кодами от 500 до

504. Каждое сообщение означает отдельную синтаксическую ошибку. Поскольку

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

отличаться друг от друга. Каждое сообщение об ошибке имеет свой собственный

порядковый номер в данной серии. Спецификация SMTP рекомендует, но не

обязывает использовать строго заданные текстовые строки в ответах MTA-

сервера.

Ответ MTA-сервера может состоять из нескольких строк специального

формата. Каждая строка (кроме последней) многострочного ответа начинается с

кода ответа, дефиса (-), текста и комбинации CRLF. Последняя строка

многострочного ответа начинается с кода ответа, за которым следует пробел:

123-Первая строка сообщения из нескольких строк

123-Код ответа, 123, не изменяется

123-1 сообщение может начинаться с цифры

123 Последняя строка начинается не с дефиса, а с пробела

За кодом каждой строки, кроме последней, следует знак дефиса (-). Это

необходимо, чтобы клиент MTA смог отличить строку-продолжение ответа от

последней строки. За кодом ответа в последней строке всегда следует пробел.

2.1.3. Ограничения по размерам.

В стандарте SMTP сказано, что реализации SMTP не должны ограничивать

максимальную длину обрабатываемых объектов (возможно, для будущих ра

ширений стандарта). Однако, в настоящий момент SMTP ограничивает допустимые

размеры следующими величинами, приведенными в табл. 3.

Таблица 3

Ограничения на размеры объектов SMTP

|Объект |Ограничение |

|SMTP | |

|User |Максимальная длина имени пользователя: 64 символа |

|Domain |Максимальная длина имени домена: 64 символа |

|Path |Максимальная длина обратного маршрута или маршрута доставки,|

| |включая знаки пунктуации и символы-oграничители: 256 знаков |

|Command |Максимальная длина командной строки, включая ключевое слово |

|line |и символы CRLF: 512 знаков |

|Reply |Максимальная длина строки ответа, включая код ответа и |

|line |символы CRLF: 512 знаков |

|Text line|Максимальная длина текстовой строки, включая символы CRLF: |

| |1000 знаков |

|Recipient|Максимальное количество получателей сообщения (за одну |

|s |транзакцию): 100 |

Если клиент МТА превысил ограничения на размер передаваемой

информации, сервер МТА отвечает одним из следующих кодов:

500 Line too long.

(слишком длинная строка)

501 Path too long.

(слишком длинный путь)

552 Too many recipients.

(слишком много получателей)

552 Too much mail data.

(слишком много данных в сообщении)

2.1.4. Промежуточные агенты.

Термин “маршрут доставки” (forward-path) служит для того, чтобы

отличать почтовый ящик (mailbox), имя которого абсолютно, от пути (он может

быть различным), по которому следует почта. Предположим, что нужно

доставить два почтовых сообщения на один и тот же сетевой компьютер. Оба

сообщения имеют один и тот же адрес, однако, не обязательно будут следовать

по одному и тому же маршруту. Точно так же, если на пришедшие сообщения

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

маршруту (reverse-path). Как правило, конкретный маршрут для почты

выбирается системным администратором. Чтобы направить почту по нужному

пути, используются значения маршрута доставки и обратного маршрута, в

которых указываются промежуточные агенты (relay agents). Промежуточный

агент доставки - это МТА, так называемый почтовый хаб (mail hub),

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

местный агент пользователя (UA) передает его местному МТА, который, в свою

очередь, передает его промежуточному агенту МТА. В следующем примере

Smith@usc.edu является почтовым ящиком, a HOST1, HOST2 и HOST3 -

промежуточными агентами:

MAIL FROM:

Промежуточные агенты присутствуют практически во всех сетях, входящих

в Internet.

[pic]

Рис. 2 Почтовая система Интернет с участием промежуточных агентов.

Чтобы упростить процесс конфигурации почтовой системы, в локальной

сети устанавливается один компьютер, служащий промежуточным агентом (relay

host). Вся почта пользователей попадает сначала на него. Затем этот

компьютер рассылает сообщения по Internet. Кроме всего прочего, такой

компьютер может служить защитой фирмы от взломщиков-хакеров из Internet.

Ограничивая общение локальной сети с внешним миром до уровня почты,

организация сводит до минимума риск нежелательного вторжения в свои

собственные системы. Кроме того, администрировать и защищать в этом случае

приходится единственный компьютер. SMTP в состоянии послать сообщение

непосредственно с компьютера пользователя на компьютер адресата в том

случае, если между ними существует прямое почтовое соединение. Но обычно

между двумя компьютерами находятся промежуточные агенты. Чтобы обеспечить

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

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

Аргументом команды 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: 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