Последнее изменение файла: 2007.02.08
Скопировано с www.bog.pp.ru: 2024.04.19

Bog BOS: Формат сообщений интернет (от RFC822 к RFC2822)

Базовый формат почтовых сообщений (писем, messages) и статей USENET (article) определяется RFC 822 и его "наследником" RFC 2822. Каждое сообщение (письмо, message, статья, article) состоит из конверта и содержимого. Конверт хранит адресную информацию, необходимую для отправки и передачи сообщения получателю. Формат конверта определяется средой распространения. Для его автоматического создания может использоваться информация из содержимого сообщения. Стандарт определяет только формат содержимого сообщения и только в момент передачи, т.е. сообщения могут храниться совершенно в другом формате (например, в БД). RFC 1123 определяет, что MTA должен уметь обрабатывать сообщения размером до 64 КБ (но желательно и больше),

Сообщение делится на строки и состоит из секции заголовков и тела сообщения (возможно пустого). Формат тела сообщения не определяется, лишь говорится, что оно состоит из строк ASCII, точнее ANSI X3.4 (7-битные символы!), отделенных от секции заголовков пустой строкой (CRLF), которая должна присутствовать даже для пустого тела (чтобы отличить его от ошибочного сообщения с порезанным заголовком). Следует заметить, что хотя формат тела не определен, но передавать двоичные данные все же не следует, так как предполагается, что оно делится на строки, а символы конца строки могут модифицироваться при передаче в подсеть или при хранении. Существуют также правила "хорошего тона": при цитировании предыдущего письма, цитируемый текст предваряется знаком ">" (без пробела!); перед подписью вставляется строка "-- " (обратите внимание на пробел перед концм строки!). Длина строки должна быть не более 998 символов, но желательно не порождать строк длиной более 78 символов (не считая CRLF).

Заголовок делится на поля, некоторые из которых являются обязательными (Date и хотя бы одно из полей, описывающих отправителя: From, Sender, Reply-To). Опциональные поля описываются, но не являются обязательными. Можно добавлять свои поля (начинаются с X-). Порядок полей несущественен, но запрещено менять порядок полей Received и Resent-. Последствия присутствия нескольких полей с одинаковым именем непредсказуемы (явно запрещены для всех стандартизованных полей, кроме Comment, Keywords, Received и Resent-), кроме полей To, Cc и Bcc (содержимое соответствующих полей сливается). Поле занимает одну логическую строку и состоит из имени поля (символы от 0x21 до 0x7e, кроме двоеточия), двоеточия и тела поля (ASCII, кроме CR и LF; опять-таки только 7-битные символы!). Тело поля может быть разбито на несколько строк путем вставки CRLF перед пробельным символом (пробел или табуляция).

Тело поля может быть неструктурировано (строка текста) или структурировано. Структурированное тело поля состоит из специальных символов (круглые, угловые или квадратные скобки, @, точка, запятая, двоеточие, точка с запятой, обратная косая черта, кавычки), пробельных символов, строк в кавычках, комментариев (строка в круглых скобках), атомов (строка ASCII-символов, кроме пробельных, специальных и управляющих) и доменных констант (строка в квадратных скобках). Специальные символы теряют свое "специальное" значение, если им предшествует обратная косая черта. В структурированном теле поля несколько идущих подряд пробельных символов трактуются как один пробел. Комментарии могут быть вложенными, трактуются как один пробел. Регистр букв (символьная или строчная) различается только в текстовых строках. В частности, нет разницы между именем поля "From" и "froM". BS действует только до начала физической строки или строки в кавычках. При прохождении внутри сети CRLF может преобразовываться в CR, при выходе CR преобразуется обратно в CRLF (так что отдельные CR или LF использовать небезопасно, а в RFC 2822 явно запрещено).

Формат даты унаследован с 1970-х годов и выглядит так: Tue, 5 Feb 02 00:59:59 +0300. День недели с запятой и секунды с двоеточием можно опускать. Заметьте 2 цифры, отведенные на номер года в RFC 822 (увеличено до 4 цифр в RFC 1123, RFC 2822). Последнее слово определяет смещение локальной временной зоны относительно UTC в часах и минутах. Иногда используются сокращенные наименования временных зон вместо смещения, но это не рекомендуется (а в RFC 2822 явно запрещается). Для временной зоны UTC должно указываться смещение +0000. Смещение -0000 обозначает отсутствие информации о временной зоне.

Адрес почтового ящика состоит из локальной части (слова через точку, не интерпретируется, строчные и прописные буквы различаются), знака "@" и доменной части. Доменная часть - имена поддоменрв, разделенные точками или явное указание IP-адреса в квадратных скобках. Имя домена может быть полным или сокращенным (сокращенное имя домена вызывает множество неприятных ситуаций). Точка справа отсутствует. Не забывайте, что текст в круглых скобках является комментарием. Если имеется текст в угловых скобках, то именно он является адресом, а предваряющая его фраза является описанием адресата и предназначена для вывода на экран. Может быть указан явный маршрут (source routing), хотя не рекомендуется, а в RFC 2822 явно запрещается: список доменных имен (предваряемых знаком "@") через запятую, завершающийся двоеточием. Иногда в локальную часть адреса встраивают маршруты UUCP и других не TCP/IP сетей. Бытует также обычай встраивать source routing в локальную часть адреса с использованием символов процента в качестве разделителей хостов. Резервируется локальная часть адреса - Postmaster (регистр не важен). В каждом домене должен быть Postmaster, отвечающий за работу почты.

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

Часть синтаксиса описывается в RFC 2822 как "устаревший" (определенный в RFC 822 или исторически сложившийся). Сообщения с устаревшим синтаксисом не должны создаваться, но должны обрабатываться, если уж встретились. Например:

• отдельно стоящие CR или LF
• символ NUL
• точка внутри фразы
• пустая фраза
• строка продолжения из одних пробельных символов и комментариев
• номер года из 2 цифр
• указание временной зоны по имени вместо смещения
• явная маршрутизация в адресах (source routing) должна игнорироваться
• строка в кавычках в локальной части адреса
• пустые элементы списка адресов
• пробельные символы перед двоеточием в имени поля
• фразы в полях In-Reply-To и References

RFC 2822 посылает желающих использовать не-ASCII символы как в заголовках, так и в теле сообщения к MIME.

Date. Время, когда автор сообщения заявил, что оно готово к отправке (MUA может отложить отправку, например, до следующего соединения с интернет).

From. Отправитель сообщения (человек или процесс), указывается адрес почтового ящика или список адресов. Если отсутствует поле Sender, то в поле From обязательно должен быть один адрес. Если поле Sender присутствует в заголовке, то в поле From может быть несколько адресов через запятую (таким образом обозначаются авторы сообщения, реальный отправитель определяется полем Sender).

Sender. Определяет отправителя письма (см. выше описание поля From), указывается адрес почтового ящика. Обязательно, если в поле From указано несколько адресов. Сообщения об ошибках доставки почты посылаются ему (но не ответы на сообщения!).

Reply-To. Может содержать список адресов или групп адресов для ответа через запятую. Если присутствует, то ответ на сообщение не должен посылаться по адресу, указанному в поле From или Sender.

Должна быть учтена возможность совпадения адресов в полях From, Sender или Reply-To. Стандарт явным образом запрещает использовать чужие адреса в этих полях.

To. Адреса основных получателей сообщения или группы адресов через запятую.

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

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

Должен быть хотя бы один адрес в поле To, Cc или поле Bcc, даже пустое.

Message-ID. Уникальный идентификатор этой версии этого сообщения (добавление полей Received и Resent- и тому подобные преобразования не порождают новой версии). Уникальность гарантируется генерирующим хостом. Заключается в угловые скобки и состоит из части, однозначно идентифицирующей хост (доменное имя или явный адрес в квадратных скобках), и части, однозначно идентифицирующей сообщение внутри хоста, разделенных знаком "@". Необязательное поле, но крайне желательное.

In-Reply-To. Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые дается ответ в данном сообщении. Фразы удалены из RFC 2822.

References. Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые ссылается данное сообщение (содержимое полей Message-ID, In-Reply-To и References исходного сообшения). Фразы удалены из RFC 2822.

Некоторые почтовые системы позволяют пользователям перепосылать письмо без изменения полей заголовка. Надо отличать перепосылку (resending) от пересылки (forwarding). В этом случае добавляются поля "Resent-...", смысл которых совпадает со смыслом полей без слова Resent, но они относятся к субъекту, переславшему письмо: Resent-Reply-To (запрещен в RFC 2822), Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-cc, Resent-bcc, Resent-Message-ID. Вся группа полей должна быть добавлена в начало сообщения вместе, так чтобы самые "свежие" поля Resent- стояли в начале заголовка, остальные заголовки меняться не должны. Если данная группа полей используется, то поля Resent-From и Resent-Date должны быть.

Keywords. Ключевые слова или фразы в кавычках, разделенные запятыми.

Subject. Тема сообщения. Неструктурированный текст. Ответное сообщение обычно имеет ту же тему, перед которой стоит строка "Re: ".

Comments. Неструктурированный текст.

Return-Path. RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821). Согласно RFC 822 поле добавляется последней транспортной системой (MTA), которая отправляет сообщение получателю, и содержит информацию достаточную этому MTA для определения обратного маршрута (совершенно необходимо для протоколов типа UUCP). Необязательное поле, но если есть, то также должно быть хотя бы одно поле Received. Представляет собой адрес почтового ящика в угловых скобках, перед которым может быть записана цепочка имен хостов, предваряемых знаком "@" и двоеточие. Адрес может быть пустым (<>), используется для предотвращения зацикливания сообщений об ошибках.

Received. Добавляется каждым MTA по пути следования сообщения. RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821). Согласно RFC 822 тело поля содержит следующую информацию (обязательно только with, причем их может быть несколько, и время):

1. from домен (от какого хоста получено данным MTA, полное каноническое имя; записывается имя, сообщенное отправившим MTA и затем (в скобках) его реальный IP-адрес и имя; при несовпадении прямой и обратной проверки DNS записывается предупреждение)
2. by домен (на каком хосте работает данный MTA, полное каноническое имя; здесь же обычно записывается название MTA и номер версии)
3. via атом (физическая сеть: Internet, JANET, хотя встречаются и слова типа HTTP)
4. with атом (почтовый протокол - SMTP, ESMTP)
5. id идентификатор-сообщения (внутренний идентификатор принимающего MTA, если он хранит сообщение в очереди)
6. for адрес (если принимающий MTA преобразует адрес получателя, то здесь сохраняется исходная форма)
7. ; время-получения (формат такой же, как у поля Date)

Encrypted. Первое слово определяет программу шифрования, второе - индекс в таблице ключей. Удален в RFC 2822.

Content-Type. Введено RFC 1049 для автоматического распознавания типа содержимого тела сообщения.

Encoding. Введено RFC 1505 для автоматического распознавания типа содержимого тела сообщения (см. ниже).

RFC 934 предлагает при включении письма внутрь другого письма с целью его пересылки (письма делятся на оригинальные, ответы - reply, пересылаемые письма - forward, распространяемые письма - distribution) отделять его строками тире. До сих пор используется (Netscape называет это "forward inline" в противовес MIME-стилю "forward as attach"). Предусмотрена неограниченная вложенность.

RFC 1153 определяет формат упаковки нескольких сообщений списка рассылки в одно. Поле Subject содержит имя списка, слово Digest, буква V, за которой следует номер тома, символ диез, за которым следует номер выпуска. Тело сообщения содержит преамбулу (обычно содержит оглавление из полей Subject, включенных сообщений), одно или несколько включенных сообщений и завершающий текст. Включенное сообщение содержит поля заголовка Date, From, To, Cc, Subject, Mesage-ID, Keywords из исходного сообщения (обязательно в этом порядке), пустую строку и тело исходного сообщения. Преамбула отделяется 70-ю знаками тире и пустой строкой. После каждого включенного сообщения ставится пустая строка, строка из 30 тире и еще одна пустая строка. Завершающий текст состоит из 2 строк. Первая содержит слова End of , за которыми следует имя списка, слово Digest, буква V, за которой следует номер тома, символ диез, за которым следует номер выпуска. Вторая строка состоит из звездочек.

Попытка определить формат сообщения, состоящего из нескольких частей, каждая из которых имела собственную кодировку была предпринята в RFC 1154 и RFC 1505. Разбиение тела сообщения на части, для каждой части определяется свой тип кодирования. Размер части задается явным указанием числа строк. Вводит поле Encoding, указывающее для каждой части число строк и тип кодирования (text - простой текст, message - вложенное сообщение, hex - каждый байт представляется двумя шестнадцатеричными цифрами, X.400, uuencode, encrypted, FS - файл, LZJU90 - сжатие и преобразование в текстовый вид, LZW - сжатие в формате compress, PEM - шифрование, PGP - сжатие, шифрование и преобразование в текстовый вид, TAR, PostScript, SHAR, URL). К каждой части последовательно может применяться несколько методов кодирования. Вложенное сообщение может иметь свое поле Encoding. Проверив на массиве из 25000 писем и 20000 статей, нашел один случай использования (uuencode-вложения, сделанные Microsoft Internet E-mail/MAPI), хотя отличительные признаки файлов, встроенных в сообщение, - имя файла и атрибуты в квадратных скобках - ранее встречались довольно часто.

Дальнейшая разработка стандартов тела сообщения пошла в рамках MIME.

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

Перечисление полей заголовка, добавляемых к сообщению шлюзом X.400 -> RFC822 для писем и извещений и представление адресов X.400 вынесено в отдельную статью.

• RFC 822. STD 11. Revised by David H. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 13, 1982. Базовый стандарт на формат сообщения. Отменен RFC 2822.
• RFC 886. M.T. Rose, Proposed standard for message header munging, Dec-15-1983. Предлагается при трансформации сообщения из одного стандарта в другой заносить ошибки в поля Illegal-Field и Illegal-Object.
• RFC 915. M.A. Elvy, R. Nedved, Network mail path service, Dec-01-1984. Сервис uucp-path (117/ucp) и протокол. Позволяет по почтовому неинтернетовскому адресу (UUCP, BITNET и др.) определить его адрес в формате RFC 822 (адрес шлюза и локальную часть адреса, которая позволит шлюзу переслать письмо адресату).
• RFC 934. M.T. Rose and E.A. Stefferud, "Proposed Standard for Message Encapsulation," January 1985.
• RFC 976. Mark. R. Horton, UUCP Mail Interchange Format Standard, February 1986. Адаптация почты UUCP к формату сообщения RFC 822 и доменным адресам RFC 920, определение формата конверта ("From ", ">From ", "From_ "), адресации и маршрутизации почты в смешанном окружении.
• RFC 1049. M. Sirbu, A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES, March 1988. Неприжившийся предшественник MIME. Ввел поле Content-Type.
• RFC 1123. R. Braden, Editor, Requirements for Internet Hosts - Application and Support, October 1989. Содержит уточнения к RFC 822.
• RFC 1137. Kille, S., "Mapping between full RFC 822 and RFC 822 with restricted encoding", October 1989. Преобразование адресов RFC 822 для сетей, не поддерживающих полную кодировку (UUCP). В частности, пробел заменяется на подчеркивание, специальные символы кодируются буквами, обрамленными знаками диез.
• RFC 1153. F.J. Wancho, Digest message format, Apr-01-1990.
• RFC 1154. D. Robinson, R. Ullmann, Encoding header field for internet messages, Apr-01-1990. Отменен RFC 1505.
• RFC 1505. Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header Field for Internet Messages", August 1993. Отменяет RFC 1154.
• RFC 2822. Resnick, P., Editor, "Internet Message Format", April 2001. Базовый стандарт на формат сообщения в Интернет. Отменяет RFC 822.
• Klyne. XML coding of RFC822 messages. 10 September 2001. draft-klyne-message-rfc822-xml-02.txt.
• --------------------------------------------------------
• RFC 2076. Palme, J., "Common Internet Message Headers", February 1997.
• Palme, J., "Common Internet Message Header Fields", Internet draft draft-palme-mailext-headers-06, November 2001.

•         Jukka "Yucca" Korpela: Quick             Non-
          reference to Internet message            standard
          headers,
          http://www.cs.tut.fi/~jkorpela/headers.html
          October 2001.