RFC 822
RFC 822 — это стандарт, опубликованный в 1982 году в рамках серии документов Request for Comments (RFC) Инженерного совета Интернета (IETF), который определяет формат сообщений электронной почты в сети ARPANET и, впоследствии, в Интернете. Полное название документа — «Standard for the Format of ARPA Internet Text Messages». RFC 822 установил базовую структуру письма, состоящую из заголовка (header) и тела (body), разделённых пустой строкой, а также специфицировал синтаксис полей заголовка, таких как «From», «To», «Subject», «Date» и других. Этот стандарт стал основой для всего современного обмена электронными письмами и был заменён более поздним стандартом RFC 2822 в 2001 году, который, в свою очередь, уступил место RFC 5322.
История
До появления RFC 822 электронная почта в сети ARPANET использовала разнородные форматы, определённые в более ранних документах, таких как RFC 680, RFC 724 и RFC 733. Последний, RFC 733 («Standard for the Format of ARPA Network Text Messages», 1977 год), уже задавал общую структуру, но его спецификация была недостаточно строгой и допускала множественные интерпретации. К началу 1980-х годов, с ростом числа узлов и пользователей ARPANET, возникла необходимость в едином, чётко определённом стандарте, который обеспечил бы совместимость между различными почтовыми программами.
RFC 822 был разработан Дэвидом Крокером (David H. Crocker) и опубликован 13 августа 1982 года. Он отменил действие RFC 733 и ввёл строго формализованное описание структуры сообщения, используя расширенную форму Бэкуса-Наура (ABNF). Документ предназначался для передачи текстовых сообщений, состоящих исключительно из символов ASCII (7-битная кодировка). Это ограничение стало основным недостатком стандарта в эпоху глобализации и необходимости поддержки национальных алфавитов.
В 2001 году RFC 822 был заменён на RFC 2822 («Internet Message Format»), который сохранил базовую архитектуру, но уточнил синтаксис, устранил неоднозначности и добавил поддержку MIME-расширений (Multipurpose Internet Mail Extensions). В 2008 году RFC 2822 был, в свою очередь, заменён на RFC 5322, который является действующим стандартом на сегодняшний день.
Структура сообщения по RFC 822
Сообщение электронной почты в соответствии с RFC 822 состоит из двух частей: заголовка и тела. Разделителем между ними служит пустая строка (последовательность символов CRLF CRLF — Carriage Return, Line Feed).
Заголовок (Header)
Заголовок представляет собой набор полей (fields), каждое из которых записывается в формате: Имя_поля: значение. Имя поля (field name) — это последовательность печатных символов ASCII, за исключением двоеточия. Значение (field body) может занимать несколько строк, при этом последующие строки должны начинаться с пробела или табуляции (продолжение строки с отступом). RFC 822 определял обязательные и необязательные поля.
Обязательные поля
- Date — дата и время отправки сообщения. Формат:
Date: день, число месяц год часы:минуты:секунды часовой_пояс, например:Date: Tue, 14 Aug 1984 10:30:00 +0300. - From — адрес отправителя. Может содержать одно или несколько адресов (в случае групповой отправки). Пример:
From: Ivan Petrov ivan@example.com.
Необязательные поля (наиболее распространённые)
- To — адрес(а) получателя. Может содержать один или несколько адресов, разделённых запятыми.
- Subject — тема письма. Текстовая строка, не должна содержать символы перевода строки.
- Cc (Carbon Copy) — адреса получателей копии.
- Bcc (Blind Carbon Copy) — адреса получателей скрытой копии (не отображается в заголовке письма, полученного другими адресатами).
- Reply-To — адрес, на который следует отправлять ответ (если отличается от From).
- Message-ID — уникальный идентификатор сообщения, генерируемый почтовой системой отправителя. Формат:
<строка@домен>. Используется для связывания писем в цепочки и предотвращения дублирования. - In-Reply-To — ссылка на Message-ID письма, на которое даётся ответ.
- References — список Message-ID писем, относящихся к той же теме (используется для построения веток обсуждения).
- Keywords — ключевые слова, используемые для фильтрации или сортировки.
- Received — поле, добавляемое каждым почтовым сервером при пересылке письма. Содержит информацию о маршруте (хост, IP-адрес, время). Позволяет отследить путь письма от отправителя до получателя.
Тело (Body)
Тело сообщения в RFC 822 — это произвольная последовательность строк, состоящих из символов ASCII (7-битных). Длина каждой строки не должна превышать 998 символов, но рекомендуется ограничивать её 78 символами для удобочитаемости. Тело отделяется от заголовка пустой строкой. В рамках оригинального стандарта тело не могло содержать двоичные данные или символы национальных алфавитов. Для передачи таких данных потребовалось создание расширений, в первую очередь MIME.
Ограничения и недостатки
Основным ограничением RFC 822 была ориентация исключительно на 7-битный ASCII. Это делало невозможным отправку писем с символами кириллицы, иероглифами, а также вложений в виде изображений, аудио или исполняемых файлов без дополнительного кодирования. Попытки вставлять 8-битные символы напрямую приводили к несовместимости и искажению текста при прохождении через некоторые почтовые серверы.
Кроме того, стандарт не регламентировал поведение почтовых клиентов при отображении длинных строк, а также не предусматривал механизмов для подтверждения доставки или шифрования содержимого. Отсутствие строгих правил для поля Subject приводило к проблемам с отображением тем в разных кодировках.
Наследие и влияние
RFC 822 стал фундаментом для всей инфраструктуры электронной почты. Его простая и чёткая структура (заголовок — пустая строка — тело) оказалась настолько удачной, что была сохранена во всех последующих версиях стандарта. Формат полей заголовка, определённый в RFC 822, используется и сегодня, хотя и с расширениями.
Разработка MIME (RFC 2045–2049) в 1992 году позволила преодолеть ограничение на 7-битный ASCII, добавив возможность указывать тип содержимого (Content-Type) и кодировку (Content-Transfer-Encoding). Это сделало возможным отправку писем с HTML-разметкой, вложениями и текстом в Unicode.
RFC 822 также оказал влияние на другие протоколы и форматы. Например, структура заголовков HTTP (HyperText Transfer Protocol) во многом заимствована из почтового стандарта: поля Content-Type, Content-Length, Date и другие имеют прямые аналоги в RFC 822.
Пример сообщения в формате RFC 822
``` Date: Wed, 15 Jun 2022 14:30:00 +0300 From: "Алексей Смирнов" alexey@example.org To: "Мария Иванова" maria@example.com Subject: Встреча во вторник Message-ID: 20220615143000.12345@mail.example.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit
Здравствуйте, Мария!
Напоминаю, что наша встреча запланирована на вторник, 21 июня, в 15:00.
С уважением, Алексей ```
В данном примере показано, как современное письмо использует структуру RFC 822, но с добавлением MIME-полей для указания кодировки UTF-8 и типа содержимого. Само тело письма содержит кириллические символы, что стало возможным благодаря MIME-расширениям, а не исходному стандарту.
Источники
- Crocker, D. (1982). Standard for the Format of ARPA Internet Text Messages. RFC 822. IETF.
- Resnick, P. (2001). Internet Message Format. RFC 2822. IETF.
- Resnick, P. (2008). Internet Message Format. RFC 5322. IETF.
- Freed, N., & Borenstein, N. (1996). Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045. IETF.
- Крокер, Д. (1982). Стандарт формата текстовых сообщений ARPA Internet. RFC 822 (оригинальный текст на английском языке).
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →