RFC 5322 | Формат интернет-сообщения (IMF)

Аннотация

Этот документ определяет формат сообщений Интернета (IMF), синтаксис текстовых сообщений, отправляемых между пользователями компьютеров в рамках сообщений «электронная почта». Данная спецификация представляет собой пересмотр Запрос на комментарии (RFC) 2822, который сам по себе заменил Запрос на комментарии (RFC) 822, «Стандарт для формата текстовых сообщений в Интернете ARPA», обновив его, чтобы отразить текущую практику и включив в него дополнительные изменения, которые были указаны в других RFC.

Скачать оригинальный документ на английском языке RFC 5322 PDF

 

Оглавление

1. Введение
1.1. Объем
1.2. Условные обозначения
1.2.1. Обозначение требований
1.2.2. Синтаксическая нотация
1.2.3. Структура этого документа
2. Лексический анализ сообщений
2.1. Общее описание
2.1.1. Пределы длины линии
2.2. Поля заголовка
2.2.1. Неструктурированные заголовки полевых органов
2.2.2. Структурированные заголовки полевых органов
2.2.3. Длинные поля заголовка
2.3. Тело
3. Синтаксис
3.1. Вступление
3.2. Лексические жетоны
3.2.1. Процитированные персонажи
3.2.2. Складной пробел и комментарии
3.2.3. Атом
3.2.4. Строки в кавычках
3.2.5. Разные токены
3.3. Дата и время уточнения
3.4. Спецификация адреса
3.4.1. Спецификация Addr-Spec
3.5. Общий синтаксис сообщения
3.6. Определения полей
3.6.1. Поле даты происхождения
3.6.2. Поля инициатора
3.6.3. Поля адреса назначения
3.6.4. Поля идентификации
3.6.5. Информационные поля
3.6.6. Возмущенные поля
3.6.7. Поля трассировки
3.6.8. Необязательные поля
4. Устаревший синтаксис
4.1. Разное Устаревшие токены
4.2. Устаревший складной белый пробел
4.3. Устаревшие дата и время
4.4. Устаревшая адресация
4.5. Устаревшие поля заголовка
4.5.1. Устаревшее поле даты происхождения
4.5.2. Устаревшие поля оригинатора
4.5.3. Устаревшие поля адреса назначения
4.5.4. Устаревшие поля идентификации
4.5.5. Устаревшие информационные поля
4.5.6. Устаревшие поля
4.5.7. Устаревшие поля трассировки
4.5.8. Устаревшие необязательные поля
5. Вопросы безопасности
6. Соображения IANA
Приложение А. Пример сообщений
Приложение А.1. Примеры адресации
Приложение А.1.1. Сообщение от одного человека другому с простой адресацией
Приложение А.1.2. Различные типы почтовых ящиков
Приложение А.1.3. Групповые адреса
Приложение А.2. Ответные сообщения
Приложение А.3. Повторно отправленные сообщения
Приложение А.4. Сообщения с полями трассировки
Приложение А.5. Пустое пространство, комментарии и другие странности
Приложение А.6. Устаревшие формы
Приложение А.6.1. Устаревшая адресация
Приложение А.6.2. Устаревшие даты
Приложение А.6.3. Устаревшее пустое пространство и комментарии
Приложение B. Отличия от предыдущих спецификаций
Приложение C. Благодарности
7. Ссылки
7.1. Нормативные ссылки
7.2. Информационные ссылки
Адрес автора

 

Статус этой заметки

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

 

1. Введение

1.1. Объем

Этот документ определяет формат сообщений Интернета (IMF), синтаксис текстовых сообщений, отправляемых между пользователями компьютеров в рамках сообщений «электронная почта». Данная спецификация является обновлением к [RFC2822], которое само заменило [RFC0822], обновляя его, чтобы отразить текущую практику и включающее в себя дополнительные изменения, которые были указаны в других RFC, таких как [RFC1123].

Этот документ определяет синтаксис только для текстовых сообщений. В частности, оно не предусматривает передачу изображений, аудио или других видов структурированных данных в сообщениях электронной почты. Опубликовано несколько расширений, таких как серия документов MIME ([RFC2045], [RFC2046], [RFC2049]), которые описывают механизмы передачи таких данных по электронной почте, либо путем расширения синтаксиса, представленного здесь, либо путем структурирования таких сообщения, чтобы соответствовать этому синтаксису. Эти механизмы выходят за рамки данной спецификации.

В контексте электронной почты сообщения рассматриваются как имеющие конверт и содержание. Конверт содержит любую информацию, необходимую для осуществления передачи и доставки. (См. [RFC5321] для обсуждения конверта.) Содержимое содержит объект, который должен быть доставлен получателю. Эта спецификация применяется только к формату и некоторым семантикам содержимого сообщения. Он не содержит спецификации информации в конверте.

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

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

 

1.2. Условные обозначения

1.2.1. Обозначение требований

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119], [RFC8174]

1.2.2. Синтаксическая нотация

В этой спецификации для формальных определений синтаксиса сообщений используется нотация расширенной формы Бэкуса-Наура (ABNF) [RFC5234]. Символы будут указываться либо десятичным значением (например, значением %d65 для прописных букв A и %d97 для строчных букв A), либо нечувствительным к регистру литеральным значением, заключенным в кавычки (например, «A» для прописных или строчных букв A ).

1.2.3. Структура этого документа

Этот документ состоит из нескольких разделов.

Этот раздел, раздел 1, является кратким введением в документ.

Раздел 2 излагает общее описание сообщения и его составных частей. Это обзор, который поможет читателю понять некоторые общие принципы, использованные в последующих частях этого документа. Любые примеры в этом разделе НЕ ДОЛЖНЫ рассматриваться как спецификация формального синтаксиса какой-либо части сообщения.
Раздел 3 определяет формальные правила ABNF для структуры каждой части сообщения (синтаксис) и описывает взаимосвязь между этими частями и их значение в контексте сообщения (семантика). То есть в нем изложены фактические правила для структуры каждой части сообщения (синтаксис), а также описание частей и инструкции по их интерпретации (семантика).

Это включает в себя анализ синтаксиса и семантики частей сообщений, имеющих определенную структуру. Синтаксис, включенный в раздел 3, представляет сообщения, поскольку они ДОЛЖНЫ быть созданы. В разделе 3 также есть примечания, указывающие, следует ли использовать какие-либо параметры, указанные в синтаксисе, над другими.

В обоих разделах 2 и 3 описаны сообщения, которые разрешено генерировать для целей данной спецификации.

Раздел 4 этого документа определяет «устаревший» синтаксис. В разделе 3 есть ссылки на эти устаревшие синтаксические элементы. Правила устаревшего синтаксиса — это элементы, которые появились в более ранних версиях этой спецификации или ранее широко использовались в интернет-сообщениях. Как таковые, эти элементы ДОЛЖНЫ интерпретироваться синтаксическими анализаторами сообщений, чтобы соответствовать этой спецификации. Однако, поскольку элементы в этом синтаксисе были определены как не способные к взаимодействию или создающие существенные проблемы для получателей сообщений, они НЕ ДОЛЖНЫ создаваться создателями соответствующих сообщений.

В разделе 5 подробно рассматриваются вопросы безопасности, которые необходимо учитывать при реализации данной спецификации.

В приложении А приведены примеры сообщений разного рода. Эти примеры не являются исчерпывающими для типов сообщений, которые появляются в Интернете, но дают широкий обзор определенных синтаксических форм.

В Приложении B перечислены различия между этой спецификацией и предыдущими спецификациями для интернет-сообщений.

Приложение C содержит подтверждения.

 

2. Лексический анализ сообщений

2.1. Общее описание

На самом базовом уровне сообщение представляет собой последовательность символов. Сообщение, соответствующее этой спецификации, состоит из символов со значениями в диапазоне от 1 до 127 и интерпретируется как символы US-ASCII [ANSI.X3-4.1986]. Для краткости этот документ иногда называет этот диапазон символов просто «символами US-ASCII».

 

Сообщения делятся на строки символов. Строка — это последовательность символов, разделенная двумя символами возврата каретки и перевода строки; то есть символ возврата каретки (CR) (значение ASCII 13), за которым сразу следует символ перевода строки (LF) (значение ASCII 10). (Пара возврата каретки / перевода строки обычно пишется в этом документе как «CRLF».)

Сообщение состоит из полей заголовка (в совокупности называемых «раздел заголовка сообщения»), за которыми, необязательно, следует тело. Раздел заголовка представляет собой последовательность строк символов со специальным синтаксисом, как определено в этой спецификации. Тело — это просто последовательность символов, которая следует за разделом заголовка и отделена от раздела заголовка пустой строкой (то есть строкой, в которой ничего не предшествует CRLF).

 

2.1.1. Пределы длины линии

В этой спецификации есть два ограничения на количество символов в строке. Каждая строка символов ДОЛЖНА быть не более 998 символов и ДОЛЖНА быть не более 78 символов, исключая CRLF.

Ограничение в 998 символов связано с ограничениями во многих реализациях, которые отправляют, получают или хранят сообщения IMF, которые просто не могут обрабатывать более 998 символов в строке. Для обеспечения надежности было бы целесообразно получать реализации для обработки произвольно большого количества символов в строке. Однако существует так много реализаций, что (в соответствии с транспортными требованиями [RFC5321]) не принимаются сообщения, содержащие более 1000 символов, включая CR и LF на строку, для реализаций важно не создавать такие сообщения.

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

 

2.2. Поля заголовка

Поля заголовка — это строки, начинающиеся с имени поля, за которым следует двоеточие («:»), за которым следует тело поля, и заканчивается CRLF. Имя поля ДОЛЖНО состоять из печатных символов US-ASCII (то есть символов, которые имеют значения между 33 и 126 включительно), за исключением двоеточия. Тело поля может состоять из печатных символов US-ASCII, а также символов пробела (SP, значение ASCII 32) и символов горизонтальной табуляции (HTAB, значение ASCII 9) (вместе известных как символы пробела, WSP). Тело поля НЕ ДОЛЖНО включать CR и LF, за исключением случаев, когда они используются в «сворачивании» и «разворачивании», как описано в разделе 2.2.3. Все полевые тела ДОЛЖНЫ соответствовать синтаксису, описанному в разделах 3 и 4 настоящей спецификации.

 

2.2.1. Неструктурированные заголовки полевых органов

Некоторые тела полей в этой спецификации определяются просто как «неструктурированные» (которые указаны в разделе 3.2.5 как любые печатные символы US-ASCII плюс символы пробелов) без каких-либо дополнительных ограничений. Они называются неструктурированными полевыми органами. Семантически неструктурированные тела полей просто должны рассматриваться как одна строка символов без дальнейшей обработки (за исключением «сворачивания» и «разворачивания», как описано в разделе 2.2.3).

 

2.2.2. Структурированные Заголовки Полевых Органов

Некоторые тела полей в этой спецификации имеют более строгий синтаксис, чем неструктурированные тела полей, описанные выше. Они называются «структурированными» полевыми органами. Структурированные полевые тела — это последовательности конкретных лексических токенов, как описано в разделах 3 и 4 настоящей спецификации. Многие из этих токенов допускаются (в соответствии с их синтаксисом), вводятся или заканчиваются комментариями (как описано в разделе 3.2.2), а также символами пробела, и эти символы пробела подлежат «сворачиванию» и «разворачиванию» «как описано в разделе 2.2.3. Дан семантический анализ структурированных полевых тел наряду с их синтаксисом.

 

2.2.3. Длинные поля заголовка

Каждое поле заголовка логически представляет собой одну строку символов, содержащую имя поля, двоеточие и тело поля. Для удобства, однако, и для того, чтобы справиться с ограничениями в 998/78 символов на строку, часть тела поля поля заголовка может быть разбита на многострочное представление; это называется «складывание». Общее правило заключается в том, что там, где эта спецификация допускает складывание пробелов (а не просто символов WSP), CRLF может быть вставлен перед любым WSP.

Например, поле заголовка:

Тема: это тест

может быть представлен как:

Тема: это
тест

 

Процесс перехода от этого сложенного многострочного представления поля заголовка к его однострочному представлению называется «разворачиванием». Развертывание выполняется простым удалением любого CRLF, за которым сразу следует WSP. Каждое поле заголовка должно обрабатываться в развернутом виде для дальнейшей синтаксической и семантической оценки. Поле заголовка в развернутом виде не имеет ограничения по длине и поэтому может быть неопределенно длинным.

 

2.3. Тело

Тело сообщения — это просто строки символов US-ASCII. Единственными двумя ограничениями на тело являются следующие:

o CR и LF ДОЛЖНЫ появляться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться самостоятельно в теле.

o Строки символов в теле ДОЛЖНЫ быть ограничены 998 символами и ДОЛЖНЫ быть ограничены 78 символами, исключая CRLF.

 

3. Синтаксис

3.1. Вступление

Синтаксис, приведенный в этом разделе, определяет юридический синтаксис интернет-сообщений. Сообщения, которые соответствуют этой спецификации, ДОЛЖНЫ соответствовать синтаксису в этом разделе. Если в этом разделе есть опции, где СЛЕДУЕТ генерировать одну опцию, это указывается либо в прозе, либо в комментарии рядом с синтаксисом.

Для определенных выражений дается краткое описание синтаксиса и использования, затем синтаксис в ABNF и семантический анализ. Следующие примитивные токены, которые используются, но не указаны, взяты из «Основных правил» [RFC5234], Приложение B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA и VCHAR.

В некоторых определениях будут нетерминалы, имена которых начинаются с «obs-». Эти элементы «obs-» относятся к токенам, определенным в устаревшем синтаксисе в разделе 4. Во всех случаях эти произведения должны игнорироваться для целей генерации легальных интернет-сообщений и НЕ ДОЛЖНЫ использоваться как часть такого сообщения. Однако при интерпретации сообщений эти токены ДОЛЖНЫ учитываться как часть легального синтаксиса. В этом смысле раздел 3 определяет грамматику для генерации сообщений с элементами «obs-», которые следует игнорировать, а раздел 4 добавляет грамматику для интерпретации сообщений.

 

3.2. Лексические токены

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

3.2.1. Процитированные символы

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

quoted-pair = («\» (VCHAR / WSP)) / obs-qp

Если появляется любая указанная пара, она должна интерпретироваться как один символ. То есть символ «\», который появляется как часть пары в кавычках, семантически «невидим».

 

3.2.2. Складной пробел и комментарии

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

Строки символов, заключенные в круглые скобки, считаются комментариями, если они не отображаются в «кавычках», как определено в разделе 3.2.4. Комментарии могут быть вложенными.

В этой спецификации есть несколько мест, где комментарии и FWS могут быть свободно вставлены. Чтобы приспособить этот синтаксис, дополнительный токен для «CFWS» определен для мест, где могут появляться комментарии и / или FWS. Однако, если в данной спецификации встречается CFWS, он НЕ ДОЛЖЕН вставляться таким образом, чтобы любая строка поля свернутого заголовка состояла полностью из символов WSP и ничего более.

FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; «(«, «)», or «\»
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = «(» *([FWS] ccontent) [FWS] «)»
CFWS = (1*([FWS] comment) [FWS]) / FWS

В этой спецификации, где появляется FWS (жетон складывания пустого пространства), он указывает место, где может иметь место сворачивание, как описано в разделе 2.2.3. Везде, где свертывание появляется в сообщении (то есть в теле поля заголовка, содержащем CRLF, за которым следует любой WSP), развертывание (удаление CRLF) выполняется до того, как будет выполнен любой дополнительный семантический анализ в этом поле заголовка в соответствии с этой спецификацией. То есть любой CRLF, который появляется в FWS, является семантически «невидимым».

Комментарий обычно используется в теле структурированного поля, чтобы предоставить некоторый читаемый человеком информационный текст. Поскольку комментарий может содержать FWS, в комментарии разрешается сворачивание. Также обратите внимание, что поскольку в комментарии разрешена пара в кавычках, круглые скобки и символы обратной косой черты могут появляться в комментарии, если они отображаются в виде пары в кавычках. Семантически, заключенные в скобки не являются частью комментария; комментарий — это то, что заключено в две скобки. Как указывалось ранее, «\» в любой паре в кавычках и CRLF в любом FWS, который появляется в комментарии, семантически «невидимы» и, следовательно, также не являются частью комментария.

Запуски FWS, комментария или CFWS, возникающие между лексическими токенами в поле структурированного заголовка, семантически интерпретируются как один пробел.

 

3.2.3. Атом

Несколько продукций в телах структурированных заголовков — это просто строки определенных базовых символов. Такие произведения называются атомами.

Некоторые из тел поля структурированного заголовка также допускают символ точки («.», Значение ASCII 46) в пределах прогонов atext. Для этих целей определен дополнительный токен «точка-атом».

 

atext = ALPHA / DIGIT / ; Printable US-ASCII
«!» / «#» / ; characters not including
«$» / «%» / ; specials. Used for atoms.
«&» / «’» /
«*» / «+» /
«-» / «/» /
«=» / «?» /
«^» / «_» /
«‘» / «{» /
«|» / «}» /
«~»
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *(«.» 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = «(» / «)» / ; Special characters that do
«<» / «>» / ; not appear in atext
«[» / «]» /
«:» / «;» /
«@» / «\» /
«,» / «.» /
DQUOTE

И атом, и точка-атом интерпретируются как единое целое, состоящее из строки символов, из которых он состоит. Семантически необязательные комментарии и FWS, окружающие остальные символы, не являются частью атома; атом — это только последовательность символов-атекс в атоме, или атекс и «.» символы в точечном атоме.

 

3.2.4. Строки в кавычках

Строки символов, которые включают символы, отличные от разрешенных в атомах, могут быть представлены в формате строки в кавычках, где символы окружены символами в кавычках (DSCOTE, ASCII value 34).

qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; «\» or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]

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

Семантически ни необязательные CFWS вне символов кавычек, ни сами символы кавычек не являются частью строки в кавычках; строка в кавычках — это то, что содержится между двумя кавычками. Как указывалось ранее, «\» в любой паре в кавычках и CRLF в любом FWS / CFWS, который появляется в строке в кавычках, семантически «невидимы» и, следовательно, также не являются частью строки в кавычках.

 

3.2.5. Разные токены

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

word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct

 

3.3. Дата и время уточнения

Дата и время встречаются в нескольких полях заголовка. В этом разделе указывается синтаксис полной спецификации даты и времени. Хотя в спецификации даты и времени допускается складывание пробелов, РЕКОМЕНДУЕТСЯ использовать один пробел в каждом месте, где появляется FWS (независимо от того, является ли он обязательным или необязательным); некоторые более старые реализации не будут правильно интерпретировать более длинные последовательности складывания пустого пространства.

date-time = [ day-of-week «,» ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = «Mon» / «Tue» / «Wed» / «Thu» / «Fri» / «Sat» / «Sun»
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = «Jan» / «Feb» / «Mar» / «Apr» / «May» / «Jun» / «Jul» / «Aug» / «Sep» / «Oct» / «Nov» / «Dec»
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour «:» minute [ «:» second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( «+» / «-» ) 4DIGIT) / obs-zone

День — это числовой день месяца. Год — любой числовой год 1900 или позже.

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

Дата и время суток ДОЛЖНЫ выражаться по местному времени.

Зона указывает смещение от всемирного координированного времени (UTC, ранее называемое «средним временем по Гринвичу»), которое представляют дата и время суток. «+» Или «-» указывает, является ли время дня впереди (т.е. восточнее) или позади (т.е. западнее) всемирного времени. Первые две цифры обозначают разницу часов по сравнению с универсальным временем, а последние две цифры обозначают количество дополнительных минут по сравнению с универсальным временем. (Следовательно, + hhmm означает + (чч * 60 + мм) минут, а -hhmm означает — (чч * 60 + мм) минут). Форму «+0000» СЛЕДУЕТ использовать для указания часового пояса в универсальном времени. Хотя «-0000» также указывает универсальное время, оно используется для указания того, что время было сгенерировано в системе, которая может находиться в местном часовом поясе, отличном от универсального времени, и что дата-время не содержит информации о местном часовом поясе.

Спецификация даты и времени ДОЛЖНА быть семантически действительной. То есть, день недели (если включен) ДОЛЖЕН быть днем, подразумеваемым датой, числовой день месяца ДОЛЖЕН быть между 1 и числом дней, разрешенных для указанного месяца (в указанном году), время суток ДОЛЖНО быть в диапазоне от 00:00:00 до 23:59:60 (количество секунд с учетом високосной секунды; см. [RFC1305]), а последние две цифры зоны ДОЛЖНЫ быть в пределах диапазон от 00 до 59.

 

3.4. Спецификация адреса

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

address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] «<» addr-spec «>» [CFWS] / obs-angle-addr
group = display-name «:» [group-list] «;» [CFWS]
display-name = phrase
mailbox-list = (mailbox *(«,» mailbox)) / obs-mbox-list
address-list = (address *(«,» address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list

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

Обычно почтовый ящик состоит из двух частей: (1) необязательное отображаемое имя, которое указывает имя получателя (которое может быть человеком или системой), которое может быть отображено пользователю почтового приложения, и (2) адрес addr-spec, заключенный в угловые скобки («<» и «>»). Существует альтернативная простая форма почтового ящика, в которой адрес addr-spec отображается один, без имени получателя или угловых скобок. Интернет-адрес addr-spec описан в разделе 3.4.1.

 

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

 

3.4.1. Спецификация Addr-Spec

Addr-spec — это определенный идентификатор в Интернете, который содержит локально интерпретируемую строку, за которой следует символ знака («@», значение ASCII 64), за которым следует домен Интернета. Локально интерпретируемая строка является либо строкой в кавычках, либо точечным атомом. Если строка может быть представлена как точка-атом (то есть она не содержит никаких символов, кроме символов atext или «.», Окруженных символами atext), тогда следует использовать форму точки-атома, а форму цитированной строки НЕ СЛЕДУЕТ использовать , Комментарии и складывающиеся пробелы НЕ ДОЛЖНЫ использоваться вокруг «@» в addr-spec.

 

addr-spec = local-part «@» domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] «[» *([FWS] dtext) [FWS] «]» [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; «[«, «]», or «\»

Доменная часть идентифицирует точку, в которую доставляется почта. В форме точечного атома это интерпретируется как имя домена Интернета (имя хоста или имя почтового обменника), как описано в [RFC1034], [RFC1035] и [RFC1123]. В доменной форме домен интерпретируется как буквальный Интернет-адрес конкретного хоста. В обоих случаях, как используется адресация и как сообщения передаются на конкретный хост, рассматривается в отдельных документах, таких как [RFC5321]. Эти механизмы выходят за рамки этого документа.

Часть локальной части является зависимой от домена строкой. В адресах это просто интерпретируется на определенном хосте как имя определенного почтового ящика.

 

3.5. Общий синтаксис сообщения

Сообщение состоит из полей заголовка, за которыми может следовать тело сообщения. Строки в сообщении ДОЛЖНЫ быть не более 998 символов, исключая CRLF, но РЕКОМЕНДУЕТСЯ, чтобы строки были ограничены 78 символами, исключая CRLF. (См. Пояснение в разделе 2.1.1.) В теле сообщения МОГУТ использоваться все символы, перечисленные в текстовом правиле, использование управляющих символов US-ASCII (значения от 1 до 8, 11, 12 и от 14 до 14). 31) не рекомендуется, поскольку их интерпретация приемниками для отображения не гарантируется.

message = (fields / obs-fields) [CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127

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

 

3.6. Определения полей

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

 

Важно отметить, что поля заголовка не обязательно должны быть в определенном порядке. Они могут появляться в любом порядке, и известно, что они иногда переупорядочиваются при передаче через Интернет. Однако для целей данной спецификации поля заголовка НЕ ​​ДОЛЖНЫ быть переупорядочены при транспортировке или преобразовании сообщения. Что еще более важно, поля заголовка трассировки и повторно отправленные поля заголовка НЕ ​​ДОЛЖНЫ быть переупорядочены и ДОЛЖНЫ храниться в блоках, предшествующих сообщению. См. Разделы 3.6.6 и 3.6.7 для получения дополнительной информации.

Единственными обязательными полями заголовка являются поле даты отправления и поля адреса отправителя. Все остальные поля заголовка синтаксически необязательны. Более подробная информация содержится в таблице после этого определения.

fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)

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

 

3.6.1. Поле даты происхождения

Поле даты происхождения состоит из имени поля «Дата», за которым следует указание даты и времени.

orig-date = «Date:» date-time CRLF

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

 

3.6.2. Поля инициатора

Поля отправителя сообщения состоят из поля «от», поля «отправитель» (если применимо) и, при необходимости, поля «ответ». Поле from состоит из имени поля «From» и разделенного запятыми списка одной или нескольких спецификаций почтовых ящиков. Если поле from содержит более одной спецификации почтового ящика в списке почтовых ящиков, то в сообщении ДОЛЖНО появиться поле отправителя, содержащее имя поля «Отправитель» и спецификацию одного почтового ящика. В любом случае также может быть включено необязательное поле для ответа, которое содержит имя поля «Reply-To» и разделенный запятыми список из одного или нескольких адресов.

from = «From:» mailbox-list CRLF
sender = «Sender:» mailbox CRLF
reply-to = «Reply-To:» address-list CRLF

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

 

Поля отправителя также предоставляют информацию, необходимую при ответе на сообщение. Когда присутствует поле «Reply-To:», оно указывает адрес (а), на который автор сообщения предлагает отправлять ответы. При отсутствии поля «Reply-To:» ответы ДОЛЖНЫ по умолчанию отправляться на почтовые ящики, указанные в поле «From:», если автором ответа не указано иное.

Во всех случаях поле «От:» НЕ ДОЛЖНО содержать почтовый ящик, который не принадлежит автору (ям) сообщения. См. Также раздел 3.6.3 для получения дополнительной информации о формировании адресов назначения для ответа.

 

3.6.3. Поля адреса назначения

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

to = «To:» address-list CRLF
cc = «Cc:» address-list CRLF
bcc = «Bcc:» [address-list / CFWS] CRLF

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

Поле «Кому:» содержит адрес (а) основного получателя (ей) сообщения.

Поле «Cc:» (где «Cc» означает «Копия» в смысле создания копии на пишущей машинке с использованием копировальной бумаги) содержит адреса других лиц, которые должны получить сообщение, хотя содержание сообщения может не быть направленным на них.

Поле «Bcc:» (где «Bcc» означает «Слепая копия») содержит адреса получателей сообщения, адреса которых не должны раскрываться другим получателям сообщения. Существует три способа использования поля «Bcc:». В первом случае, когда сообщение, содержащее поле «Bcc:» готово к отправке, строка «Bcc:» удаляется, даже если все получатели (включая тех, которые указаны в поле «Bcc:») отправлены копия сообщения. Во втором случае получателям, указанным в строках «To:» и «Cc:» каждая, отправляется копия сообщения со строкой «Bcc:», удаленной, как указано выше, но получатели в строке «Bcc:» получают отдельная копия сообщения, содержащего строку «Bcc:». (Когда в поле «Bcc:» имеется несколько адресов получателей, некоторые реализации фактически отправляют каждому получателю отдельную копию сообщения с «Bcc:», содержащим только адрес этого конкретного получателя.) Наконец, после «Bcc» : «поле может не содержать адресов, поле« СК: »может быть отправлено без каких-либо адресов, указывающих получателям, что слепые копии были отправлены кому-либо. Какой метод использовать с полями «СК:» зависит от реализации, но для обсуждения каждого из них обратитесь к разделу «Вопросы безопасности» этого документа.

Когда сообщение является ответом на другое сообщение, почтовые ящики авторов исходного сообщения (почтовые ящики в поле «От:») или почтовые ящики, указанные в поле «Ответить:» (если оно существует), МОГУТ появляться в поле «Кому:» ответа, поскольку обычно они являются основными получателями ответа. Если ответ отправляется на сообщение с полями назначения, часто желательно отправить копию ответа всем получателям сообщения, в дополнение к автору. Когда такой ответ формируется, адреса в полях «To:» и «Cc:» исходного сообщения МОГУТ появляться в поле «Cc:» ответа, поскольку обычно они являются вторичными получателями ответа. Если в исходном сообщении присутствует поле «Bcc:», адреса в этом поле МОГУТ появляться в поле «Bcc:» ответа, но они НЕ ДОЛЖНЫ появляться в полях «To:» или «Cc:».

 

3.6.4. Поля идентификации

Хотя это указано как необязательное в таблице в разделе 3.6, каждое сообщение ДОЛЖНО иметь поле «Message-ID:». Кроме того, ответные сообщения ДОЛЖНЫ иметь поля «In-Reply-To:» и «References:» в зависимости от ситуации и как описано ниже.

Поле «Message-ID:» содержит один уникальный идентификатор сообщения. Поля «References:» и «In-Reply-To:» содержат по одному или нескольким уникальным идентификаторам сообщений, которые могут быть разделены CFWS.

Синтаксис идентификатора сообщения (msg-id) является ограниченной версией конструкции addr-spec, заключенной в символы угловой скобки, «<» и «>». В отличие от addr-spec, этот синтаксис разрешает только точечный атом-текст в левой части символа «@» и не имеет внутреннего CFWS где-либо в идентификаторе сообщения.

 

message-id = «Message-ID:» msg-id CRLF
in-reply-to = «In-Reply-To:» 1*msg-id CRLF
references = «References:» 1*msg-id CRLF
msg-id = [CFWS] «<» id-left «@» id-right «>» [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal = «[» *dtext «]»

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

 

Поля «In-Reply-To:» и «References:» используются при создании ответа на сообщение. Они содержат идентификатор сообщения исходного сообщения и идентификаторы сообщения других сообщений (например, в случае ответа на сообщение, которое само было ответом). Поле «In-Reply-To:» может использоваться для идентификации сообщения (или сообщений), на которое новое сообщение является ответом, а поле «References:» может использоваться для идентификации «цепочки» разговора.

При создании ответа на сообщение поля «In-Reply-To:» и «References:» полученного сообщения составляются следующим образом:

Поле «In-Reply-To:» будет содержать содержимое поля «Message-ID:» того сообщения, на которое оно является ответом («родительское сообщение»). Если имеется более одного родительского сообщения, то поле «In-Reply-To:» будет содержать содержимое всех полей «Message-ID:» родителей. Если в каком-либо из родительских сообщений нет поля «Message-ID:», то в новом сообщении не будет поля «In-Reply-To:».

Поле «References:» будет содержать содержимое родительского поля «References:» (если есть), за которым следует содержимое родительского поля «Message-ID:» (если есть). Если родительское сообщение не содержит поля «References:», но имеет поле «In-Reply-To:», содержащее один идентификатор сообщения, то поле «References:» будет содержать содержимое «In-Reply» родителя. -To: «поле, за которым следует содержимое родительского поля« Message-ID: »(если есть). Если родитель не имеет ни одного из полей «References:», «In-Reply-To:» или «Message-ID:», то в новом сообщении не будет поля «References:».

 

Сам идентификатор сообщения (msg-id) ДОЛЖЕН быть глобально уникальным идентификатором сообщения. Генератор идентификатора сообщения ДОЛЖЕН гарантировать, что msg-id является уникальным. Есть несколько алгоритмов, которые могут быть использованы для достижения этой цели. Поскольку msg-id имеет синтаксис, аналогичный addr-spec (идентичен, за исключением того, что строки в кавычках, комментарии и складывающиеся пробелы не допускаются), хорошим способом является помещение имени домена (или буквенного IP-адреса домена) из узел, на котором идентификатор сообщения был создан справа от «@» (поскольку доменные имена и IP-адреса обычно уникальны), и помещает комбинацию текущей абсолютной даты и времени вместе с некоторыми другими в настоящее время уникальными (возможно, последовательный) идентификатор, доступный в системе (например, номер идентификатора процесса) с левой стороны. Хотя другие алгоритмы будут работать, РЕКОМЕНДУЕТСЯ, чтобы правая часть содержала некоторый идентификатор домена (либо самого хоста, либо иным образом), чтобы генератор идентификатора сообщения мог гарантировать уникальность левой части в пределах области действия. этот домен.

Семантически символы угловых скобок не являются частью msg-id; msg-id — это то, что содержится между двумя символами угловой скобки.

 

3.6.5. Информационные поля

Информационные поля являются необязательными. Поля «Subject:» и «Comments:» являются неструктурированными полями, как определено в разделе 2.2.1, и, следовательно, могут содержать текст или пробел. Поле «Keywords:» содержит разделенный запятыми список из одного или нескольких слов или строк в кавычках.

subject = «Subject:» unstructured CRLF
comments = «Comments:» unstructured CRLF
keywords = «Keywords:» phrase *(«,» phrase) CRLF

Эти три поля предназначены для того, чтобы иметь только удобочитаемый контент с информацией о сообщении. Поле «Subject:» является наиболее распространенным и содержит короткую строку, идентифицирующую тему сообщения. При использовании в ответе тело поля МОЖЕТ начинаться со строки «Re:» (сокращение от латинского «in re», означающего «в вопросе»), за которым следует содержимое поля «Subject:» поля оригинальное сообщение. Если это сделано, следует использовать только один экземпляр буквенной строки «Re:», поскольку использование других строк или нескольких экземпляров может привести к нежелательным последствиям. Поле «Комментарии:» содержит любые дополнительные комментарии к тексту тела сообщения. Поле «Ключевые слова:» содержит разделенный запятыми список важных слов и фраз, которые могут быть полезны для получателя.

 

3.6.6. Возмущенные поля

Повторно отправленные поля ДОЛЖНЫ быть добавлены к любому сообщению, которое повторно вводится пользователем в транспортную систему. Отдельный набор повторно отправленных полей ДОЛЖЕН быть добавлен каждый раз, когда это делается. Все повторно отправленные поля, соответствующие конкретной повторной отправке сообщения, ДОЛЖНЫ быть сгруппированы вместе. Каждый новый набор повторно отправленных полей добавляется к сообщению; то есть самый последний набор повторно отправленных полей появляется ранее в сообщении. Другие поля в сообщении не изменяются при добавлении повторно отправленных полей.

Каждое из повторно отправленных полей соответствует определенному полю в другом месте в синтаксисе. Например, поле «Resent-Date:» соответствует полю «Date:», а поле «Resent-To:» соответствует полю «To:». В каждом случае синтаксис для тела поля идентичен синтаксису, приведенному ранее для соответствующего поля.

Когда используются повторно отправленные поля, поля «Resent-From:» и «Resent-Date:» ДОЛЖНЫ быть отправлены. Поле «Resent-Message-ID:» ДОЛЖНО быть отправлено. «Resent-Sender:» НЕ ДОЛЖЕН использоваться, если «Resent-Sender:» будет идентичным «Resent-From:».

resent-date = «Resent-Date:» date-time CRLF
resent-from = «Resent-From:» mailbox-list CRLF
resent-sender = «Resent-Sender:» mailbox CRLF
resent-to = «Resent-To:» address-list CRLF
resent-cc = «Resent-Cc:» address-list CRLF
resent-bcc = «Resent-Bcc:» [address-list / CFWS] CRLF
resent-msg-id = «Resent-Message-ID:» msg-id CRLF

Повторно отправленные поля используются для идентификации сообщения как вновь введенного пользователем в транспортную систему. Цель использования повторно отправленных полей состоит в том, чтобы сообщение появилось у конечного получателя, как если бы оно было отправлено непосредственно исходным отправителем, при этом все исходные поля остались прежними. Каждый набор повторно отправленных полей соответствует определенному событию повторной отправки. То есть, если сообщение повторно отправляется несколько раз, каждый набор повторно отправленных полей дает идентификационную информацию для каждого отдельного времени. Последние поля являются строго информационными. Они НЕ ДОЛЖНЫ использоваться при обычной обработке ответов или других подобных автоматических действиях с сообщениями.

 

В полях повторно отправленного отправителя указывается почтовый ящик лица или систем, которые повторно отправляют сообщение. Как и в случае с обычными полями отправителя, существует две формы: простая форма «Resent-From:», которая содержит почтовый ящик лица, выполняющего повторную отправку, и более сложная форма, когда одно лицо (определено в «Resent-Sender» : «field) повторно отправляет сообщение от имени одного или нескольких других (указанных в поле» Resent-From: «).

 

«Resent-Date:» указывает дату и время, когда повторно отправленное сообщение отправляется отправителем сообщения. Как и в поле «Дата:», это не дата и время, когда сообщение было фактически передано.

Поля «Resent-To:», «Resent-Cc:» и «Resent-Bcc:» функционируют идентично полям «To:», «Cc:» и «Bcc:» соответственно, за исключением того, что они указывают получатели повторно отправленного сообщения, а не получатели исходного сообщения.

Поле «Resent-Message-ID:» предоставляет уникальный идентификатор для повторно отправленного сообщения.

 

3.6.7. Поля трассировки

Поля трассировки — это группа полей заголовка, состоящая из необязательного поля «Return-Path:» и одного или нескольких полей «Received:». Поле заголовка «Return-Path:» содержит пару угловых скобок, которые заключают в себе необязательную спецификацию addr. Поле «Received:» содержит (возможно, пустой) список токенов, за которыми следует точка с запятой и спецификация datetime. Каждый токен должен быть словом, angle-addr, addrspec или доменом. Дополнительные ограничения применяются к синтаксису полей трассировки спецификациями, которые предусматривают их использование, такими как [RFC5321].

trace = [return]
1*received
return = «Return-Path:» path CRLF
path = angle-addr / ([CFWS] «<» [CFWS] «>» [CFWS])
received = «Received:» *received-token «;» date-time CRLF
received-token = word / angle-addr / addr-spec / domain

Полное обсуждение использования полей трассировки электронной почтой содержится в [RFC5321]. Для целей данной спецификации поля трассировки являются строго информационными, и любая их формальная интерпретация выходит за рамки этого документа.

 

3.6.8. Необязательные поля

Поля могут появляться в сообщениях, которые не указаны в этом документе. Они ДОЛЖНЫ соответствовать синтаксису необязательного поля. Это имя поля, состоящее из печатных символов US-ASCII, за исключением SP и двоеточия, за которым следует двоеточие, за которым следует любой текст, соответствующий неструктурированному синтаксису.

Имена полей любого необязательного поля НЕ ДОЛЖНЫ совпадать с именами полей, указанных в других местах этого документа.

optional-field = field-name «:» unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; «:».

Для целей данной спецификации любое необязательное поле не интерпретируется.

 

4. Устаревший синтаксис

Более ранние версии этой спецификации допускали другой (обычно более либеральный) синтаксис, чем разрешено в этой версии. Кроме того, в сообщениях в Интернете использовались синтаксические элементы, интерпретации которых никогда не документировались. Хотя эти синтаксические формы НЕ ДОЛЖНЫ генерироваться в соответствии с грамматикой в ​​разделе 3, они ДОЛЖНЫ быть приняты и проанализированы соответствующим получателем. В этом разделе описаны многие из этих синтаксических элементов. Принятие грамматики в разделе 3 и добавление определений, представленных в этом разделе, приведет к грамматике, используемой для интерпретации сообщений.

 

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

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

Наконец, некоторые символы, которые ранее были разрешены в сообщениях, появляются в этом разделе. Символ NUL (значение ASCII 0) был когда-то разрешен, но больше не по соображениям совместимости. Точно так же управляющие символы USASCII, отличные от CR, LF, SP и HTAB (значения ASCII от 1 до 8, 11, 12, 14–31 и 127), допускались в теле полей заголовка. CR и LF разрешалось появляться в сообщениях, отличных от CRLF; это использование также показано здесь.

Другие различия в синтаксисе и семантике отмечены в следующих разделах.

 

4.1. Разное Устаревшие токены

Эти синтаксические элементы используются в другом месте в устаревшем синтаксисе или в основном синтаксисе. Голый CR, голый LF и NUL добавляются в obs-qp, obs-body и obs-unstruct. Управляющие символы US-ASCII добавляются в obs-qp, obs-unstruct, obs-ctext и obs-qtext. Символ точки добавляется в obs-фразу. Список obs-фраза-списка предоставляет (потенциально пустой) список фраз, разделенных запятыми, которые могут содержать «нулевые» элементы. То есть в таком списке может быть две или более запятых, между которыми ничего нет, или запятые в начале или конце списка.

 

obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = «\» (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / «.» / CFWS)
obs-phrase-list = [phrase / CFWS] *(«,» [phrase / CFWS])

Bare CR и голый LF появляются в сообщениях с двумя различными значениями. Во многих случаях голые CR или голые LF используются неправильно вместо CRLF для обозначения разделителей строк. В других случаях голые CR и голые LF используются просто как управляющие символы US-ASCII с их традиционными значениями ASCII.

 

4.2. Устаревший складной пробел

В устаревшем синтаксисе МОЖЕТ быть вставлено любое количество складывающихся пробелов, если разрешено правило obs-FWS. Это создает возможность наличия двух последовательных «сгибов» в строке и, следовательно, возможность того, что строка, которая составляет сложенное поле заголовка, может состоять полностью из пустого пространства.

obs-FWS = 1*WSP *(CRLF 1*WSP)

 

4.3. Устаревшие дата и время

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

obs-day-of-week = [CFWS] day-name [CFWS]
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = «UT» / «GMT» / ; Universal Time
; North American UT
; offsets
«EST» / «EDT» / ; Eastern: — 5/ — 4
«CST» / «CDT» / ; Central: — 6/ — 5
«MST» / «MDT» / ; Mountain: — 7/ — 6
«PST» / «PDT» / ; Pacific: — 8/ — 7
;

%d65-73 / ; Military zones — «A»
%d75-90 / ; through «I» and «K»
%d97-105 / ; through «Z», both
%d107-122 ; upper and lower case

Если в дате встречается год из двух или трех цифр, год следует интерпретировать следующим образом: Если встречается год из двух цифр, значение которого находится между 00 и 49, год интерпретируется путем добавления 2000, заканчивающегося значением между 2000 и 2049. Если встречается год с двумя цифрами со значением от 50 до 99 или встречается любой год с тремя цифрами, этот год интерпретируется путем добавления 1900.

В устаревшем часовом поясе «UT» и «GMT» обозначают «универсальное время» и «среднее время по Гринвичу», соответственно, и оба семантически идентичны «+0000».

Оставшиеся три символьных пояса являются часовыми поясами США. Первая буква «E», «C», «M» или «P» означает «восточная», «центральная», «горная» и «тихоокеанская». Вторая буква — это либо «S» для «стандартного» времени, либо «D» для «летнего» (или летнего) времени. Их интерпретации следующие:

EDT is semantically equivalent to -0400
EST is semantically equivalent to -0500
CDT is semantically equivalent to -0500
CST is semantically equivalent to -0600
MDT is semantically equivalent to -0600
MST is semantically equivalent to -0700
PDT is semantically equivalent to -0700
PST is semantically equivalent to -0800

Военные часовые пояса, состоящие из 1 символа, были определены нестандартным способом в [RFC0822] и поэтому непредсказуемы по своему значению. Первоначальные определения военных зон от «A» до «I» эквивалентны «+0100» — «+0900» соответственно; «K», «L» и «M» эквивалентны «+1000», «+1100» и «+1200» соответственно; «N» — «Y» эквивалентны «-0100» — «-1200». соответственно; и «Z» эквивалентно «+0000». Однако из-за ошибки в [RFC0822] все они ДОЛЖНЫ считаться эквивалентными «-0000», если только нет внеполосной информации, подтверждающей их значение.

Другие многосимвольные (обычно от 3 до 5) буквенные часовые пояса использовались в интернет-сообщениях. Любой такой часовой пояс, значение которого неизвестно, ДОЛЖЕН считаться эквивалентным «-0000», если только нет внеполосной информации, подтверждающей их значение.

 

4.4. Устаревшая адресация

Есть четыре основных различия в адресации. Во-первых, адресам почтовых ящиков разрешалось иметь часть маршрута перед спецификацией addr, если они заключены в «<» и «>». Маршрут представляет собой просто список доменных имен, разделенных запятыми, каждому из которых предшествует «@», а список заканчивается двоеточием. Во-вторых, CFWS были разрешены между разделенными периодом элементами локальной части и области (то есть точка-атом не использовалась). Кроме того, локальная часть может содержать строку в кавычках в дополнение к просто атому. В-третьих, список почтовых ящиков и список адресов могли иметь «нулевые» члены. То есть в таком списке может быть две или более запятых, между которыми ничего нет, или запятые в начале или конце списка. Наконец, управляющие символы US-ASCII и пары в кавычках были разрешены в литералах домена и добавлены здесь.

obs-angle-addr = [CFWS] «<» obs-route addr-spec «>» [CFWS]
obs-route = obs-domain-list «:»
obs-domain-list = *(CFWS / «,») «@» domain
*(«,» [CFWS] [«@» domain])
obs-mbox-list = *([CFWS] «,») mailbox *(«,» [mailbox / CFWS])
obs-addr-list = *([CFWS] «,») address *(«,» [address / CFWS])
obs-group-list = 1*([CFWS] «,») [CFWS]
obs-local-part = word *(«.» word)
obs-domain = atom *(«.» atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair

При интерпретации адресов часть маршрута ДОЛЖНА игнорироваться.

 

4.5. Устаревшие поля заголовка

Синтаксически, основное различие в устаревшем синтаксисе поля состоит в том, что оно допускает множественные вхождения любого из полей, и они могут встречаться в любом порядке. Кроме того, любое количество пробелов допускается до «:» в конце имени поля.

obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)

За исключением полей адреса назначения (описанных в разделе 4.5.3), интерпретация множественных вхождений полей не определена. Кроме того, интерпретация полей трассировки и повторно отправленных полей, которые не встречаются в блоках, добавленных к сообщению, также не определена. Если в следующих разделах не указано иное, интерпретация других полей идентична интерпретации их устаревших аналогов в разделе 3.

 

4.5.1. Устаревшее поле даты происхождения

obs-orig-date = «Date» *WSP «:» date-time CRLF

 

4.5.2. Устаревшие поля оригинатора

obs-from = «From» *WSP «:» mailbox-list CRLF
obs-sender = «Sender» *WSP «:» mailbox CRLF
obs-reply-to = «Reply-To» *WSP «:» address-list CRLF

 

4.5.3. Устаревшие поля адреса назначения

obs-to = «To» *WSP «:» address-list CRLF
obs-cc = «Cc» *WSP «:» address-list CRLF
obs-bcc = «Bcc» *WSP «:»
(address-list / (*([CFWS] «,») [CFWS])) CRLF

Когда в сообщении встречаются несколько вхождений полей адресов назначения, они ДОЛЖНЫ обрабатываться так, как если бы список адресов в первом вхождении поля комбинировался со списками адресов последующих вхождений путем добавления запятой и объединения.

 

4.5.4. Устаревшие поля идентификации

Устаревшие поля «In-Reply-To:» и «References:» отличаются от текущего синтаксиса тем, что допускают появление фразы (слова или строки в кавычках). Устаревшие формы левой и правой сторон msg-id допускают вкрапления CFWS, делая их синтаксически идентичными local-part и domain соответственно.

obs-message-id = «Message-ID» *WSP «:» msg-id CRLF
obs-in-reply-to = «In-Reply-To» *WSP «:» *(phrase / msg-id) CRLF
obs-references = «References» *WSP «:» *(phrase / msg-id) CRLF
obs-id-left = local-part
obs-id-right = domain

В целях интерпретации фразы в полях «In-Reply-To:» и «References:» игнорируются.

Семантически, ни один из необязательных CFWS в локальной части и домене не является частью obs-id-left и obs-id-right, соответственно.

 

4.5.5. Устаревшие информационные поля

obs-subject = «Subject» *WSP «:» unstructured CRLF
obs-comments = «Comments» *WSP «:» unstructured CRLF
obs-keywords = «Keywords» *WSP «:» obs-phrase-list CRLF

 

4.5.6. Устаревшие поля

Устаревший синтаксис добавляет поле «Resent-Reply-To:», которое состоит из имени поля, необязательных комментариев и складывающихся пробелов, двоеточия и списка адресов, разделенных запятыми.

obs-resent-from = «Resent-From» *WSP «:» mailbox-list CRLF
obs-resent-send = «Resent-Sender» *WSP «:» mailbox CRLF
obs-resent-date = «Resent-Date» *WSP «:» date-time CRLF
obs-resent-to = «Resent-To» *WSP «:» address-list CRLF
obs-resent-cc = «Resent-Cc» *WSP «:» address-list CRLF
obs-resent-bcc = «Resent-Bcc» *WSP «:»
(address-list / (*([CFWS] «,») [CFWS])) CRLF
obs-resent-mid = «Resent-Message-ID» *WSP «:» msg-id CRLF
obs-resent-rply = «Resent-Reply-To» *WSP «:» address-list CRLF

Как и в случае других повторно отправленных полей, поле «Resent-Reply-To:» следует рассматривать только как информацию трассировки.

 

4.5.7. Устаревшие поля трассировки

Obs-return и obs-receive снова приведены здесь в качестве определений шаблонов, точно так же, как возврат и получение приведены в разделе 3. Их полный синтаксис приведен в [RFC5321].

obs-return = «Return-Path» *WSP «:» path CRLF
obs-received = «Received» *WSP «:» *received-token CRLF

 

4.5.8. Устаревшие необязательные поля

obs-optional = field-name *WSP «:» unstructured CRLF

 

5. Вопросы безопасности

Необходимо соблюдать осторожность при отображении сообщений на терминале или эмуляторе терминала. Мощные терминалы могут воздействовать на escape-последовательности и другие комбинации управляющих символов US-ASCII с различными последствиями. Они могут переназначить клавиатуру или разрешить другие модификации терминала, которые могут привести к отказу в обслуживании или даже повреждению данных. Они могут вызывать (иногда программируемые) ответные сообщения, которые могут позволить сообщению вызывать команды от имени получателя. Они также могут влиять на работу подключенных к терминалу устройств, таких как принтеры. Для просмотра сообщений может потребоваться удалить потенциально опасные управляющие последовательности терминала из сообщения перед его отображением. Тем не менее, другие escape-последовательности появляются в сообщениях для полезных целей (см. [ISO.2022.1994], [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) и поэтому не должны быть удалены без разбора.

Передача нетекстовых объектов в сообщениях поднимает дополнительные проблемы безопасности. Эти вопросы обсуждаются в [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288] и [RFC4289].

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

Из-за этого один из слепых адресатов потенциально может отправить ответ всем показанным получателям и случайно обнаружить, что сообщение отправлено слепому получателю. При использовании второго метода из раздела 3.6.3 адрес слепого получателя появляется в поле «Bcc:» отдельной копии сообщения. Если отправленное поле «Bcc:» содержит всех скрытых адресатов, все получатели «Bcc:» будут видеть каждый получатель «Bcc:». Даже если каждому получателю «Bcc:» отправляется отдельное сообщение только с адресом индивидуума, реализации все же должны быть осторожны при обработке ответов на сообщение согласно разделу 3.6.3, чтобы случайно не открыть слепого получателя другим получателям.

 

6. Соображения IANA

Этот документ обновляет регистрации, появившиеся в [RFC4021], которые ссылались на определения в [RFC2822]. IANA обновила репозиторий полей заголовка постоянного сообщения следующими полями заголовка в соответствии с процедурами, изложенными в [RFC3864].

Header field name: Date
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.1)

Header field name: From
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.2)

Header field name: Sender
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.2)

Header field name: Reply-To
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.2)

Header field name: To
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.3)

Header field name: Cc
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.3)

Header field name: Bcc
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.3)

Header field name: Message-ID
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.4)

Header field name: In-Reply-To
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.4)

Header field name: References
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.4)

Header field name: Subject
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.5)

Header field name: Comments
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.5)

Header field name: Keywords
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.5)

Header field name: Resent-Date
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-From
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-Sender
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-To
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-Cc
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-Bcc
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Resent-Reply-To
Applicable protocol: Mail
Status: obsolete
Author/Change controller: IETF
Specification document(s): This document (section 4.5.6)

Header field name: Resent-Message-ID
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.6)

Header field name: Return-Path
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.7)

Header field name: Received
Applicable protocol: Mail
Status: standard
Author/Change controller: IETF
Specification document(s): This document (section 3.6.7)
Related information: [RFC5321]

 

Приложение А. Пример сообщений

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

В текстовой версии этого документа сообщения в этом разделе разделяются между строками «—-». Строки «—-» не являются частью самого сообщения.

 

Приложение А.1. Примеры адресации

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

 

Приложение А.1.1. Сообщение от одного человека другому с простой адресацией

Это можно назвать каноническим сообщением. У него есть один автор, Джон Доу, один получатель, Мэри Смит, тема, дата, идентификатор сообщения и текстовое сообщение в теле.

From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

Если секретарь Джона Майкл действительно отправил сообщение, хотя Джон был автором и ответы на это сообщение должны были вернуться к нему, поле отправителя будет использовано:

From: John Doe <jdoe@machine.example>
Sender: Michael Jones <mjones@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

 

Приложение А.1.2. Различные типы почтовых ящиков

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

From: «Joe Q. Public» <john.q.public@example.com>
To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
Cc: <boss@nil.test>, «Giant; \»Big\» Box» <sysservices@example.net>
Date: Tue, 1 Jul 2003 10:52:37 +0200
Message-ID: <5678.21-Nov-1997@example.com>
Hi everyone.

Обратите внимание, что отображаемые имена для Joe Q. Public и Giant; «Большое» поле необходимо заключить в двойные кавычки, поскольку первое содержит точку, а второе — как точки с запятой, так и символы двойных кавычек (символы двойных кавычек, представленные в виде конструкций с кавычками). И наоборот, отображаемое имя для кого? может появиться без них, потому что вопросительный знак является законным в атоме. Также обратите внимание, что jdoe@example.org и boss@nil.test не имеют отображаемых имен, связанных с ними вообще, а jdoe@example.org использует более простую форму адреса без угловых скобок.

 

Приложение А.1.3. Групповые адреса

From: Pete <pete@silly.example>
To: A Group:Ed Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
Cc: Undisclosed recipients:;
Date: Thu, 13 Feb 1969 23:32:54 -0330
Message-ID: <testabcd.1234@silly.example>
Testing.

В этом сообщении поле «Кому:» содержит одного получателя группы с именем «Группа», который содержит 3 адреса, и поле «Копия:» с пустым получателем группы с именем «нераскрытые» получатели.

 

Приложение А.2. Ответные сообщения

Ниже приводится серия из трех сообщений, составляющих цепочку разговоров между Джоном и Мэри. Джон сначала отправляет сообщение Мэри, затем Мэри отвечает на сообщение Джона, а затем Джон отвечает на ответное сообщение Мэри.

Обратите особое внимание на поля «Message-ID:», «References:» и «In-Reply-To:» в каждом сообщении.

From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

При отправке ответов поле «Тема» часто сохраняется, хотя с добавлением «Re:», как описано в разделе 3.6.5.

From: Mary Smith <mary@example.net>
To: John Doe <jdoe@machine.example>
Reply-To: «Mary Smith: Personal Account» <smith@home.example>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID: <3456@example.net>
In-Reply-To: <1234@local.machine.example>
References: <1234@local.machine.example>
This is a reply to your hello.

Обратите внимание на поле «Ответить» в вышеприведенном сообщении. Когда Джон отвечает на сообщение Мэри выше, ответ должен идти по адресу в поле «Reply-To:» вместо адреса в поле «From:».

To: «Mary Smith: Personal Account» <smith@home.example>
From: John Doe <jdoe@machine.example>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 11:00:00 -0600
Message-ID: <abcd.1234@local.machine.test>
In-Reply-To: <3456@example.net>
References: <1234@local.machine.example> <3456@example.net>
This is a reply to your reply.

 

Приложение А.3. Повторно отправленные сообщения

Начните с сообщения, которое использовалось в качестве примера несколько раз:

From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

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

Resent-From: Mary Smith <mary@example.net>
Resent-To: Jane Brown <j-brown@other.example>
Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
Resent-Message-ID: <78910@example.net>
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

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

 

Приложение А.4. Сообщения с полями трассировки

Поскольку сообщения отправляются через транспортную систему, как описано в [RFC5321], к сообщению добавляются поля трассировки. Ниже приведен пример того, как могут выглядеть эти поля трассировки. Обратите внимание, что в первом есть несколько складывающихся пробелов, так как эти строки могут быть длинными.

Received: from x.y.test
by example.net
via TCP
with ESMTP
id ABC12345
for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
From: John Doe <jdoe@node.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.node.example>
This is a message just to say hello.
So, «Hello».

 

Приложение А.5. Пустое пространство, комментарии и другие странности

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

From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
To:A Group(Some people)
:Chris Jones <c@(Chris’s host.)public.example>,
joe@example.org,
John <jdoe@one.test> (my dear friend); (the end of the group)
Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ;
Date: Thu,
13
Feb
1969
23:32
-0330 (Newfoundland Time)
Message-ID: <testabcd.1234@silly.test>
Testing.

Приведенный выше пример эстетически неприятен, но совершенно законен. Обратите особое внимание на (1) комментарии в поле «От:» (включая комментарий с символом «), появляющийся как часть пары в кавычках); (2) пробел отсутствует после «:» в поле «Кому», а также комментарий и сворачивание пробела после имени группы, специальный символ («.») В комментарии в адресе Криса Джонса и складывающиеся пробелы до и после «joe@example.org»; (3) множественные и вложенные комментарии в поле «Cc:», а также комментарий, следующий сразу за «:» после «Cc»; (4) складывающиеся пробелы (но без комментариев, кроме в конце) и недостающие секунды во времени поля даты; и (5) пробел перед (но не внутри) идентификатором в поле «Message-ID:».

 

Приложение А.6. Устаревшие формы

Ниже приведены примеры устаревших (то есть «НЕ ДОЛЖНЫ генерировать») синтаксических элементов, описанных в разделе 4 этого документа.

 

Приложение А.6.1. Устаревшая адресация

Обратите внимание на приведенный ниже пример отсутствия кавычек вокруг Joe Q. Public, маршрута, который появляется в адресе для Мэри Смит, двух запятых, которые появляются в поле «To:», и пробелов, которые появляются вокруг «.» в адресе jdoe.

From: Joe Q. Public <john.q.public@example.com>
To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example
Date: Tue, 1 Jul 2003 10:52:37 +0200
Message-ID: <5678.21-Nov-1997@example.com>
Hi everyone.

 

Приложение А.6.2. Устаревшие даты

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

From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: 21 Nov 97 09:55:06 GMT
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, «Hello».

 

Приложение А.6.3. Устаревшее пустое пространство и комментарии

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

From : John Doe <jdoe@machine(comment). example>
To : Mary Smith
__
<mary@example.net>
Subject : Saying Hello
Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
Message-ID : <1234 @ local(blah) .machine .example>
This is a message just to say hello.
So, «Hello».

Обратите особое внимание на вторую строку поля «Кому:». Начинается с двух пробелов. (Обратите внимание, что «__» представляет пробелы.) Поэтому он считается частью сгиба, как описано в разделе 4.2. Кроме того, комментарии и пробелы в адресах, датах и идентификаторах сообщений являются частью устаревшего синтаксиса.

 

Приложение B. Отличия от предыдущих спецификаций

В этом приложении содержится список изменений, которые были внесены в формат сообщений Интернета из более ранних спецификаций, в частности [RFC0822], [RFC1123] и [RFC2822]. Элементы, отмеченные звездочкой (*) ниже, являются элементами, которые указаны в разделе 4 этого документа и, следовательно, больше не могут быть сгенерированы.

Ниже приведены изменения, внесенные из [RFC0822] и [RFC1123] в [RFC2822], которые остаются в этом документе:

1. Период допускается в устаревшей форме фразы.
2. ABNF удален из документа, теперь в [RFC5234].
3. Четыре или более цифр допускаются для года.
4. Порядок полей заголовка (и его отсутствие) сделан явным.
5. Зашифрованное поле заголовка удалено.
6. Специально разрешить и придать значение часовому поясу «-0000».
7. Не допускается складывание пробелов между каждым токеном.
8. Требование по пунктам назначения удалено.
9. Переадресация и повторная отправка.
10. Поля заголовка расширения больше не вызываются.
11. ASCII 0 (ноль) удален. *
12. Складывающиеся строки продолжения не могут содержать только пробелы. *
13. Бесплатная вставка комментариев не допускается в дате. *
14. Нечисловые часовые пояса не допускаются. *
15. Двузначные годы не допускаются. *
16. Три цифры года интерпретируются, но не допускаются для генерации. *
17. Маршруты по адресам не допускаются. *
18. CFWS внутри локальных частей и доменов не допускается. *
19. Пустые члены списков адресов не допускаются. *
20. Запрещается складывать пробелы между именем поля и двоеточием. *
21. Комментарии между именем поля и двоеточием не допускаются.
22. Ужесточен синтаксис in-reply-to и ссылок. *
23. CFWS внутри msg-id не допускается. *
24. Уточненная семантика последних полей как только информационная.
25. Повторно отправленный ответ не разрешен. *
26. Нет многократных вхождений полей (кроме отправленных и полученных). *
27. Свободные CR и LF не допускаются. *
28. Указаны пределы длины линии.
29. Bcc более четко указано.

Ниже приведены изменения из [RFC2822].

1. Исправлено несколько типографских / грамматических ошибок и внесены уточнения.
2. Изменено «стандартное» на «документ» или «спецификация».
3. Сделано различие между «заголовком поля» и «заголовком раздела».
4. Удалены NO-WS-CTL из ctext, qtext, dtext и неструктурированных. *
5. Перемещено обсуждение спецпредложений в раздел «Atom». Перемещен текст в раздел «Общий синтаксис сообщения».
6. Упрощенный синтаксис CFWS.
7. Исправлен неструктурированный синтаксис.
8. Изменен синтаксис даты и времени для устранения пробелов в устаревшем синтаксисе даты.
9. Удалена цитируемая пара из литералов домена и идентификаторов сообщений. *
10. Уточнил, что другие спецификации ограничивают синтаксис домена.
11. Упрощенный синтаксис «Bcc:» и «Resent-Bcc:».
12. Разрешено добавление необязательного поля в информации трассировки.
13. Удалил no-fold-quote из msg-id. Уточнены синтаксические ограничения.
14. Обобщенный синтаксис «Received:» для исправления ошибок и перемещения определения из этого документа.
15. Упрощенный obs-qp. Исправлен и упрощен obs-utext (который теперь появляется только в устаревшем синтаксисе). Убраны obs-text и obschar, добавлены obs-body.
16. Исправлен устаревший синтаксис даты, чтобы позволить больше (или меньше) комментариев и пробелов.
17. Исправлен весь устаревший синтаксис списка (obs-domain-list, obs-mbox-list, obs-addr-list, obs-фразу-list и недавно добавленный obs-grouplist).
18. Исправлен синтаксис obs-reply-to.
19. Исправлены obs-bcc и obs-resent-bcc для разрешения пустых списков.
20. Удален obs-путь.

 

Приложение C. Благодарности

Многие люди внесли свой вклад в этот документ. Среди них были люди, которые участвовали в Рабочей группе по детальному пересмотру и обновлению стандартов обмена сообщениями (DRUMS) Целевой группы по инженерным вопросам интернета (IETF), председатель DRUMS, региональные директора IETF и люди, которые просто отправляли свои комментарии через Эл. адрес. Редактор глубоко признателен всем им и искренне благодарит их. Ниже приведен список всех, кто отправил электронное письмо, касающееся как этого документа, так и [RFC2822]. Надеемся, что каждый, кто внес свой вклад, назван здесь:

Matti Aarnio, Tanaka Akira, Russ Allbery, Eric Allman, Harald Alvestrand, Ran Atkinson, Jos Backus, Bruce Balden, Dave Barr, Alan Barrett, John Beck, J Robert von Behren, Jos den Bekker, D J Bernstein, James Berriman, Oliver Block, Norbert Bollow, Raj Bose, Antony Bowesman, Scott Bradner, Randy Bush, Tom Byrer, Bruce Campbell, Larry Campbell, W J Carpenter, Michael Chapman, Richard Clayton, Maurizio Codogno, Jim Conklin, R Kelley Cook, Nathan Coulter, Steve Coya, Mark Crispin, Dave Crocker, Matt Curtin, Michael D’Errico, Cyrus Daboo, Michael D Dean, Jutta Degener, Mark Delany, Steve Dorner, Harold A Driscoll, Michael Elkins, Frank Ellerman, Robert Elz, Johnny Eriksson, Erik E Fair, Roger Fajman, Patrik Faltstrom, Claus Andre Faerber, Barry Finkel, Erik Forsberg, Chuck Foster, Paul Fox, Klaus M Frank, Ned Freed, Jochen Friedrich, Randall C Gellens, Sukvinder Singh Gill, Tim Goodwin, Philip Guenther, Arnt Gulbrandsen, Eric A Hall, Tony Hansen, John Hawkinson, Philip Hazel, Kai Henningsen, Robert Herriot, Paul Hethmon, Jim Hill, Alfred Hoenes, Paul E Hoffman, Steve Hole, Kari Hurtta, Marco S Hyman, Ofer Inbar, Olle Jarnefors, Kevin Johnson, Sudish Joseph, Maynard Kang, Prabhat Keni, John C Klensin, Graham Klyne, Brad Knowles, Shuhei Kobayashi, Peter Koch, Dan Kohn, Christian Kuhtz, Anand Kumria, Steen Larsen, Eliot Lear, Barry Leiba, Jay Levitt, Bruce Lilly, Lars-Johan Liman, Charles Lindsey, Pete Loshin, Simon Lyall, Bill Manning, John Martin, Mark Martinec, Larry Masinter, Denis McKeon, William P McQuillan, Alexey Melnikov, Perry E Metzger, Steven Miller, S Moonesamy, Keith Moore, John Gardiner Myers, Chris Newman, John W Noerenberg, Eric Norman, Mike O’Dell, Larry Osterman, Paul Overell, Jacob Palme, Michael A Patton, Uzi Paz, Michael A Quinlan, Robert Rapplean, Eric S Raymond, Sam Roberts, Hugh Sasse, Bart Schaefer, Tom Scola, Wolfgang Segmuller, Nick Shelness, John Stanley, Einar Stefferud, Jeff Stephenson, Bernard Stern, Peter Sylvester, Mark Symons, Eric Thomas, Lee Thompson, Karel De Vriendt, Matthew Wall, Rolf Weber, Brent B Welch, Dan Wing, Jack De Winter, Gregory J Woodhouse, Greg A Woods, Kazu Yamamoto, Alain Zahm, Jamie Zawinski, Timothy S Zurcher

 

7. Ссылки

7.1. Нормативные ссылки

[ANSI.X3-4.1986] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

7.2. Информационные ссылки

[ISO.2022.1994] International Organization for Standardization, «Information technology — Character code structure and extension techniques», ISO Standard 2022, 1994.

[RFC0822] Crocker, D., «Standard for the format of ARPA Internet text messages», STD 11, RFC 822, August 1982.

[RFC1305] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation», RFC 1305, March 1992.

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types», RFC 2046, November 1996.

[RFC2047] Moore, K., «MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text», RFC 2047, November 1996.

[RFC2049] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples», RFC 2049, November 1996.

[RFC2822] Resnick, P., «Internet Message Format», RFC 2822, April 2001.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC4021] Klyne, G. and J. Palme, «Registration of Mail and MIME Header Fields», RFC 4021, March 2005.

[RFC4288] Freed, N. and J. Klensin, «Media Type Specifications and Registration Procedures», BCP 13, RFC 4288, December 2005.

[RFC4289] Freed, N. and J. Klensin, «Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures», BCP 13, RFC 4289, December 2005.

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, October 2008.

 

Адрес автора

Peter W. Resnick (editor)
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/

 

Заявление об авторском праве

Авторское право (C) Траст IETF (2008).

На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, указанных в нем, авторы сохраняют за собой все свои права.

Этот документ и информация, содержащаяся в данном документе, предоставляются на условиях «КАК ЕСТЬ», и ИСПОЛНИТЕЛЬ, ОРГАНИЗАЦИЯ, КОТОРАЯ ОН ПРЕДСТАВЛЯЕТ ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЛЮБОЙ), ИНТЕРНЕТ-ОБЩЕСТВО, IETF TRUST И ИНТЕРНЕТ-ИНЖИНИРИНГ ЗАДАЧА, ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИИ, ЯВНЫЕ ИЛИ ПОДРАЗУМЕВАЕМЫЕ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

 

Интеллектуальная собственность

IETF не занимает никакой позиции относительно действительности или объема каких-либо прав интеллектуальной собственности или других прав, которые могут быть заявлены как относящиеся к внедрению или использованию технологии, описанной в этом документе, или степени, в которой любая лицензия в соответствии с такими правами может или не может быть быть доступным; и при этом это не означает, что оно предприняло какие-либо независимые усилия для выявления любых таких прав. Информацию о процедурах в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия прав интеллектуальной собственности, сделанного в Секретариат IETF, и любые гарантии лицензий, которые должны быть предоставлены, или результат попытки получить общую лицензию или разрешение на использование таких прав собственности исполнителями или пользователями данной спецификации могут быть получены из онлайнового хранилища прав интеллектуальной собственности IETF по адресу http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне довести до ее сведения любые авторские права, патенты или патентные заявки или другие права собственности, которые могут касаться технологии, которая может потребоваться для реализации этого стандарта. Пожалуйста, отправьте информацию в IETF по адресу ietf-ipr@ietf.org.