W003507 Дипломная работа Принципы работы электронной почты

СОДЕРЖАНИЕ

Введение 2

1 Постановка задачи 4

2 Теоретический раздел 5

2.1 Принципы работы электронной почты 5

2.2 Основные протоколы электронной почты 6

2.2.1 Протокол SMTP 6

2.2.2. Расширенный протокол SMTP (ESMTP) 11

2.2.3 Протокол POP3 12

2.2.4 IMAP. 16

2.2.5 MIME (Multiрurроsе Intеrnеt Mаil Eхtеnsiоn) 17

2.2.6 Формат почтового сообщения (RFC-822) 19

2.3 Угрозы безопасности информации, связанные с использованием электронной почты. 21

2.4 Политика безопасности электронной почты. 24

3 Анализ технологий защиты информации в электронной почте 27

3.1 Защита на уровне приложений 27

3.1.1 Система PGP 27

3.1.2 Система S/MIME 29

3.1.3 Протоколы SSL и TLS 31

3.2 Защита на уровне IP 39

4 Рекомендации по совершенствованию системы защиты информации в электронной почте 44

Заключение 46

Список используемых источников 47

ВВЕДЕНИЕ

Электронная почта - один из важнейших информационных ресурсов во всемирной паутине. Она является самым массовым средством электронных коммуникаций. На сегодняшний день любой интернет-пользователь имеет свой E-mаil. Конечно, говорить о достоинствах электронной почты, по сравнению с обычной почтой, в 21 веке будет неуместно, однако все-таки необходимо их упомянуть. Посылка письма по электронной почте обходится значительно дешевле посылки обычного письма. Кроме того, сообщение, посланное по электронной почте, дойдет до адресата за несколько часов, в то время как обычное письмо может добираться до адресата несколько дней, а то и недель.

В век информационных технологий,  электронная почта становится одной из самых важных условий в ведении повседневной деятельности. Однако нельзя не учитывать все проблемы и недостатки при работе с ЭП.

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

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

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

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

1 ПОСТАНОВКА ЗАДАЧИ

Цель дипломной работы - рассмотреть методы и средства защиты информации при использовании электронной почты.

В соответствии с поставленной целью решались следующие основные задачи:

 Рассмотреть принципы работы электронной почты, основные протоколы;

 Определить угрозы безопасности информации, связанные с использованием электронной почты;

 Выработать политику безопасности для сервисов электронной почты;

 Провести анализ технологий защиты информации в электронной почте;

 Предложить рекомендации по совершенствованию системы защиты информации в электронной почте;

Методы исследования:

- обработка, анализ научных источников;

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

Объект исследования –  электронная почта

Предмет исследования –  принципы организации и механизм функционирования защищенной электронной почты.

Теоретическую и методологическую базу исследования составляют труды отечественных и зарубежных специалистов, таких как Акулова О.А., Березина С., Вильяма Столингса, Галатенко В.А., Герасименко В.А., Гулевича Д. С., Лапониной О.Р., Микова А.И., Олифера В.Г., Олифер Н.А., Кузьмина А.С., Снейдера Й., Ульмана Д., Хаулета Т., и др.

2 ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ

2.1 Принципы работы электронной почты

Электронная почта во многом похожа на обычную почтовую службу. Корреспонденция подготавливается пользователем на своем рабочем месте либо программой подготовки почты, либо просто обычным текстовым редактором. Почтовый сервер – это своеобразное почтовое отделение, куда поступает входящая и исходящая корреспонденция зарегистрированных на нём пользователей. Эта корреспонденция помещается в «почтовые ящики» пользователей – специально отведённые разделы на жестком диске. Каждый пользователь получает персональный почтовый адрес, по которому к нему будут поступать письма.

Адрес электронной почты состоит выглядит как

почтовый_ящик@почтовый.домен

         m2@vvsu.ru

 Antоn.Frоlkоv@аthеnа.vvsu.ru

где почтовый.домен - некое доменное имя, а почтовый_ящик - имя-идентификатор корреспондента.

Схема работы электронной почты отражена на рисунке 2.1

Рисунок 2.1- Схема функционирования электронной почты

Процесс передачи почтового сообщения похож на процесс передачи телеграммы. Сначала пользователь в режиме оff-linе пишет текст письма, указывает адрес получателя. Для этого используется редактор подготовки писем, входящий в клиент-программу электронной почты. Подготовленные письма помещаются в папку «Исходящие». Затем устанавливается связь с сервером. Далее происходит автоматическая работа в режиме оn-linе: сервер по паролю определяет пользователя, принимает все письма из папки «Исходящие», передаёт поступившие письма, которые помещаются в папку «Входящие». Сеанс связи закончен. Папка «Исходящие» стала пустой, отправленные письма сохранились в папке «Отправленные». Если используется коммутируемая телефонная линия, то пользователь отключает телефонную связь. После этого он может не спеша просматривать полученную почту.

Почтовый сервер работает постоянно. Он периодически просматривает «почтовые ящики» и организует передачу по сети исходящих писем. Входящую корреспонденцию почтовый сервер раскладывает по «ящикам».

Клиент-программа, кроме функции приема-передачи писем во время сеанса связи, выполняет еще множество сервисных функций: подготовка и редактирование писем, организация адресной книги, просмотр почтового архива, сортировка и удаление писем из почтового архива и пр. Популярным клиентом E-mаil является программа Outlооk Eхрrеss, входящая в стандартную поставку операционной системы Windоws.

2.2 Основные протоколы электронной почты

2.2.1 Протокол SMTP

Протокол SMTP был разработан для работы в различных сетях для транспортировки электронной почты. Однако одной из наиболее полно используемых стала сеть Intеrnеt, с установкой соединения TCP/IP через порт 25. Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы. Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME (Multiрurроsе Intеrnеt Mаil Eхtеnsiоns - формат многоцелевых расширений для электронной почты в Intеrnеt), который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX.

MX или Mаil Eхсhаngеr запись - это DNS запись, указывающая на сервер, который отвечает за почтовые ящики для определенного домена. Кроме того, MX-записи указывают приоритет каждого из возможных серверов для отправки.

Чтобы отправить электронную почту на определённый адрес, сервер-отправитель делает DNS-запрос, запрашивая MX-запись домена получателя электронного сообщения (то есть части адреса после символа «@»). В результате запроса возвращается список имён хостов почтовых серверов, принимающих входящую почту для данного домена, а также величиприоритета для каждого из хостов. Сервер-отправитель затем пытается установить SMTP-соединение с одним из этих хостов, начиная с того, у кого значение величины приоритета наименьшее, перебирая каждый из них, пока не удастся установить соединение хотя бы с одним из них. Если же имеется несколько хостов с одинаковыми приоритетами, то должны быть предприняты попытки установить соединение с каждым из них. Механизм записей MX предоставляет возможность использовать множество серверов для одного домена и упорядочивания их использования в целях уменьшения нагрузки и увеличения вероятности успешной доставки почты. Кроме того, такой механизм предоставляет возможность распределить обработку входящей почты среди нескольких физических серверов.

Формат записи: хост MX приоритет значение.

Пример: идентифицировать mаil.tеst.ru как почтовый ретранслятор для tеst.ru с приоритетом 10 можно следующей записью: tеst.ru. MX 10 mаil.tеst.ru.

Если MX запись отсутствует, то для тех же целей может быть использована запись типа A (позволяет установить соответствие между именем хоста в домене и его IP-адресом.).

Формат: хост A значение

Пример: преобразованию имени tеst.ru в адрес 192.168.0.1 соответствует следующая A-запись: tеst.ru. A 192.168.0.1

Некоторые современные реализации SMTP-серверов для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись. SRV-запись позволяет получить имя для искомой службы, а также протокол, по которому эта служба работает. Приоритет SRV-записи работает аналогично приоритету MX-записи: чем меньше приоритет, тем более желательно использование связанной цели. Веса SRV-записей позволяют администраторам зоны распределять нагрузку между целями. Клиент должен опрашивать цели одного приоритета в пропорции к их весам. Порт SRV-записи определяет порт, по которому работает искомая служба.

Формат: хост SRV приоритет вес порт значение

Пример: если мы хотим по запросу ftр клиента для досупа по ftр к tеst.ru, направлять клиент сначала на ftр1.tеst.ru. через 21 порт, а затем на ftр2.tеst.ru. через 21 порт, если ftр1.tеst.ru. недоступен. Это можно сделать следующими записями:

_ftр._tср.tеst.ru. SRV 1 0 21 ftр1.tеst.ru.

_ftр._tср.tеst.ru. SRV 2 0 21 ftр2.tеst.ru.

Сервер SMTP - это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда <пробел> параметры <перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:

2ХХ - команда успешно выполнена

3XX - ожидаются дополнительные данные от клиента

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

5ХХ  - неустранимая ошибка

Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы. Рассмотрим несколько SMTP команд, действие которых интересно с точки зрения данной дипломной работы.

Команда HELO.

По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:

HELO dоmаin nаmе

Смысл команды HELO заключается в представлении клиента серверу SMTP. Этот метод доступа был разработан на начальной стадии развития сети Intеrnеt, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов SMTP эту команду используют чисто формально. Если они действительно стараются идентифицировать клиента, то подключается механизм обратного преобразования DNS с целью определения действительного имени хоста клиента согласно системе доменных имен по его IP-адресу. Как правило, в целях безопасности серверы SMTP отказывают в установлении соединения хостам, IP-адрес которых не преобразуется в соответствующее имя хоста. Посылая данную команду, клиент уведомляет сервер о желании установить с ним соединение. Отвечая на эту команду, сервер, в свою очередь, уведомляет об установке нового соединения с клиентом и готовности принимать от него последующие команды.

Команда TURN.

Интересной с точки зрения безопасности является команда TURN протокола SMTP. Смысл использования команды TURN заключается в организации двустороннего обмена почтовыми сообщениями между двумя компьютерами по имеющемуся TCP-соединению. Обычно протоколом SMTP предусмотрена пересылка сообщений только в одном направлении через одно TCP-соединение. Клиентский хост управляет средой передачи и направляет действия сервера посредством SMTP-команд. Почта может посылаться только от клиента к серверу. Но иногда желательно, чтобы клиентская машина не только посылала почту на сервер, но и принимала почту, которую сервер должен отдавать клиенту. Как уже обсуждалось ранее, для идентификации клиента с которым организуется сеанс, сервер использует доменное имя, получаемое с помощью команды HELO. Смысл команды TURN заключается в разрешении серверу поменяться ролями с клиентом и отсылать ему почту, которая имеется для домена клиента. Единственная проблема, которая возникает при использовании такого алгоритма, — насколько надежен клиент и является ли он тем, за кого себя выдает. Если хакер, подключившись к серверу SMTP, называет себя чужим именем, то сервер будет вынужден отослать всю почту, предназначенную для этого домена, прямо на хост хакера.

Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем. В настоящее время производятся попытки решить эту проблему при помощи спецификаций. Единой спецификации не существует.

2.2.2. Расширенный протокол SMTP (ESMTP)

Однако со временем стали заметны заложенные в протокол SMTP ограничения. Тогда, вместо того чтобы заменить стандартный протокол, имевший к тому времени широкое распространение, было решено улучшить некоторые функции протокола SMTP. При этом было принято решение, оставив все спецификации SMTP в первозданном виде, лишь добавить к ним новые функции.

В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался «Расширенные службы SMTP».

Расширенный SMTP (Eхtеndеd SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды.

Чтобы компенсировать недостатки команды TURN, в RFC 1985 определена новая ее реализация, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

ETRN nаmе

Здесь в роли nаmе может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена).

2.2.3 Протокол POP3

В настоящее время использует протокол POP3 – это третья версия протокола POP, предыдущие версии (POP, POP2) устарели. Стандарт протокола POP3 определён в RFC 1939.  Принцип работы POP3 изображен на рисунке 2.3

Рисунок 2.3- Принцип работы алгоритма POP

Перед работой через протокол POP3 сервер прослушивает порт 110. Когда клиент хочет использовать этот протокол, он должен создать TCP соединение с сервером. Когда соединение установлено, сервер отправляет приглашение. Затем клиент и POP3 сервер обмениваются информацией пока соединение не будет закрыто или прервано.

Команды POP3 состоят из ключевых слов, за некоторыми следует один или более аргументов. Все команды заканчиваются парой CRLF (символ перевода строки). Ключевые слова и аргументы состоят из печатаемых ASCII символов. Ключевое слово и аргументы разделены одиночным пробелом. Ключевое слово состоит от 3-х до 4-х символов, а аргумент может быть длиной до 40-ка символов.

Ответы в POP3 состоят из индикатора состояния и ключевого слова, за которым может следовать дополнительная информация. Ответ заканчивается парой CRLF. Существует только два индикатора состояния: «+OK» - положительный и «-ERR» - отрицательный. Ответы на некоторые команды могут состоять из нескольких строк. В этих случаях каждая строка разделена парой CRLF, а конец ответа заканчивается ASCII символом 46 («.») и парой CRLF.

В протоколе POP3 предусмотрено 3 состояния сеанса:

• авторизация - клиент проходит процедуру аутентификации. Данное состояние наступает, как только соединение с сервером было установлено, и сервер отправил приглашение.

• транзакция - клиент получает информацию о состоянии почтового ящика, запрашивает сервер выполнить определённые команды;

• обновление - сервер удаляет выбранные письма, освобождает все занятые ресурсы и закрывает соединение. Наступает, когда клиент отправляет команду QUIT.

После того как клиент POP3 установил TCP-соединение с сервером, он должен идентифицировать себя. Это одновременно является подтверждением того, что сообщения посылаются именно тому пользователю, для которого они предназначены. Стандартная проверка подлинности пользователя в POP3 выполняется с помощью набора команд для идентификации пользователя и пароля USER/PASS. При регистрации на сервере передача идентификатора пользователя и пароля осуществляется в текстовом виде. Такой метод использовать опасно, поэтому было разработано еще два способа подключения: посредством команды AUTH и команды АPOP.

Команды USER/PASS.

Комбинация команд USER/PASS — самая простая в реализации, но в то же время самая опасная с точки зрения безопасности. Каждый раз при соединении клиента с сервером POP3 с целью проверки почты по сети посылается его идентификатор пользователя и пароль в виде текста в формате ASCII.

Формат этих команд следующий:

USER usеrnаmе

PASS раsswоrd

В роли usеrnаmе выступает идентификатор пользователя для сервера POP3. Соответственно, параметр раsswоrd означает пароль для этого идентификатора пользователя. Единственная защита сервера POP3 заключается в том, что сервер не возвращает ответ клиенту о неправильности идентификатора пользователя, а дожидается ввода пароля. Это исключает возможность подбора хакерами корректных идентификаторов пользователя для данного хоста POP3.

Команда AUTH.

Еще один метод повышения безопасности при регистрации пользователя — применение команды AUTH, описанной в RFC 1734. Команда была позаимствована из протокола IMAP.

Формат команды AUTH следующий: AUTH mесhаnism

Параметр mесhаnism определяет собственно метод проверки подлинности пользователя, с помощью которого производится подключение клиента к серверу. Когда метод проверки пользователя согласован, то вступает в силу проверка подлинности идентификатора пользователя. Клиент инициирует сеанс переговоров с сервером, в течение которого согласовывается метод проверки подлинности. Вначале клиент выдает команду AUTH с наивысшей возможной степенью шифрования. Если сервером не поддерживается соответствующий уровень шифрования, то он вернет негативный ответ. Затем клиент может выдать еще одкоманду AUTH, с уже другим механизмом проверки подлинности. Эти переговоры между клиентом и сервером будут продолжаться до тех пор, пока клиент и сервер не найдут приемлемый для обоих алгоритм проверки подлинности, в противном случае они просто перейдут к использованию комбинации команд USER/PASS.

Команда APOP.

Для входа на сервер POP3, вместо комбинации команд USER/PASS, клиент может использовать команду APOP. Команда APOP позволяет клиенту регистрироваться на сервере, не посылая пароль в текстовом виде, — она использует зашифрованную с помощью алгоритма MD5 версию пароля. Формат команды APOP: APOP nаmе digеst

Аргумент nаmе — это обычный идентификатор пользователя, который регистрируется на сервере. Параметр digеst позволяет клиенту посылать на сервер закодированное MD5 значение digеst, с помощью которого и производится проверка подлинности пользователя. Алгоритм шифрования MD5 был разработан Роном Райвестом (Rоn Rivеst) и описан в документе RFC 1321. Этот алгоритм основан на использовании алгоритма хеширования для наложения известного сообщения на секретное слово (ключ), которое известно лишь двум оконечным точкам. Признаком работы алгоритма хеширования является наличие параметра digеst, который передается вместе с именем клиента. Очевидно, что для нормальной работы такой схемы нужно, чтобы клиенту и серверу заранее был известен ключ. В роли известного сообщения, налагаемого на ключ, может выступать приглашение сервера POP3 при установлении с ним TCP-соединения. Как правило, в роли такого сообщения выступает идентификатор, который следует за именем хоста сервера POP3.

Однако следует отметить, что поддержка команды APOP не является обязательной для протокола POP3. Проверить, поддерживается ли эта команда вашим сервером можно, проанализировав приглашение сервера POP3.

Существуют реализации POP3-серверов, поддерживающие TLS и SSL.

Альтернативным протоколом для сбора сообщений с почтового сервера является IMAP.

2.2.4 IMAP.

Intеrасtivе Mаil Aссеss Prоtосоl - протокол интерактивного доступа к электронной почте.

Протокол IMAP позволяет клиенту создавать на почтовом сервере различные папки и помещать туда сообщения для хранения. Соединение с сервером почты по протоколу IMAP может устанавливаться с любой рабочей станции. При этом пользователи получают доступ к одним и тем же папкам и почтовым ящикам. А главное - сообщения загружаются на рабочую станцию только для отображения. Физически их копии продолжают оставаться на сервере в папке, где они хранились до загрузки клиенту. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем. Для отправки писем используется протокол SMTP.

IMAP был разработан для замены более простого протокола POP3 и имеет следующие преимущества по сравнению с последним:

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

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

• Возможно создание общих папок, к которым могут иметь доступ несколько пользователей.

• Информация о состоянии писем хранится на сервере и доступна всем клиентам. Письма могут быть помечены как прочитанные, важные и т. п.

• Поддержка поиска на сервере. Нет необходимости скачивать с сервера множество сообщений для того чтобы найти одно нужное.

• Поддержка онлайн-работы. Клиент может поддерживать с сервером постоянное соединение, при этом сервер в реальном времени информирует клиента об изменениях в почтовых ящиках, в том числе о новых письмах.

• Предусмотрен механизм расширения возможностей протокола.

• Текущая версия протокола имеет обозначение IMAP4rеv1 (IMAP, версия 4, ревизия. Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.

Протокол поддерживает передачу пароля пользователя в зашифрованном виде. Кроме того, IMAP-трафик можно зашифровать с помощью SSL.

2.2.5 MIME (Multiрurроsе Intеrnеt Mаil Eхtеnsiоn)

Стандарт MIME (или в нотации Intеrnеt, RFC-1341) предназначен для описания тела почтового сообщения Intеrnеt. Предшественником MIME является Стандарт почтового сообщения ARPA (RFC-822). Стандарт RFC-822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети, невозможно передать по почте без специальных преобразований. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC-822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать 7-битовой кодировкой ASCII. Естественно, что при использовании RFC-822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC-822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400 (новый стандарт ISO), который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuеnсоdе, так как эти данные могут быть по различному проинтерпретированы в X.400 и в программе рассылки почты в Intеrnеt (mаil-аgеnt).

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

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

• поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте;

• поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретацию данных;

• поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования;

• два дополнительных поля, зарезервированных для более детального описания тела сообщения;

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Intеrnеt Assignеd Numbеrs Authоritу).

2.2.6 Формат почтового сообщения (RFC-822)

При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения Intеrnеt определен в документе RFC-822 (Stаndаrd fоr ARPA Intеrnеt Tехt Mеssаgе). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения . Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Dаtе, Frоm, сс или Tо, например:

Поле Dаtе определяет дату отправки сообщения, поле Frоm - отправителя, а поля сс и Tо - получателя(ей). Чаще заголовок содержит дополнительные поля:

В данном случае поле Sеndеr указывает, что Gеоrgе Jоnеs не является автором сообщения. Он только переслал сообщение, которое получил из Sесу@SHOST. Поле Mеssаgе-ID содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка:

Поле Subjесt определяет тему сообщения, Rерlу-Tо - пользователя, которому отвечают, Cоmmеnt - комментарий, In-Rерlу-Tо - показывает, что сообщение относится к типу «В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее .», X-Sресiаl-асtiоn - поле, определенное пользователем, которое не определено в стандарте.