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

СОДЕРЖАНИЕ

Введение	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.	15
2.2.5 MIME (Multipurpose Internet Mail Extension)	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	38
4 Рекомендации по совершенствованию системы защиты информации в электронной почте	43
Заключение	45
Список используемых источников	46




ВВЕДЕНИЕ
     Электронная почта - один из важнейших информационных ресурсов во всемирной паутине. Она является самым массовым средством электронных коммуникаций. На сегодняшний день любой интернет-пользователь имеет свой E-mail. Конечно, говорить о достоинствах электронной почты, по сравнению с обычной почтой, в 21 веке будет неуместно, однако все-таки необходимо их упомянуть. Посылка письма по электронной почте обходится значительно дешевле посылки обычного письма. Кроме того, сообщение, посланное по электронной почте, дойдет до адресата за несколько часов, в то время как обычное письмо может добираться до адресата несколько дней, а то и недель.
     В век информационных технологий,  электронная почта становится одной из самых важных условий в ведении повседневной деятельности. Однако нельзя не учитывать все проблемы и недостатки при работе с ЭП.
     Основные проблемы, с которыми сталкиваются пользователи электронной почты связано, прежде всего, с недостаточной защитой современных почтовых систем. К этим проблемам относятся спам, хакерские атаки, взломы, похищение конфиденциальной информации и так далее.
     С этими проблемами приходится иметь дело не только пользователям общедоступных публичных систем, но и организациям, государственным учреждениям. Горький опыт и практика показывает, что одномоментное решение проблемы защиты электронной почты, к сожалению, невозможно. Создатели вирусов и их распространители, спамеры и хакеры изобретательны, поэтому еще вчера, вполне удовлетворительный уровень защиты информации при использовании электронной почты, сегодня может оказаться недостаточным. 
     Для того чтобы защита электронной почты была на наивысшем уровне, без чрезмерных усилий и затрат, в том числе финансовых, необходима выработка систематического и комплексного, с учетом всех угроз, подхода к решению данного вопроса.
     Все вышеописанные факторы обусловили актуальность моего исследования.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    1 ПОСТАНОВКА ЗАДАЧИ
     Цель дипломной работы - рассмотреть методы и средства защиты информации при использовании электронной почты. 
     В соответствии с поставленной целью решались следующие основные задачи:
     * Рассмотреть принципы работы электронной почты, основные протоколы;
     * Определить угрозы безопасности информации, связанные с использованием электронной почты;
     * Выработать политику безопасности для сервисов электронной почты;
     * Провести анализ технологий защиты информации в электронной почте;
     * Предложить рекомендации по совершенствованию системы защиты информации в электронной почте;
     Методы исследования:
     - обработка, анализ научных источников;
     - анализ научной литературы, учебников и пособий по исследуемой проблеме.
     Объект исследования –  электронная почта
     Предмет исследования –  принципы организации и механизм функционирования защищенной электронной почты.
     Теоретическую и методологическую базу исследования составляют труды отечественных и зарубежных специалистов, таких как Акулова О.А., Березина С., Вильяма Столингса, Галатенко В.А., Герасименко В.А., Гулевича Д. С., Лапониной О.Р., Микова А.И., Олифера В.Г., Олифер Н.А., Кузьмина А.С., Снейдера Й., Ульмана Д., Хаулета Т., и др.
    2 ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ
     2.1 Принципы работы электронной почты
     Электронная почта во многом похожа на обычную почтовую службу. Корреспонденция подготавливается пользователем на своем рабочем месте либо программой подготовки почты, либо просто обычным текстовым редактором. Почтовый сервер – это своеобразное почтовое отделение, куда поступает входящая и исходящая корреспонденция зарегистрированных на нём пользователей. Эта корреспонденция помещается в «почтовые ящики» пользователей – специально отведённые разделы на жестком диске. Каждый пользователь получает персональный почтовый адрес, по которому к нему будут поступать письма.
     Адрес электронной почты состоит выглядит как 
     почтовый_ящик@почтовый.домен
              m2@vvsu.ru
      Anton.Frolkov@athena.vvsu.ru
     где почтовый.домен - некое доменное имя, а почтовый_ящик - имя-идентификатор корреспондента.
     Схема работы электронной почты отражена на рисунке 2.1
     
     
     Рисунок 2.1- Схема функционирования электронной почты
     Процесс передачи почтового сообщения похож на процесс передачи телеграммы. Сначала пользователь в режиме off-line пишет текст письма, указывает адрес получателя. Для этого используется редактор подготовки писем, входящий в клиент-программу электронной почты. Подготовленные письма помещаются в папку «Исходящие». Затем устанавливается связь с сервером. Далее происходит автоматическая работа в режиме on-line: сервер по паролю определяет пользователя, принимает все письма из папки «Исходящие», передаёт поступившие письма, которые помещаются в папку «Входящие». Сеанс связи закончен. Папка «Исходящие» стала пустой, отправленные письма сохранились в папке «Отправленные». Если используется коммутируемая телефонная линия, то пользователь отключает телефонную связь. После этого он может не спеша просматривать полученную почту.
     Почтовый сервер работает постоянно. Он периодически просматривает «почтовые ящики» и организует передачу по сети исходящих писем. Входящую корреспонденцию почтовый сервер раскладывает по «ящикам».
     Клиент-программа, кроме функции приема-передачи писем во время сеанса связи, выполняет еще множество сервисных функций: подготовка и редактирование писем, организация адресной книги, просмотр почтового архива, сортировка и удаление писем из почтового архива и пр. Популярным клиентом E-mail является программа Outlook Express, входящая в стандартную поставку операционной системы Windows.
     2.2 Основные протоколы электронной почты
     2.2.1 Протокол SMTP
     Протокол SMTP был разработан для работы в различных сетях для транспортировки электронной почты. Однако одной из наиболее полно используемых стала сеть Internet, с установкой соединения TCP/IP через порт 25. Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы. Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME (Multipurpose Internet Mail Extensions - формат многоцелевых расширений для электронной почты в Internet), который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.
     Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX. 
     MX или Mail Exchanger запись - это DNS запись, указывающая на сервер, который отвечает за почтовые ящики для определенного домена. Кроме того, MX-записи указывают приоритет каждого из возможных серверов для отправки.
     Чтобы отправить электронную почту на определённый адрес, сервер-отправитель делает DNS-запрос, запрашивая MX-запись домена получателя электронного сообщения (то есть части адреса после символа «@»). В результате запроса возвращается список имён хостов почтовых серверов, принимающих входящую почту для данного домена, а также величину приоритета для каждого из хостов. Сервер-отправитель затем пытается установить SMTP-соединение с одним из этих хостов, начиная с того, у кого значение величины приоритета наименьшее, перебирая каждый из них, пока не удастся установить соединение хотя бы с одним из них. Если же имеется несколько хостов с одинаковыми приоритетами, то должны быть предприняты попытки установить соединение с каждым из них. Механизм записей MX предоставляет возможность использовать множество серверов для одного домена и упорядочивания их использования в целях уменьшения нагрузки и увеличения вероятности успешной доставки почты. Кроме того, такой механизм предоставляет возможность распределить обработку входящей почты среди нескольких физических серверов.
     Формат записи: хост MX приоритет значение.
     Пример: идентифицировать mail.test.ru как почтовый ретранслятор для test.ru с приоритетом 10 можно следующей записью: test.ru. MX 10 mail.test.ru.
     Если MX запись отсутствует, то для тех же целей может быть использована запись типа A (позволяет установить соответствие между именем хоста в домене и его IP-адресом.). 
     Формат: хост A значение 
     Пример: преобразованию имени test.ru в адрес 192.168.0.1 соответствует следующая A-запись: test.ru. A 192.168.0.1
     Некоторые современные реализации SMTP-серверов для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись. SRV-запись позволяет получить имя для искомой службы, а также протокол, по которому эта служба работает. Приоритет SRV-записи работает аналогично приоритету MX-записи: чем меньше приоритет, тем более желательно использование связанной цели. Веса SRV-записей позволяют администраторам зоны распределять нагрузку между целями. Клиент должен опрашивать цели одного приоритета в пропорции к их весам. Порт SRV-записи определяет порт, по которому работает искомая служба.
     Формат: хост SRV приоритет вес порт значение 
     Пример: если мы хотим по запросу ftp клиента для досупа по ftp к test.ru, направлять клиент сначала на ftp1.test.ru. через 21 порт, а затем на ftp2.test.ru. через 21 порт, если ftp1.test.ru. недоступен. Это можно сделать следующими записями:
     _ftp._tcp.test.ru. SRV 1 0 21 ftp1.test.ru.
     _ftp._tcp.test.ru. SRV 2 0 21 ftp2.test.ru.
     Сервер SMTP - это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда <пробел> параметры <перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:
     2ХХ - команда успешно выполнена 
     3XX - ожидаются дополнительные данные от клиента 
     4ХХ - временная ошибка, клиент должен произвести следующую попытку через некоторое время 
     5ХХ  - неустранимая ошибка 
     Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы. Рассмотрим несколько SMTP команд, действие которых интересно с точки зрения данной дипломной работы.
     Команда HELO.
     По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:
     HELO domain name
     Смысл команды HELO заключается в представлении клиента серверу SMTP. Этот метод доступа был разработан на начальной стадии развития сети Internet, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов 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 (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды.
     Чтобы компенсировать недостатки команды TURN, в RFC 1985 определена новая ее реализация, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:
     ETRN name
     Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена).
     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 username
     PASS password
     В роли username выступает идентификатор пользователя для сервера POP3. Соответственно, параметр password означает пароль для этого идентификатора пользователя. Единственная защита сервера POP3 заключается в том, что сервер не возвращает ответ клиенту о неправильности идентификатора пользователя, а дожидается ввода пароля. Это исключает возможность подбора хакерами корректных идентификаторов пользователя для данного хоста POP3.
     Команда AUTH.
     Еще один метод повышения безопасности при регистрации пользователя — применение команды AUTH, описанной в RFC 1734. Команда была позаимствована из протокола IMAP.
     Формат команды AUTH следующий: AUTH mechanism
     Параметр mechanism определяет собственно метод проверки подлинности пользователя, с помощью которого производится подключение клиента к серверу. Когда метод проверки пользователя согласован, то вступает в силу проверка подлинности идентификатора пользователя. Клиент инициирует сеанс переговоров с сервером, в течение которого согласовывается метод проверки подлинности. Вначале клиент выдает команду AUTH с наивысшей возможной степенью шифрования. Если сервером не поддерживается соответствующий уровень шифрования, то он вернет негативный ответ. Затем клиент может выдать еще одну команду AUTH, с уже другим механизмом проверки подлинности. Эти переговоры между клиентом и сервером будут продолжаться до тех пор, пока клиент и сервер не найдут приемлемый для обоих алгоритм проверки подлинности, в противном случае они просто перейдут к использованию комбинации команд USER/PASS. 
     Команда APOP.
     Для входа на сервер POP3, вместо комбинации команд USER/PASS, клиент может использовать команду APOP. Команда APOP позволяет клиенту регистрироваться на сервере, не посылая пароль в текстовом виде, — она использует зашифрованную с помощью алгоритма MD5 версию пароля. Формат команды APOP: APOP name digest
     Аргумент name — это обычный идентификатор пользователя, который регистрируется на сервере. Параметр digest позволяет клиенту посылать на сервер закодированное MD5 значение digest, с помощью которого и производится проверка подлинности пользователя. Алгоритм шифрования MD5 был разработан Роном Райвестом (Ron Rivest) и описан в документе RFC 1321. Этот алгоритм основан на использовании алгоритма хеширования для наложения известного сообщения на секретное слово (ключ), которое известно лишь двум оконечным точкам. Признаком работы алгоритма хеширования является наличие параметра digest, который передается вместе с именем клиента. Очевидно, что для нормальной работы такой схемы нужно, чтобы клиенту и серверу заранее был известен ключ. В роли известного сообщения, налагаемого на ключ, может выступать приглашение сервера POP3 при установлении с ним TCP-соединения. Как правило, в роли такого сообщения выступает идентификатор, который следует за именем хоста сервера POP3.
     Однако следует отметить, что поддержка команды APOP не является обязательной для протокола POP3. Проверить, поддерживается ли эта команда вашим сервером можно, проанализировав приглашение сервера POP3.
     Существуют реализации POP3-серверов, поддерживающие TLS и SSL. 
     Альтернативным протоколом для сбора сообщений с почтового сервера является IMAP.
     2.2.4 IMAP.
     Interactive Mail Access Protocol - протокол интерактивного доступа к электронной почте. 
     Протокол IMAP позволяет клиенту создавать на почтовом сервере различные папки и помещать туда сообщения для хранения. Соединение с сервером почты по протоколу IMAP может устанавливаться с любой рабочей станции. При этом пользователи получают доступ к одним и тем же папкам и почтовым ящикам. А главное - сообщения загружаются на рабочую станцию только для отображения. Физически их копии продолжают оставаться на сервере в папке, где они хранились до загрузки клиенту. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем. Для отправки писем используется протокол SMTP.
     IMAP был разработан для замены более простого протокола POP3 и имеет следующие преимущества по сравнению с последним:
* Письма хранятся на сервере, а не на клиенте. Возможен доступ к одному и тому же почтовому ящику с разных клиентов. Поддерживается также одновременный доступ нескольких клиентов. В протоколе есть механизмы с помощью которых клиент может быть проинформирован об изменениях, сделанных другими клиентами.
* Поддержка нескольких почтовых ящиков (или папок). Клиент может создавать, удалять и переименовывать почтовые ящики на сервере, а также перемещать письма из одного почтового ящика в другой.
* Возможно создание общих папок, к которым могут иметь доступ несколько пользователей.
* Информация о состоянии писем хранится на сервере и доступна всем клиентам. Письма могут быть помечены как прочитанные, важные и т. п.
* Поддержка поиска на сервере. Нет необходимости скачивать с сервера множество сообщений для того чтобы найти одно нужное.
* Поддержка онлайн-работы. Клиент может поддерживать с сервером постоянное соединение, при этом сервер в реальном времени информирует клиента об изменениях в почтовых ящиках, в том числе о новых письмах.
* Предусмотрен механизм расширения возможностей протокола.
* Текущая версия протокола имеет обозначение IMAP4rev1 (IMAP, версия 4, ревизия. Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.
     Протокол поддерживает передачу пароля пользователя в зашифрованном виде. Кроме того, IMAP-трафик можно зашифровать с помощью SSL.
     2.2.5 MIME (Multipurpose Internet Mail Extension)
     Стандарт MIME (или в нотации Internet, RFC-1341) предназначен для описания тела почтового сообщения Internet. Предшественником MIME является Стандарт почтового сообщения ARPA (RFC-822). Стандарт RFC-822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети, невозможно передать по почте без специальных преобразований. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC-822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать 7-битовой кодировкой ASCII. Естественно, что при использовании RFC-822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC-822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400 (новый стандарт ISO), который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть по различному проинтерпретированы в X.400 и в программе рассылки почты в Internet (mail-agent). 
     В некотором смысле стандарт MIME ортогонален стандарту RFC-822. Если последний подробно описывает в заголовке почтового сообщения текстовое тело письма и механизм его рассылки, то MIME, главным образом, ориентирован на описание в заголовке письма структуры тела почтового сообщения и возможности составления письма из информационных единиц различных типов1. 
     В стандарте зарезервировано несколько способов представления разнородной информации. Для этого используются специальные поля заголовка почтового сообщения: 
     * поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте; 
     * поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретацию данных; 
     * поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования; 
     * два дополнительных поля, зарезервированных для более детального описания тела сообщения;
     Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority). 
     
     2.2.6 Формат почтового сообщения (RFC-822)
     При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения2. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или To, например: 
     
     Поле Date определяет дату отправки сообщения, поле From - отправителя, а поля сс и To - получателя(ей). Чаще заголовок содержит дополнительные поля: 
     
     В данном случае поле Sender указывает, что George Jones не является автором сообщения. Он только переслал сообщение, которое получил из Secy@SHOST. Поле Message-ID содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка: 
     
     Поле Subject определяет тему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение относится к типу «В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее ...», X-Special-action - поле, определенное пользователем, которое не определено в стандарте. 
     Следует сказать, что формат сообщения постоянно дополняется и совершенствуется. В RFC-1327 введены дополнительные поля для совместимости с почтой X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто встречающихся заголовков, которые не регламентированы в RFC-822. Так первое предложение заголовка, которое начинается со слова From, содержит UUCP-путь сообщения, по которому можно определить, через какие машины сообщение «пробиралось». Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты3.
     2.3 Угрозы безопасности информации, связанные с использованием электронной почты.
     Основные протоколы передачи почты (SMTP, POP3,IMAP4) обычно не осуществляют надёжной аутентификации, что позволяет легко создать письма с фальшивыми адресами. Ни один из этих протоколов не использует криптографию, которая могла бы гарантировать конфиденциальность электронных писем. Хотя существуют расширения этих протоколов, решение использовать их должно быть явно принято, как составная часть политики администрации почтового сервера. Некоторые такие расширения используют уже имеющиеся средства аутентификации, а другие позволяют клиенту и серверу согласовать тип аутентификации, который будет использоваться в данном соединении. Домарев В.В. Название: Безопасность информационных технологий. Методология создания систем защиты Издательство:ТИД Диа Софт , 2006. - с. 413
     1. Фальшивые адреса отправителя
     Адресу отправителя в электронной почте Интернета нельзя доверять, так как отправитель может указать фальшивый обратный адрес, или заголовок может быть модифицирован в ходе передачи письма, или отправитель может сам соединиться с SMTP-портом на машине, от имени которой он хочет отправить письмо, и ввести текст письма.
     2. Перехват письма
     Заголовки и содержимое электронных писем передаются в чистом виде. В результате содержимое сообщения может быть прочитано или изменено в процессе передачи его по Интернету. Заголовок может быть модифицирован, чтобы скрыть или изменить отправителя, или для того чтобы перенаправить сообщение.
     3. Почтовые бомбы
     Почтовая бомба - это атака с помощью электронной почты. Атакуемая система переполняется письмами до тех пор, пока она не выйдет из строя. Как это может случиться, зависит от типа почтового сервера и того, как он сконфигурирован.
     Некоторые провайдеры Интернета дают временные логины любому для тестирования подключения к Интернету, и эти логины могут быть использованы для начала подобных атак.
     Типовые варианты выхода почтового сервера из строя:
     - Почтовые сообщения принимаются до тех пор, пока диск, где они размещаются, не переполнится. Следующие письма не принимаются. Если этот диск также основной системный диск, то вся система может аварийно завершиться.
     - Входная очередь переполняется сообщениями, которые нужно обработать и передать дальше, до тех пор, пока не будет достигнут предельный размер очереди. Последующие сообщения не попадут в очередь.
     - У некоторых почтовых систем можно установить максимальное число почтовых сообщений или максимальный общий размер сообщений, которые пользователь может принять за один раз. Последующие сообщения будут отвергнуты или уничтожены.
     - Может быть превышена квота диска для данного пользователя. Это помешает принять последующие письма, и может помешать ему выполнять другие действия. Восстановление может оказаться трудным для пользователя, так как ему может понадобиться дополнительное дисковое пространство для удаления писем.
     - Большой размер почтового ящика может сделать трудным для системного администратора получение системных предупреждений и сообщений об ошибках.
     - Посылка почтовых бомб в список рассылки может привести к тому, что его члены могут отписаться от списка.
     4. Угрожающие письма
     Так как любой человек в мире может послать вам письмо, может оказаться трудным заставить его прекратить посылать их вам. Люди могут узнать ваш адрес из списка адресов организации, списка лиц, подписавшихся на список рассылки, или писем в Usenet. Если вы указали ваш почтовый адрес какому-нибудь веб-сайту, то он может продать ваш адрес "почтовым мусорщикам". Некоторые веб-браузеры сами указывают ваш почтовый адрес, когда вы посещаете веб-сайт, поэтому вы можете даже не понять, что вы его дали. Много почтовых систем имеют возможности фильтрации почты, то есть поиска указанных слов или словосочетаний в заголовке письма или его теле, и последующего помещения его в определённый почтовый ящик или удаления. Но большинство пользователей не знает, как использовать механизм фильтрации. Кроме того, фильтрация у клиента происходит после того, как письмо уже полу.......................