Организация и функционирование Электронной почты в компьютерных сетях

     • Низкая скорость работы. World Wide Web напоминает улицу с односторонним движением, на которой есть полоска для движения в обратную сторону, но такая узкая, что по ней едва проезжает детская коляска. Отправляя в сеть краткий и формальный запрос с URL-адресом нужного нам ресурса получаем в ответ богато украшенную Web-страницу. Отправить же что-то объемное в WWW проблематично. Это как в библиотеке. Там при заказе книги заполняют скромное требование на бланке, а в ответ получают огромные тома. В общем, получить письмо (и не только письмо) через WWW легко, а отправить что-либо — проблема;

     • Ограниченность полезных функций. Обычно почтовые клиенты имеют множество полезных функций, автоматизирующих работу с почтой. Их так много, что одно только перечисление заняло бы несколько страниц. А есть ли такие функции на Web-сервере — заранее неизвестно. Как правило, их число ограничено, потому что в рамках протокола HTTP развернуться крайне трудно;

     • Угроза безопасности. Если все же на Web-сервере есть какие-то средства для автоматизации работы с электронной почтой, то надо еще понять, на чём они основаны, даже такие простейшие, как, например, сортировка поступивших сообщений. В стандартной ситуации у автора Web страниц нет почти никаких средств для создания кнопок меню, раскрывающихся списков и других элементов управления. Cоздатели Web-страниц широко используют для этого язык сценариев Java-script;

     • Языковые барьеры. Для англоязычной части мира все просто и понятно. Там нет разницы в том, как кодируются символы английского языка в E-Mail и в Web-Mail. Эти символы успешно записываются кодами, которые укладываются между числами 32 и 127. В этом диапазоне действует единый международный стандарт ASCII. Он однозначно определяет, какому символу какой код соответствует.

     В странах с иными национальными  алфавитами, как в России, возможны проблемы. В России коды русских букв принадлежат диапазону 128...255, в котором действует несколько стандартов. То есть, получив, например, код 161, программа просмотра должна понять, какая кодировка была использована отправителем. И вот здесь-то и начинаются проблемы связанные с кодированием¹¹.

     Для ЭП в России основной считается кодировка КОИ8-Р. Однако если письмо приходит в формате HTML, то логично ожидать, что оно всё-таки написано в кодировке Windows-1251. Это понятно, ведь ЭП в России начала развиваться в те далекие годы, когда еще никакой операционной системы Windows и в помине не было. За основу была взята та кодировка, которая использовалась в межгосударственном общении стран-членов Совета Экономической Взаимопомощи (СЭВ). Поэтому письмо, отправленное через обычный сервер E-Mail, может не читаться на сервере Web-Mail без хитростей, связанных с изменением кодировки.

     Еще хуже дело обстоит на зарубежных серверах бесплатной электронной почты. Некоторые  из них полагают, что в России должен действовать международный стандарт кодировки, введенный Международным институтом стандартизации (ISO).

     К сожалению, нет простых и однозначных ответов того, как раз и навсегда избежать проблем с кодировкой символов. Виной тому многообразие возможных ситуаций. Результат зависит от того, каким типом ЭП пользуется партнёр (Wab-Mail или E-Mail), на каком сервере у него открыт «почтовый ящик», какой почтовый клиент он использует, какую кодировку избрал при создании сообщения, что сделали с сообщением промежуточные серверы во время транспортировки и т.д., и т.п. 
 

      2.2 Формат почтового  сообщения 
 

    Почтовые  службы на разных машинах представляют сообщения в разных форматах, некоторые из них несовместимы. Тем не менее, большинство систем во всем мире понимают формат сообщения, называемый, по имени документа, в котором он описан, например формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message).

    Первоначально этот стандарт был разработан для сети Internet, но сейчас принят во многих других сетях. Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах.

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

    RFC-822 регламентирует содержание заголовка  сообщения. Заголовок состоит  из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом «:».

    В документе RFC-822 открыто, сказано, что пользователям разрешается изобретать собственные заголовки для своих нужд при условии, что эти заголовки начинаются со строки X-. Гарантируется, что в будущем никакие стандартные заголовки не будут начинаться с этих символов, чтобы избежать конфликтов между официальными и частными заголовками. Иногда умники-студенты включают поля вроде X-Fruit-of-the-day: (сегодняшний плод) или X-Disease-of-the-week: (недуг недели), использование которых вполне законно, хотя их смысл и не всегда понятен.

    Минимально  необходимыми являются поля Date, From и To, например:

      • Date: Wed May 10 18:31:21 2007

      • From: postcards@postcards.ok.kz

      • To: Max@mail.ru

      Поле Date определяет дату отправки сообщения, поле From - отправителя, а поле  To – получателя (ей). Если письмо отослано по списку рассылки, то в поле To будет указан адрес почтового ящика, на который посылается текст письма для рассылки.

      Письма  по спискам рассылки идут довольно долго и могут запоздать на сутки и более. Бывает, что при ежедневной рассылке почты письмо за текущий день не приходит, а приходит оно после письма за следующий день. То есть, если письмо должно прийти 9-го числа, то может случиться, что оно придет 10-го, 11-го числа. Это обусловлено самой системой рассылки. Письмо может проходить через большое количество серверов и вследствие этого может опоздать. Также на это влияет и загруженность почтового сервера¹².

      Чаще  заголовок содержит дополнительные поля:

      • Date: Tue May 9 12:21:18 2000

      • From: ykovrizhnykh@online.kz

      • Sender: admin@online.kz

      • To: hetene@mail.ru

      • Message-ID: <4231.629.XYzi-admin@online.kz>

      В данном случае, поле Sender указывает, что владелец ящика ykovrizhnykh@online.kz не является автором сообщения. Он только переслал сообщение, которое получил от admin@online.kz. Поле Message-ID содержит уникальный идентификатор сообщения и используется программами доставки почты.

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

      • Date:  16 Mon Feb 2000 16:53:33

      • From:  Ken Davis <Kdavis@This-Host.This.net>

      • Subject:  Re: The Syntax in the RFC

      • Sender:  KSecy@Other-host

      • Reply-To: Sam.Irving@Reg.Organization

      • To:  hetene@mail.ru

      • cc:  Important folks

      • Comment: New company launced.

      • In-Reply-To: <some.string@DBM.Group>, George`s message

      • Message-ID: <4331.629.XYzi-What@Other-Host

      Поле Subject определяет ему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение относится к типу «В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее...».

      Следует сказать, что формат сообщения постоянно  дополняется и совершенствуется. В RFC-1327 введены дополнительные поля для совместимости с почтой протокола X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто встречающихся заголовков, которые не регламентированы в RFC-822.

      Так, первое предложение заголовка, которое начинается со слова From, может содержать IMAP-путь сообщения, по которому можно определить, через какие машины сообщение «пробиралось». Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты.

     2.3 Протоколы 
 

     Для работы в режиме обмена корреспонденции  по ЭП необходимы специальные программы. Существуют два основных стандарта E-Mail:

      • X.400, созданный International Telecommunications Union;

      • SMTP, разработанный IETF (Internet Engineering Task Force).

      Стандарт  Х.400 отличается строгостью, жёсткой  стандартизацией, наличием коммерческих операторов с гарантированным уровнем сервиса, поддержкой большого числа национальных кодировок. Этот стандарт в виду названных особенностей пользуется большой популярностью среди государственных организаций всего мира, при работе, в частности, по правительственным телекоммуникационным линиям.

     SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

     ESMTP (англ. Extended SMTP) — масштабируемое  расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают SMTP и его расширения.

     SMTP используется для отправки почты  от пользователей к серверам  и между серверами для дальнейшей  пересылки к получателю. Коды ответов SMTP и их значения приведены в приложении 4.

     Данные  передаются при помощи TCP, при этом обычно используется порт 25 или 587. При  передаче сообщений между серверами  используется только порт 25. Ограничения на размеры объектов SMTP представлены в приложении 5.

     Sendmail был одним из первых (если не первым) агентом отправки сообщений, который начал работать с SMTP. В настоящее время этот протокол является стандартным для электронной почты, и его используют все клиенты и серверы.

     Протокол  был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы. Для снятия этого ограничения был разработан стандарт MIME – (Multipurpose Internet Mail Extensions), который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME. Существующие типы и подтипы MIME представлены в приложении 6.

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

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

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

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

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

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