1 (1131253), страница 53

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 53)

MIME определяет пять новых заголовков, показанных в таблице 7-52. Первый сообщает агенту пользователя, что он имеет дело с MIME-сообщением, и то, какая версия MIME используется. Второй и третий характеризуют сообщение. Например, второе поле можно использовать для фильтрации сообщений.

Таблица 7-52. Пять заголовков RCF 822, определенных в MIME

Заголовок	Значение
MIME-Version:	Идентифицирует версию MIME
Content-Description:	Строка, описывающая содержимое сообщения
Content-Id:	Уникальный идентификатор
Content-Transfer-Encoding:	Способ подготовки тела письма к передаче
Content-Type:	Тип сообщения

Заголовок Content_Transfer_Encoding определяет, как сообщение должно быть подготовлено для передачи через сеть. Для этого используется пять основных схем. Простейшая схема – для передачи ASCII-текста – 7 бит на символ. Однако для учета национальных алфавитов используется 8 битная схема. Однако ни первая, ни вторая схемы не должны превышать 1000 символов в строке.

Сложная ситуация с передачей двоичных данных. Для корректной передачи такого типа данных (исполняемый код программ) используется схема base64 encoding. Эта схема разбивает сообщение на блоки по 24 бита. Каждый блок разбивается на 4 группы по 6 бит каждая. Для сообщений, которые являются «почти» ASCII-сообщениями с небольшими исключениями, используется другая схема – quoted-printable encoding. Можно указать и какую-то особую схему в поле Content-Transfer-Encoding.

Последнее поле заголовка указывает тип сообщения. Возможные значения этого поля указаны в таблице 7-53.

Таблица 7-53. Типы и подтипы сообщений MIME

Тип	Подтип	Описание
Text	Plain	Неформатированный текст
	Richtext	Текст с простым форматированием
Image	Gif	Изображение в формате GIF
	Jpeg	Изображение в формате JPEG
Audio	Basic	Звук
Video	Mpeg	Фильм в формате MPEG
Application	Octet-stream	Неинтерпретируемая последовательность байтов
	Postscript	Готовый к печати документ в формате PostScript
Message	Rfc822	Сообщение MIME RFC 822
	Partial	Сообщение перед передачей было разбито на несколько частей
	External-body	Непосредственно сообщение следует передать через сеть
Multipart	Mixed	Независимые части в определенной последовательности
	Alternative	Вышеупомянутое сообщение в различных форматах
	Parallel	Части сообщения необходимо просматривать вместе
	Digest	Каждая часть является самостоятельным сообщением RFC 822

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

SMTP (Simple Mail Transfer Protocol) – Простой протокол передачи почты. В Internet почта передается следующим образом. Машина отправитель устанавливает ТСР-соединение с 25-м портом машины получателя. На 25 порту находится почтовый демон, который работает по протоколу SMTP. Он принимает соединение и распределяет поступающие сообщения по почтовым ящикам машины-получателя.

SMTP - это простой ASCII-протокол. После установления соединения машина-отправитель работает как клиент, а машина-получатель – как сервер. Сервер шлет текстовую строку, идентифицирующую его и готовность принимать почту. Если он не готов принимать почту, то клиент разрывает соединение и повторяет всю процедуру позже.

Если сервер подтвердил свою готовность, то клиент сообщает, от кого и кому предназначено очередное сообщение. Если сервер подтвердил наличие получателя, то он дает команду клиенту, и сообщение передается без контрольных сумм и подтверждений, так как ТСР-соединение обеспечивает надежный поток байтов. Если сообщений несколько, то все они передаются. Обмен по соединению происходит в обоих направлениях.

Замечание. Клиент всегда посылает 4-символьные команды. Команды сервера в основном цифровые.

Получателей может быть несколько, тогда используют несколько RCTP-команд.

У SMTP протокола, несмотря на то что он хорошо описан в RFC 821, есть несколько проблем. Первая – длина сообщения не может превосходить 64 Кбайт. Другая – time out. Если время ожидания подтверждения у отправителя и получателя не согласовано, то один будет разрывать соединение, не дождавшись, тогда как другой просто очень загружен. Третья – почтовый ураган. Пусть машина-получатель имеет лист рассылки, где указана машина-отправитель, и наоборот. Тогда отправка сообщения по листу рассылки вызовет бесконечно долгие обмены сообщениями между этими машинами.

Для преодоления этих проблем в RFC 1425 был описан протокол ESMTP. Клиент вначале шлет команду EHLO, если она отвергается сервером, то это означает, что сервер работает по SMTP.

Протокол SMTP хорош, когда обе машины находятся в Internet. Однако это не всегда так. Многие компании в целях сетевой защиты соединяют свои сети через надлежащие средства, либо используют другие протоколы. Например, отправитель или получатель могут использовать протокол Х.400. Такая ситуация показана на рисунке 7-55. Отправитель передает сообщение шлюзу, тот его буферизует и позднее передает получателю. Звучит просто, но на деле все сложнее.

Рисунок 7-55. Передача электронного письма с использованием почтового шлюза на прикладном уровне

Первая проблема – соответствие адресов. Вторая – соответствие конвертов и заголовков. Третья – соответствие тела сообщения. Например, в случае, если тело содержит аудиофайл, а на стороне получателя с ним работать не умеют. Или отправитель поставил следующее условие: если передача сообщения не пройдет по почтовому соединению, то нужно повторить его по факсу, а получатель не умеет работать с факсом. Однако для простых неструктурированных ASCII-сообщений SMTP-шлюз – решение проблемы.

До сих пор мы предполагали, что машина пользователя может и отправлять сообщения, и получать их. Однако часто машина пользователя – это персональный компьютер или ноутбук, которая время от времени связывается с почтовым сервером, чтобы отправить или получить почту.

Как это происходит? Простой протокол для изъятия почты из удаленного почтового ящика – РОР3 (Post Office Protocol – RFC 1225). Он позволяет входить в удаленную систему и выходить из нее, передавать письма и принимать их. Главное - он позволяет забирать почту с сервера и хранить ее на машине пользователя.

Более сложный протокол IMAP – Interactive Mail Access Protocol (RFC 1064). Он позволяет одному и тому же пользователю заходить с разных машин на сервер, чтобы прочесть или отправить почту. Это по существу удаленное хранилище писем. Он, например, позволяет получать доступ к письму не только по его номеру, но и по содержанию.

Третий часто используемый протокол – DMSP (Distributed Mail System Protocol RFC 1056). Этот протокол не предполагает, что пользователь работает все время с одной и той же почтовой службой. Пользователь может обратиться к серверу и забрать почту на свою локальную машину, после чего разорвать соединение. Обработав почту, он может ее отправить позже, когда будет установлено очередное соединение.

Важными почтовыми сервисами являются:

• Фильтры

• Пересылка поступающей почты на другие адреса

• Демон отсутствия

• Почтовый робот (программа, анализирующая входящие письма и отвечающая на них)

Пославший почту, естественно, предполагает, что ее никто не читает кроме адресата. Однако если об этом специально не позаботиться, то гарантировать этого нельзя. Далее мы рассмотрим две широко распространенных безопасных почтовых системы - PGP и PEM.

PGP – Pretty Good Privacy. PGP – дословно: «вполне хорошая конфиденциальность» – разработка одного человека - Фила Зиммермана (Phil Zimmermann, 1995). Это полный пакет безопасности, который включает средства конфиденциальности, установления подлинности, электронной подписи, сжатия, и все это в удобной для использования форме. Благодаря тому, что это разработка далекого от государственных структур человека, качественная, работает как на платформе Unix, так и MS-DOS/Windows, Macintosh и распространяется бесплатно, она получила очень широкое распространение.

PGP использует алгоритмы шифрования RSA, IDEA и MD5. PGP поддерживает компрессию передаваемых данных их секретность, электронную подпись и средства управления доступом к ключам. Схема работы PGP показана на рисунке 7-56. На этом рисунке DA, DB - личные (закрытые) ключи А и В соответственно, а EA, EB – их открытые ключи. Отметим, что секретный ключ для IDEA строится автоматически в ходе работы PGP на стороне А и называется ключом сессии - KM, который затем шифруется алгоритмом RSA с открытым ключом пользователя В. Также следует обратить внимание на то, что медленный алгоритм RSA используется для шифрования коротких фрагментов текста: 128-разрядного ключа для MD5 и 128-разрядного ключа для IDEA.

Рисунок 7-56. Действия PGP при отправке сообщения

PGP поддерживает три длины ключей:

• Обычный – 314 бит (может быть раскрыт за счет больших затрат).

• Коммерческий – 512 бит (может быть раскрыт специализированными организациями, названия которых, как правило, состоят из трех букв, например, ЦРУ, АНБ, ФСБ, МВД, ФБР).

• Военный – 1024 бита (не может быть раскрыт пока никем на Земле).

Рисунок 7-57. Формат PGP-сообщения

PEM – почтовая служба с повышенной конфиденциальностью. PEM имеет статус Internet-стандарта (RFC 1421, 1424). Сообщения, пересылаемые с помощью PEM, сначала преобразуются в каноническую форму. В этой форме соблюдены соглашения относительно спецсимволов типа табуляции, последовательных пробелов и т.п. Затем сообщение обрабатывается MD5 или MD2, шифруется с помощью DES (56-разрядный ключ) и передается с помощью кодировки base64. Передаваемый ключ защищается либо с помощью RSA, либо с помощью DES по схеме EDE.

Протокол передачи файлов – FTP.

FTP (File Transfer Protocol, Протокол передачи данных) - это один из первых и все еще широко используемых интернет-сервисов. Первые спецификации FTP относятся к 1971 году. С тех пор FTP претерпел множество модификаций и значительно расширил свои возможности.

Характеристики

Список файлов ответов (шпаргалок)