Компьютерные сети. 6-е изд.

7.2. Электронная почта

Электронная почта, или как ее часто называют — e-mail, существует уже более четырех десятилетий. Она быстрее и дешевле обычной почты и стала популярной с первых дней интернета. До 1990 года электронная почта использовалась преимущественно в научных организациях. В 1990-е годы с ней познакомились широкие слои населения, и ее использование выросло в геометрической прогрессии. В результате число ежедневно отправляемых электронных писем во много раз превышает количество бумажных. За последнее десятилетие стали популярными и другие формы интернет-коммуникации, например обмен мгновенными сообщениями и IP-телефония, но электронная почта по-прежнему остается основным средством сетевого общения. К примеру, она широко применяется для внутрикорпоративной связи на предприятиях, что позволяет обеспечить участие географически удаленных сотрудников в работе над сложными проектами. К сожалению, как и в случае обычной поч­ты, девять из десяти электронных писем — это рекламная рассылка, то есть спам. Хотя современные почтовые системы удаляют большую часть таких сообщений, многие из них все же достигают адресата. Поиск способов, позволяющих обнаружить весь спам, продолжается (Дэн и др.; Dan et al., 2019; Чжан и др.; Zhang et al., 2019).

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

В электронной почте широко используются жаргонные сокращения, например BTW (By The Way — «кстати»), ROFL (Rolling On the Floor Laughing — «катаюсь по полу от смеха») и IMHO (In My Humble Opinion — «на мой взгляд»). Многие пользователи также используют комбинации символов ASCII, то есть смайлы. Например, комбинацию «:-)» можно увидеть повсюду. Этот и другие эмотиконы (символы эмоций) помогают передать тон сообщения. Они широко применяются и в других видах коммуникации, таких как обмен мгновенными сообщениями, обычно в виде графических знаков — эмодзи. Современные смартфоны позволяют использовать сотни эмодзи.

За время существования электронной почты ее протоколы существенно изменились. Первые системы e-mail состояли из протокола передачи файлов с условием, что первая строка каждого сообщения (то есть файла) должна содержать адрес получателя. Постепенно электронная почта отошла от передачи файлов и получила множество новых функций, таких как рассылка сообщения сразу нескольким адресатам. В 1990-х годах добавилась передача мультимедийных данных — писем с изображениями и другой нетекстовой информацией. Серьезно изменились и программы для чтения электронной почты: на смену текстовому пришел графический пользовательский интерфейс. Также у пользователей появился доступ к почте с ноутбука вне зависимости от местонахождения. Наконец, из-за повсеместного засилия спама почтовые программы научились худо-бедно находить и удалять нежелательные письма.

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

7.2.1. Архитектура и службы

В данном разделе мы рассмотрим возможности и организацию систем электронной почты; ее архитектура показана на илл. 7.9. Система e-mail состоит из двух подсистем: пользовательских агентов (user agents), позволяющих пользователям читать и отправлять письма, и агентов передачи сообщений (message transfer agents), пересылающих письма от отправителя к получателю; последних мы будем неформально называть почтовыми серверами (mail servers).

Илл. 7.9. Архитектура системы e-mail

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

Обработка сообщений может частично автоматизироваться с учетом пожеланий пользователя. Например, входящая почта может фильтроваться с целью выявления или снижения приоритета сообщений, похожих на спам. Некоторые пользовательские агенты предлагают такие продвинутые возможности, как автоматическая отправка ответных сообщений («Я в отпуске и смогу связаться с Вами лишь спустя некоторое время»). Пользовательский агент работает на том же компьютере, на котором пользователь читает свою почту. Это обычная программа, которую можно запускать время от времени.

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

SMTP был впервые описан в RFC 821. Позже в него вносились изменения вплоть до текущей редакции RFC 5321. Он отправляет сообщения по соединениям и высылает обратно отчеты о статусе доставки и любых возникших ошибках. Существует множество ситуаций, в которых подтверждение доставки имеет большую важность и даже может иметь юридическое значение («Ваша честь, моя электронная система не очень надежна, и я полагаю, что электронная повестка в суд где-то потерялась»).

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

Соединение пользовательских агентов и агентов передачи сообщений обеспечивают почтовые ящики и стандартный формат почтовых сообщений. Почтовые ящики (mailboxes) хранят доставленную почту. Они обслуживаются почтовыми серверами. Пользовательские агенты просто предоставляют людям возможность увидеть содержимое их почтовых ящиков. Для этого агент отправляет команды почтовым серверам и получает возможность управлять почтовыми ящиками (проверять содержимое, удалять сообщения и т.д.). Получение почты — это ее доставка конечному пользователю на илл. 7.9 (шаг 3). При такой архитектуре один пользователь может использовать различные агенты на разных устройствах, чтобы получить доступ к одному и тому же почтовому ящику.

Почта пересылается между агентами передачи сообщений в стандартном формате. Первоначальный формат, RFC 822, был существенно переработан. Текущая версия носит название RFC 5322; в нее включена поддержка мультимедиа-контента и международный текст. Эта схема получила название «MIME». Однако многие по-прежнему называют электронную почту «RFC 822».

В основе данного формата сообщений лежит четкое разграничение между конвертом (envelope) и его наполнением. Конверт содержит в себе сообщение, а также всю информацию, необходимую для его доставки: адрес получателя, приоритет, уровень секретности и т.п. Все эти сведения отделены от самого сообщения. Агенты передачи сообщений используют конверт для маршрутизации, аналогично тому, как это делает обычная почтовая служба.

Сообщение внутри конверта состоит из двух отдельных частей: заголовка (header) и тела (body). В заголовке указана управляющая информация для пользовательских агентов. Тело письма целиком предназначается для человека-адресата. Примеры конвертов и сообщений показаны на илл. 7.10.

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

Илл. 7.10. Конверты и сообщения. (а) Обычное письмо. (б) Электронное письмо

7.2.2. Пользовательский агент

Пользовательский агент — это программа (иногда ее называют «почтовиком» — email reader), выполняющая разнообразные команды для составления и получения сообщений, ответа на них, а также для управления почтовыми ящиками. Существует множество популярных пользовательских агентов, включая Google Gmail, Microsoft Outlook, Mozilla Thunderbird и Apple Mail. Внешне они могут сильно различаться. Графический интерфейс часто основан на меню или на значках и требует наличия мыши или сенсорного интерфейса (на небольших мобильных устройствах). Более ранние пользовательские агенты (Elm, mh или Pine) имеют текстовый интерфейс и работают при помощи ввода с клавиатуры однобуквенных команд. С точки зрения функциональности это то же самое, по крайней мере в отношении текстовых сообщений.

Типичные элементы интерфейса пользовательского агента показаны на илл. 7.11. Агент, которым пользуетесь вы, наверняка выглядит гораздо более современно, но функции, скорее всего, совпадают. Когда агент запущен, обычно он отображает сводную таблицу сообщений в почтовом ящике. Часто каждому сообщению соответствует одна строка, а идут они в каком-либо порядке, выбранном при сор­тировке. В сводной таблице выделены ключевые поля сообщения, извлеченные из конверта или заголовка.

Илл. 7.11. Стандартные элементы интерфейса пользовательского агента

На илл. 7.11 представлены семь строк сводной таблицы. В строках используются поля From (От), Subject (Тема) и Received (Получено); именно в таком порядке. В них указано, от кого это сообщение, о чем оно и когда пришло. Вся информация удобно отформатирована; она не отображает содержание полей сообщения полностью, но основана на них. Таким образом, те, кто отправляет сообщения без темы, часто сталкиваются с тем, что их письмам присваивается низкий приоритет.

Поля и маркеры бывают очень разнообразными. Значки рядом с темой (см. илл. 7.11) могут обозначать, например, непрочитанное письмо (конверт), прикрепленный файл (скрепка) или важное, по крайней мере с точки зрения отправителя, сообщение (восклицательный знак).

Также возможны несколько вариантов сортировки. Самый распространенный — по времени получения; сначала более свежие письма, с маркером, указывающим на то, прочитано сообщение или нет. Поля сводной таблицы и порядок сортировки можно настроить по желанию пользователя.

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

Прочитав сообщение, вы можете решить, что с ним делать. Это называется размещением сообщения (message disposition). Письмо можно удалить, написать ответ, переслать его другому пользователю и оставить в ящике для дальнейшей работы. В большинстве агентов присутствует один почтовый ящик для входящих и набор папок для сохраненной почты. Это позволяет распределять сообщения по разным категориям в зависимости от отправителя, темы и т.д.

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

Но какой же спам встречается чаще всего? Спам генерируется сетью взломанных вычислительных устройств — ботнетом (botnet), а его содержание зависит от страны, в которой вы живете. В Азии часто предлагают приобрести поддельные дипломы, в США — дешевые лекарства и другую сомнительную продукцию. В большом количестве предлагаются невостребованные счета в нигерийском банке. Ну а таблетки для увеличения определенных частей тела входят в топ-лист, где бы вы ни жили.

Правила распределения писем по папкам пользователь может установить сам. Каждое правило определяет состояние и действие. Например, оно может гласить, что письмо от руководителя должно перемещаться в папку для немедленного прочтения, а письма от определенного списка людей должны помещаться в другую папку, чтобы их можно было прочитать позже. На илл. 7.11 изображено несколько папок. Самые важные — это Входящие (для почты, которая не была никуда распределена при получении) и Спам (для сообщений, которые программа посчитала нежелательными).

7.2.3. Форматы сообщений

Перейдем от рассмотрения пользовательского интерфейса к формату самих сообщений электронной почты. Чтобы сообщения, отсылаемые пользовательским агентом, обрабатывались агентами передачи сообщений, они должны быть оформлены в соответствии с определенными стандартами. Прежде всего мы рассмотрим базовый ASCII-формат электронного письма стандарта RFC 5322. Это последний вариант оригинального формата интернет-сообщений, описанного в стандарте RFC 822 и его многочисленных обновлениях. Затем мы познакомимся с мультимедийным расширением этого первоначального стандарта.

RFC 5322 — формат интернет-сообщений

Сообщения состоят из примитивного конверта (в RFC 5321 он описан как часть SMTP), нескольких полей заголовка, пустой строки и тела сообщения. Каждое поле заголовка состоит (логически) из одной строки ASCII-текста, содержащей имя поля, двоеточие и значение поля (в большинстве случаев). Первоначальный RFC 822 был создан несколько десятилетий назад, и в нем нет четкого разграничения конверта и заголовка. Хотя частично стандарт был пересмотрен в RFC 5322, целиком обновить его было невозможно, поскольку RFC 822 уже широко применялся. Обычно пользовательский агент формирует сообщение и передает его агенту передачи сообщений, который с помощью одного из полей заголовка создает конверт. Получается несколько старомодное сочетание письма и конверта.

Основные поля заголовка, связанные с транспортировкой сообщения, перечислены на илл. 7.12. Поле To: (Кому) содержит адрес электронной почты основного получателя (их может быть несколько). В поле Cc:(Carbon copy — Копия; буквально «под копирку») указываются адреса дополнительных получателей. С точки зрения доставки никаких отличий между основным и дополнительными получателями нет. Разница между ними чисто психологическая и важна только для людей, но не для почтовой системы. Обозначение Cc: несколько устарело, ведь компьютеры не используют копировальную бумагу, но термин прижился. Поле Bcc: (Blind carbon copy — Скрытая копия) аналогично предыдущему, но в этом случае строка поля удаляется из всех экземпляров сообщения, отправленных как основному, так и дополнительным получателям. Это позволяет рассылать письмо одновременно нескольким получателям, и они не будут знать, что это письмо отправлено кому-то еще.

Поле

Значение

To:

Электронный адрес (адреса) основного получателя (получателей)

Cc:

Электронный адрес (адреса) дополнительного получателя (получателей)

Bcc:

Электронный адрес (адреса) получателей скрытой копии

From:

Автор (авторы) сообщения

Sender:

Электронный адрес отправителя

Received:

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

Return-Path:

Может быть использовано для идентификации обратного пути к отправителю

Илл. 7.12. Поля заголовка стандарта RFC 5322, связанные с транспортировкой сообщения

Следующие два поля, From: (От) и Sender: (Отправитель), сообщают, соответственно, кто составил и отправил сообщение. Это могут быть разные люди. Например, написать письмо может руководитель предприятия, а отослать — его секретарь. В этом случае в поле From: будет указано имя руководителя, а в поле Sender: — имя секретаря. Поле From: является обязательным, тогда как поле Sender: может быть опущено, если его содержимое не отличается от содержимого поля From:. Эти поля нужны на случай, если сообщение доставить невозможно и об этом нужно проинформировать отправителя. Кроме того, на адреса, указанные в этих полях, может быть выслан ответ.

Строка, содержащая поле Received: (Получено), добавляется каждым агентом передачи сообщений на пути следования письма. В это поле помещается идентификатор агента, дата и время получения сообщения, а также другая информация, которая может быть использована для исправления неисправностей в системе маршрутизации. Поле Return-Path: (Обратный путь) добавляется последним агентом передачи сообщений. Предполагалось, что это поле будет сообщать, как добраться до отправителя. Теоретически эта информация может быть собрана из всех полей Received: (кроме имени почтового ящика отправителя), но на практике оно редко заполняется и обычно просто содержит адрес отправителя.

Помимо полей, показанных на илл. 7.12, сообщения стандарта RFC 5322 могут также включать широкий спектр полей заголовка, используемых пользовательским агентом или самим пользователем. Наиболее распространенные поля заголовка приведены на илл. 7.13. Информации в таблице достаточно, чтобы понять назначение полей, поэтому мы не будем рассматривать их подробно.

Поле

Значение

Date:

Дата и время отправки сообщения

Reply-to:

Электронный адрес, на который следует присылать ответ

Message-Id:

Уникальный номер для последующей ссылки на это сообщение

In-Reply-To:

Идентификатор Message-Id сообщения, в ответ на которое отправляется это сообщение

References:

Другие важные ссылки (идентификаторы Message-Id)

Keywords:

Ключевые слова, выбираемые пользователем

Subject:

Краткое изложение сообщения для отображения в одной строке (тема письма)

Илл. 7.13. Некоторые поля, используемые в заголовке сообщения стандарта RFC 5322

Поле Reply-to: (Обратный адрес) иногда применяется в случае, если ни составитель письма, ни его отправитель не хотят получать на него ответ. Например, управляющий отделом сбыта может написать письмо, информирующее клиентов о новом продукте. Это письмо отправляется его секретарем, но в поле Reply-to: указан адрес менеджера отдела продаж, который может ответить на вопросы и принять заказы. Это поле также может пригодиться, если у отправителя есть два электронных адреса и он хочет, чтобы ответы приходили на второй адрес.

Message-Id: (Идентификатор сообщения) — автоматически генерируемое число, которое используется, чтобы связывать сообщения (например, при ответе на письмо) и избежать повторной доставки.

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

После заголовков идет тело самого сообщения. Пользователь может разместить в нем все, что ему угодно. Некоторые люди завершают свои послания сложными подписями с популярными или малоизвестными цитатами, политическими заявлениями и разнообразными объявлениями (например, «Корпорация АБВ не несет ответственности за высказанное выше мнение. Собственно, она даже не в силах его постичь»).

MIME — многоцелевые расширения интернет-почты

На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений на английском языке, представленных символами ASCII. В таких условиях первоначального стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. В 1990-е годы повсеместное распространение интернета и необходимость передавать через почтовую систему более разнообразный контент показали, что такой подход уже не отвечает требованиям. К примеру, нужно было обеспечить передачу сообщений на разных языках: с диакритическими знаками (французском или немецком), с алфавитом, отличным от латинского (иврите или русском), или вовсе без алфавита (китайском или японском). Также требовалась возможность отправки сообщений, не являющихся текстом (например, аудио, изображений или бинарных документов и программ).

Решением стала разработка стандарта многоцелевых расширений интернет-почты (Multipurpose Internet Mail Extensions, MIME). Он широко применяется как для сообщений электронной почты, передаваемых по интернету, так и для описания контента в других случаях, например при просмотре сайтов. Изначально MIME описан в RFC 2045, а последующие его версии — в RFC 4288 и 4289.

Основная идея стандарта MIME сводилась к тому, чтобы продолжить использование формата RFC 822, но при этом придать структуру телу сообщения и определить правила кодирования для пересылки сообщений без ASCII-символов. Не отклоняясь от стандарта RFC 822, MIME-сообщения могут передаваться с помощью обычных агентов передачи сообщений и протоколов (ранее основанных на RFC 821, а сейчас на RFC 5321). Все, что нужно было изменить, — отправляющие и принимающие программы; это пользователи могли сделать самостоятельно.

MIME задает пять новых заголовков сообщений (илл. 7.14). Первый заголовок (MIME-Version:) просто информирует пользовательского агента, что он имеет дело с сообщением MIME, и указывает номер версии MIME. Если в сообщении нет такого заголовка, то оно считается написанным на английском языке (или по крайней мере использующим только ASCII-символы) и обрабатывается соответственно.

Поле

Значение

MIME-Version:

Указывает версию MIME

Content-Description:

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

Content-Id:

Уникальный идентификатор

Content-Transfer-Encoding:

Указывает способ кодировки тела сообщения для его передачи

Content-Type:

Тип и формат содержимого сообщения

Илл. 7.14. Заголовки сообщений, добавленные в стандарте MIME

Заголовок Content-Description: (Описание содержимого) представляет собой ASCII-строку, информирующую о том, что находится в сообщении. Он позволяет пользователю принять решение о том, нужно ли ему декодировать и читать сообщение. Если в строке сказано: «Фото хомяка Арона», а получатель не любит хомяков, скорее всего, он сразу удалит это сообщение и не станет перекодировать его в цветную фотографию высокого разрешения.

Заголовок Content-Id: (Идентификатор содержимого) идентифицирует данные в сообщении. В нем используется тот же формат, что и в стандартном заголовке Message-Id:.

В заголовке Content-Transfer-Encoding: (Кодировка содержимого для передачи) сказано, как тело сообщения было упаковано для отправки по сети. При разработке MIME основной проблемой было то, что протоколы электронной почты (SMTP) предполагали использование ASCII-сообщений с длиной строк не более 1000 символов. Символы ASCII задействуют 7 бит из каждого восьмибитного байта. Бинарные данные, такие как исполняемые программы и изображения, используют все 8 бит байта, так же как и расширенные наборы символов. Не было никакой гарантии безопасной передачи таких данных. Требовался метод передачи бинарных данных в виде обычного почтового сообщения ASCII. Расширения SMTP, введенные с момента разработки MIME, позволяют пересылать восьмибитные бинарные данные, но даже сегодня эти данные не всегда корректно передаются почтовой системой, будучи незакодированными.

MIME предоставляет пять схем кодирования для передачи данных (также можно добавлять новые схемы — на всякий случай). Самая простая схема — обычные текстовые сообщения ASCII. Символы ASCII используют 7 бит и могут передаваться напрямую протоколом электронной почты, при условии, что строка не превышает 1000 символов.

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

Далее идут сообщения в настоящей двоичной кодировке. К ним относятся произвольные двоичные файлы, которые не только используют все 8 бит, но и не соблюдают ограничение на 1000 символов в строке. К этой категории относятся исполняемые программные файлы. Сегодня почтовые серверы могут проверять, есть ли возможность переслать данные в бинарной (или 8-битной) кодировке, и если это расширение не поддерживается на обеих сторонах, данные будут передаваться в ASCII.

Кодировка бинарных данных в формате ASCII называется 64-символьной кодировкой (base64 encoding). При использовании данного метода группы по 24 бита разбиваются на четыре единицы по 6 бит, каждая из которых передается в виде обычного разрешенного ASCII-символа. В этой кодировке 6-битный символ 0 кодируется ASCII-символом A, 1 — ASCII-символом B и т.д. Затем следуют 26 строчных букв, затем 10 цифр и, наконец, + для кодирования 62 и / для 63. Последовательности == и = говорят о том, что последняя группа содержит только 8 или 16 бит соответственно. Символы перевода строки и возврата каретки игнорируются, поэтому их можно вставлять в любом месте закодированного потока символов, чтобы строки были достаточно короткими. Таким способом можно передать любой двоичный код, хотя и не слишком эффективно. Эта кодировка была крайне популярна до того, как стали широко применяться почтовые серверы, способные передавать бинарную информацию. Она часто встречается и сегодня.

Особый интерес представляет последний заголовок на илл. 7.14, Content-Type: (Тип содержания). В нем указан тип тела сообщения. Применение этого заголовка выходит далеко за пределы электронной почты. Например, контент, загружаемый из интернета, получает метку MIME-типа, что позволяет браузеру корректно отображать информацию. Так же обстоит дело с данными, которые передаются через потоковое мультимедиа и в реальном времени (например, в IP-телефонии).

Изначально в RFC 1521 были определены семь MIME-типов. У каждого из них есть один или несколько доступных подтипов. Подтип отделяется от типа косой чертой, например: Content-Type: video/mpeg. Впоследствии было добавлено более 2700 подтипов, а также два новых типа (font и model). Новые сущности добавляются постоянно, по мере появления новых типов контента.

Список утвержденных типов и подтипов поддерживается организацией IANA и расположен по адресу www.iana.org/assignments/media-types. Существующие типы, а также несколько примеров часто используемых подтипов показаны на илл. 7.15.

Тип

Примеры подтипов

Описание

text

plain, html, xml, css

Текст в различных форматах

image

gif, jpeg, tiff

Изображения

audio

basic, mpeg, mp4

Звуки

video

mpeg, mp4, quicktime

Видеофильмы

font

otf, ttf

Шрифты для форматирования текста

model

vrml

3D-модель

application

onoctet-stream, pdf, javascript, zip

Данные, производимые приложениями

message

http, rfc822

Инкапсулированное сообщение

multipart

mixed, alternative, parallel, digest

Комбинация нескольких типов

Илл. 7.15. Типы содержания MIME и примеры подтипов

Назначение MIME-типов на илл. 7.15 вполне очевидно, за исключением, возможно, последнего. Тип multipart служит для передачи сообщений с несколькими вложениями разного MIME-типа.

7.2.4. Пересылка сообщений

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

Проще всего установить транспортное соединение между компьютером-источником и компьютером-получателем, а затем передать по нему сообщение. Так изначально и работал протокол SMTP. Однако со временем возникли два разных способа его применения. Первый — подача почтового сообщения, шаг 1 в архитектуре e-mail на илл. 7.9. Так пользовательские агенты передают данные в почтовую систему для их дальнейшей отправки. Вторым способом является пересылка сообщений между агентами передачи сообщений (шаг 2 на илл. 7.9). Такая последовательность обеспечивает доставку почты на всем пути от отправляющего до получающего агента передачи сообщений за один шаг. Окончательная доставка происходит при участии других протоколов, которые мы опишем в следующем разделе.

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

SMTP и его расширения

В интернете для доставки электронной почты компьютер-источник устанавливает TCP-соединение с портом 25 компьютера-получателя. Этот порт прослушивается почтовым сервером, который поддерживает простой протокол передачи электронной почты (Simple Mail Transfer Protocol, SMTP). Сервер проверяет безопасность входящих соединений, утверждает их и принимает сообщения для передачи. Если письмо невозможно доставить, отправителю возвращается отчет об ошибке, в котором содержится первая часть этого письма.

SMTP представляет собой простой ASCII-протокол. Это не недостаток, а его характерная особенность. Использование текста в формате ASCII позволяет легко модифицировать, тестировать и исправлять ошибки в протоколах. Они могут тестироваться отсылкой команд вручную, при этом записи сообщений легко читать. Сейчас так работает большинство интернет-протоколов прикладного уровня (например, HTTP).

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

Если сервер готов принимать почту, клиент сообщает, от кого она поступила и кому предназначается. Если такой получатель существует на этом направлении, сервер дает клиенту добро на пересылку сообщения. Тогда клиент отправляет его, а сервер подтверждает его получение. Контрольные суммы не проверяются, так как TCP обеспечивает надежный байтовый поток. Если у отправителя есть еще почта, она также отсылается. После передачи всей почты в обоих направлениях соединение разрывается. Пример такого диалога представлен на илл. 7.16. Здесь строки, отправленные клиентом (то есть отправителем), снабжены префиксом C:. Строки, отправленные сервером (то есть получателем), снабжены префиксом S:.

Сначала клиент, естественно, отправляет серверу приветствие — HELO. Это наиболее удачный вариант сокращения слова HELLO до четырех символов. Зачем все эти команды нужно было сокращать до четырех символов, сейчас уже никто не помнит.

В нашем примере сообщение нужно отправить только одному получателю, поэтому используется только одна команда RCPT (от слова «recipient» — «получатель»). Использование этой команды несколько раз позволяет отослать одно сообщение ряду получателей. Каждая передача подтверждается или отвергается индивидуально. Даже если не получится передать сообщение некоторым получателям (из-за их отсутствия на этом направлении), сообщение все равно может быть доставлено по остальным адресам.

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

Базовый протокол SMTP хорошо работает, но имеет ряд ограничений. Прежде всего, он не предусматривает аутентификации. Это означает, что команда FROM в нашем примере может отобразить какой угодно адрес отправителя, что крайне удобно для рассылки спама. Еще одно ограничение протокола — он позволяет передавать сообщения в кодировке ASCII, но не бинарные данные. Именно поэтому для передачи MIME-контента приходилось использовать кодировку base64. Однако применение base64 при передаче почты ведет к неэффективному использованию пропускной способности, что становится проблемой в случае больших сообщений. Третье ограничение SMTP заключается в том, что он отсылает сообщение в незашифрованном виде. То есть сообщения никак не защищены от посторонних глаз.

S: 220 ee.uwa.edu.au - служба SMTP готова

C: HELO abcd.com

S: 250 cs.uchicago.edu приветствует ee.uwa.edu.au

C: MAIL FROM:

S: 250 подтверждаю отправителя

C: RCPT TO:

S: 250 подтверждаю получателя

C: DATA

S: 354 Отправляем письмо, завершая его символом ".", расположенным в отдельной строке

C: From: alice@cs.uchicago.edu

C: To: bob@ee.uwa.edu.au

C: MIME-Version: 1.0

C: Message-Id: <0704760941.AA00747@ee.uwa.edu.au>

C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm

C: Subject: Земля обошла вокруг Солнца целое число раз

C:

C: Это преамбула. Пользовательский агент игнорирует ее. Хорошего дня.

C:

C: --qwertyuiopasdfghjklzxcvbnm

C: Content-Type: text/html

C:

C:

С днем рожденья тебя!

C: С днем рожденья тебя!

C: С днем рождения, дорогой Боб!

C: С днем рожденья тебя!

C:

C: --qwertyuiopasdfghjklzxcvbnm

C: Content-Type: message/external-body;

C: access-type="anon-ftp";

C: site="bicycle.cs.uchicago.edu";

C: directory="pub";

C: name="birthday.snd"

C:

C: content-type: audio/basic

C: content-transfer-encoding: base64

C: --qwertyuiopasdfghjklzxcvbnm

C: .

S: 250 сообщение принято

C: QUIT

S: 221 ee.uwa.edu.au разрывает соединение

Илл. 7.16. Передача сообщения от alice@cs.uchicago.edu для bob@ee.uwa.edu.au

Чтобы справиться с этими и многими другими проблемами, связанными с передачей сообщений, к SMTP было добавлено расширение. Оно является обязательной частью стандарта RFC 5321. Использование SMTP с расширениями называется расширенным SMTP (Extended SMTP, ESMTP).

Клиенты, желающие применить ESMTP, на первом этапе высылают EHLO вместо HELO. Если этот вариант отвергается, сервер работает с обычным SMTP, а пользователь должен идти по стандартному пути. Если EHLO принимается, сервер сообщает, какие расширения он поддерживает. После этого клиент может использовать любое из них. Несколько стандартных расширений показаны на илл. 7.17. В таблице даны ключевые слова, в том виде, в каком они используются в механизме расширения, и описание нового функционала. Более подробно рассматривать расширения мы не будем.

Ключевое слово

Описание

AUTH

Аутентификация клиента

BINARYMIME

Сервер принимает бинарные сообщения

CHUNKING

Сервер принимает большие сообщения по частям

SIZE

Проверка размера сообщения перед попыткой отправки

STARTTLS

Переключение на безопасный канал (TLS; см. главу 8)

UTF8SMTP

Интернационализированный адрес

Илл. 7.17. Некоторые расширения SMTP

Чтобы лучше понять, как работает SMTP и другие рассмотренные в этой главе протоколы, попробуйте поработать с ними самостоятельно. Для начала найдите компьютер, подключенный к интернету. В системе UNIX (или Linux) наберите в командной строке:

telnet mail.isp.com 25

подставив вместо mail.isp.com DNS-имя почтового сервера провайдера. На компьютерах с Windows сначала, возможно, потребуется установить и запустить программу telnet (или ее аналог). В результате выполнения этой команды будет установлено telnet-соединение (то есть соединение TCP) с портом 25 данного компьютера. Порт 25 используется протоколом SMTP (какие порты задействованы в других стандартных протоколах, см. на илл. 6.34). В ответ на введенную команду вы получите что-то вроде этого:

Trying 192.30.200.66...

Connected to mail.isp.com

Escape character is 'ˆ]'.

220 mail.isp.com Smail #74 ready at Thu, 25 Sept 2019 13:26 +0200

Первые три строки приходят от telnet; они описывают, что делает программа. Последняя строка — от сервера SMTP удаленного компьютера; в ней говорится о готовности к общению с вашим компьютером и приему почты. Чтобы узнать о доступных командах, наберите

HELP

Начиная с этого момента возможен обмен последовательностями команд, показанными на илл. 7.16, если сервер готов принимать от вас почтовые сообщения. Вам придется вводить команды достаточно быстро, поскольку соединение может прерваться, если оно слишком долго не используется. Кроме того, не каждый почтовый сервер разрешает устанавливать telnet-соединение с неизвестным компьютером.

Подача почтовых сообщений

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

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

Эта удаленная коммуникация не является проблемой сама по себе. Именно для подобных случаев был разработан протокол TCP/IP. Однако провайдер (или компания) обычно без энтузиазма относится к тому, что некий удаленный пользователь может подавать сообщения на их почтовый сервер для доставки куда-то еще. Этот провайдер (или компания) держит сервер не на общественных началах. Кроме того, такой вид открытой почтовой станции (open mail relay) привлекает спамеров, поскольку у них есть возможность скрыть настоящего отправителя и таким образом затруднить идентификацию сообщения как спама.

Учитывая эти особенности, SMTP обычно используется для подачи писем с расширением AUTH. Оно позволяет серверу проверять данные отправителя (имя пользователя и пароль) для подтверждения того, что сервер должен предоставить почтовое обслуживание.

Есть еще несколько отличий в том, как SMTP используется при подаче почты. Например, может использоваться порт 587, а не порт 25, и SMTP-сервер может проверять и исправлять формат сообщений, отправленных пользовательским агентом. Чтобы больше узнать об использовании SMTP при подаче писем, вы можете ознакомиться со стандартом RFC 4409.

Физическая передача

Когда отправляющий агент передачи почты получает сообщение от пользовательского агента, он доставляет его получающему агенту передачи, используя SMTP. При этом источник использует адрес получателя. Взгляните на сообщение, отправляемое на адрес bob@ee.uwa.edu.au (на илл. 7.16). На какой почтовый сервер оно должно быть доставлено?

Чтобы правильно выбрать почтовый сервер, нужно обратиться к системе DNS. В предыдущем разделе было упомянуто, что DNS использует различные типы записей, включая MX («mail exchanger» — «обмен почтовыми сообщениями»). В данном случае выполняется DNS-запрос для записей MX домена ee.uwa.edu.au. Запрос возвращает упорядоченный список имен и IP-адресов одного или нескольких почтовых серверов.

Далее отправляющий агент создает TCP-соединение с IP-адресом почтового сервера на порте 25, чтобы связаться с принимающим агентом. Для передачи сообщения используется SMTP. Затем принимающий агент помещает сообщения для пользователя bob в нужный почтовый ящик, чтобы позднее Боб мог их прочитать. Этот шаг локальной доставки может включать перемещение сообщения между компьютерами при наличии разветвленной почтовой инфраструктуры.

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

Еще один пример перенаправления почты выглядит следующим образом. Допустим, Боб окончил Массачусетский технологический институт и доступен по еще одному адресу: bob@alum.mit.edu. Вместо того чтобы собирать почту с разных аккаунтов, Боб может сделать так, чтобы почта, приходящая на данный адрес, переправлялась на bob@ee.uwa.edu. В этом случае сообщения, отправленные на bob@alum.mit.edu, будут доставляться дважды. Сначала они будут отсылаться на почтовый сервер alum.mit.edu, а затем — на сервер ee.uwa.edu.au. Каждый из этих шагов является полноценной отдельной доставкой, если мы рассматриваем их с точки зрения агентов передачи почтовых сообщений.

7.2.5. Окончательная доставка

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

Сегодня пользовательский агент на ПК, ноутбуке или мобильном телефоне обычно не размещается на почтовом сервере компании или провайдера, а в случае Gmail он точно расположен на другом устройстве. Пользователи хотят иметь доступ к своей почте вне зависимости от того, где они находятся: с рабочего или домашнего компьютера, с ноутбука в командировках или из интернет-кафе. Им нужна возможность работы без постоянного соединения с сетью, с периодическим подключением к интернету для приема и отправки сообщений. Более того, пользователь может запускать несколько агентов в зависимости от того, каким компьютером ему удобно пользоваться в данный момент. Несколько пользовательских агентов даже могут работать одновременно.

В данном случае пользовательский агент должен отображать содержимое почтового ящика и позволять работать с ним удаленно. Для этого может задействоваться несколько разных протоколов, но только не SMTP. SMTP основан на механизме push. Для передачи сообщения ему необходимо соединение с удаленным сервером. Таким образом, окончательная доставка не может быть осуществлена по двум причинам: из-за того, что почтовый ящик должен храниться на агенте передачи почты, и из-за того, что пользовательский агент может быть не подключен к интернету, когда SMTP пытается передать сообщение.

Протокол IMAP

Одним из главных современных протоколов для окончательной доставки является протокол доступа к электронной почте (Internet Mail Access Protocol, IMAP ). Четвертая версия этого протокола определена в спецификации RFC 3501 и ее многочисленных обновлениях. Чтобы использовать IMAP, почтовый сервер запускает IMAP-сервер, который проверяет порт 143. Пользовательский агент запускает IMAP-клиент. Этот клиент соединяется с сервером и начинает передавать команды из списка, приведенного на илл. 7.18.

Сначала клиент устанавливает защищенное соединение, если это возможно (для соблюдения конфиденциальности сообщений и команд), а затем вводит логин и пароль или как-то иначе авторизуется на сервере. После входа в систему можно воспользоваться множеством команд, чтобы просматривать папки и сообщения или их фрагменты, помечать письма галочками для дальнейшего удаления и сор­тировать их по папкам. Обратите внимание, что во избежание неразберихи мы в этой главе используем слово «папка» (folder), имея в виду, что почтовый ящик состоит из нескольких папок. Однако в спецификации IMAP вместо папки используется термин «почтовый ящик» (mailbox). Получается, что у пользователя есть много ящиков IMAP, каждый из которых он видит как папку.

Протокол IMAP предоставляет разнообразные функции, например, можно упорядочить почту не по порядку ее поступления, а по атрибутам писем («показать первое письмо от Алисы»). На сервере также могут быть инструменты поиска сообщений по заданным критериям; клиент увидит только выбранные письма.

Команда

Описание

CAPABILITY

Перечислить возможности сервера

STARTTLS

Установить защищенное соединение (TLS, см. главу 8)

LOGIN

Войти на сервер, используя имя пользователя и пароль

AUTHENTICATE

Авторизоваться иным способом

SELECT

Выбрать папку

EXAMINE

Выбрать папку, предназначенную только для чтения

CREATE

Создать папку

DELETE

Удалить папку

RENAME

Переименовать папку

SUBSCRIBE

Добавить папку к активному набору

UNSUBSCRIBE

Удалить папку из активного набора

LIST

Перечислить доступные папки

LSUB

Перечислить активные папки

STATUS

Узнать статус папки

APPEND

Добавить сообщение в папку

CHECK

Просмотреть состояние выбранной папки (что именно входит в понятие «состояние», зависит от конкретной реализации сервера). Создать контрольную точку для папки

FETCH

Просмотреть сообщения в папке

SEARCH

Найти сообщения, находящиеся в папке

STORE

Изменить метки сообщения

COPY

Сделать копию сообщения в папке

EXPUNGE

Удалить отмеченные сообщения

UID

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

NOOP

Ничего не делать

CLOSE

Удалить помеченные сообщения и закрыть папку

LOGOUT

Выйти из системы и закрыть соединение

Илл. 7.18. Команды IMAP (версия 4)

IMAP — это улучшенная версия более раннего протокола окончательной доставки — протокола почтового отделения версии 3 (Post Office Protocol, version 3, POP3), описанного в RFC 1939. Протокол POP3 проще, но он поддерживает не так много функций и является менее безопасным при типичном использовании. Обычно почта загружается на компьютер с пользовательским агентом и не остается на почтовом сервере. Это облегчает жизнь серверу, но усложняет ее пользователю. Читать почту с нескольких устройств становится сложнее, а если компьютер с пользовательским агентом сломается, вся почта будет безвозвратно утеряна. Тем не менее POP3 все еще используется.

Кроме того, могут использоваться и частные протоколы, так как протокол работает между почтовым сервером и пользовательским агентом, который может разрабатываться одной компанией — производителем софта. Примером почтовой системы с частным протоколом является Microsoft Exchange.

Веб-почта

Популярной альтернативой IMAP и SMTP в деле предоставления почтовых услуг стало использование веб-интерфейса для отправки и получения сообщений. Широко применяются такие системы веб-почты (Webmail), как Google Mail, Microsoft Hotmail и Yahoo! Mail. Веб-служба электронной почты — это пример программного обеспечения (в данном случае почтового агента пользователя), которое предоставляется как интернет-служба.

В такой системе провайдер управляет почтовыми серверами как обычно, чтобы принимать сообщения для пользователей при помощи SMTP через порт 25. Однако пользовательский агент работает по-другому. Он является не отдельной программой, а пользовательским интерфейсом, который предоставляется через веб-страницы. То есть пользователи могут использовать любой понравившийся им браузер для доступа к своей почте и отправки новых сообщений.

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

Пользователь может кликать по многочисленным элементам страницы, отображающей его почтовый ящик, так что сообщения можно читать, удалять и т.д. Чтобы интерфейс лучше откликался на действия пользователя, веб-страницы часто используют код на JavaScript. Они запускаются локально на компьютере пользователя в ответ на определенные события (например, клики мышкой) и могут загружать на сервер и подгружать с сервера сообщения в фоновом режиме, чтобы подготовить к показу следующее письмо или подать новое. В этой модели подача почты происходит при использовании обычных веб-протоколов с отправкой данных по URL. Веб-сервер помещает сообщения в обычную, уже описанную нами систему доставки почты. Для безопасности также могут использоваться стандартные веб-протоколы. Они заботятся о шифровании веб-страниц, а не о том, является ли содержание страницы почтовым сообщением.