Энциклопедия сетевых протоколов

Network Working Group                                P. Resnick, Ed.
Request for Comments: 5322                     Qualcomm Incorporated
Obsoletes: 2822                                         October 2008
Updates: 4021
Category: Standards Track

Формат сообщений Internet

Internet Message Format

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Аннотация

Этот документ задает формат сообщений Internet (IMF¹) — синтаксис текстовых сообщений, передаваемых между пользователями компьютеров через систему электронной почты. Данная спецификация является пересмотром RFC 2822, который, в свою очередь, пересматривает RFC 822, Standard for the Format of ARPA Internet Text Messages², с учетом опыта использования и накопленных изменений, отраженных в других RFC.

1. Введение

1.1. Рамки документа

Этот документ задает формат сообщений Internet (IMF) — синтаксис текстовых сообщений, передаваемых между пользователями компьютеров через систему электронной почты. Данная спецификация является пересмотром RFC 2822 [RFC2822], который, в свою очередь, пересматривает RFC 822, Standard for the Format of ARPA Internet Text Messages [RFC0822], с учетом опыта использования и накопленных изменений, отраженных в других RFC (таких, как [RFC1123]).

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

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

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

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

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

1.2. Система обозначений

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

В этом документе используются термины, выделенные полужирным шрифтом. Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе используются для обозначения уровня требований и интерпретируются в соответствии с [RFC2119].

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

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

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

Документ делится на несколько частей.

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

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

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

Разделы 2 и 3 описывают сообщения, соответствующие данной спецификации.

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

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

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

В Приложении B перечислены отличия данной спецификации от более ранних версий спецификации формата сообщений Internet.

В Приложении 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. Предельные размеры строк

Данная спецификация вносит два ограничения на число символов в строке. Строка должна содержать не более 988 символов; следует использовать строки размером не более 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), которые вместе называют также пробельными символами⁶. В значение поля недопустимо включать символы 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 символов), значение поля может быть разбито на несколько строк; это называется «фальцовкой» (folding). Общим правило заключается в том, что данная спецификация разрешает включение последовательности CRLF (новая строка) перед любыми пробельными символами.

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

Subject: This is a test

можно записать в форме

Subject: This
is a test

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

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

2.3. Тело письма

Тело сообщения представляет собой простые строки символов US-ASCII. Для содержимого сообщения существует только два типа ограничений⁷:

• символы CR и LF должны использоваться только совместно, как CRLF; недопустимо использование этих символов в теле сообщения по-отдельности;
• строки символов должны быть не длиннее 998 символов, следует ограничивать размер строк 78 символами (без учета CRLF).

3. Синтаксис

3.1. Введение

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

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

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

3.2. Лексемы

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

3.2.1. Квотрирование символов

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

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

При появлении любой пары с квотированием (quoted-pair) она интерпретируется как отдельный символ. Т. е., символ \⁹, являющийся частью пары с квотированием, становится семантически «невидимым».

3.2.2. Пробелы для фальцовки и комментарии

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

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

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

   FWS             =   ([*WSP CRLF] 1*WSP) / obs-FWS
                                          ; пробельные символы для фальцовки
   ctext           =   %d33-39 /          ; печатаемые символы US-ASCII,
                       %d42-91 /          ; не включая
                       %d93-126 /         ; "(", ")" и "\"
                       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. Для таких конструкций определена дополнительная лексема «атом с точкой» (dot-atom).

   atext           =   ALPHA / DIGIT /    ; Печатаемые символы US-ASCII, 
                       "!" / "#" /        ; не включая специальных символов.
                       "$" / "%" /        ; Используются для атомов.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"
   atom            =   [CFWS] 1*atext [CFWS]
   dot-atom-text   =   1*atext *("." 1*atext)
   dot-atom        =   [CFWS] dot-atom-text [CFWS]
   specials        =   "(" / ")" /        ; Специальные символы1, которые не 
                       "<" / ">" /        ; появляются в atext
                       "[" / "]" /
                       ":" / ";" /
                       "@" / "\" /
                       "," / "." /
                       DQUOTE

Лексемы atom и dot-atom интерпретируются, как единый элемент, включающий строку символов. Семантически дополнительные комментарии и FWS, окружающие остальные символы, не являются частью атома — атом представляет собой только символы atext (или atext и «.» для dot-atom).

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

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

   qtext           =   %d33 /             ; Печатаемые символы US-ASCII, 
                       %d35-91 /          ; не включая "\"
                       %d93-126 /         ; и символа кавычек
                       obs-qtext
   qcontent        =   qtext / quoted-pair
   quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

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

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

3.2.5. Прочие лексемы

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

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

Дата (day) показывает порядковый номер дня в месяце. Год (year) может принимать любое значение, не ранее 1900.

Время суток (time-of-day) показывает число часов, минут и (опционально) секунд, прошедщих с полуночи указанной даты.

Значения date и time-of-day следует указывать по местному времени.

Часовой пояс (zone) показывает смещение относительно универсального времени (UTC¹², ранее использовался термин GMT¹³) значений местного времени, указанного в date и time-of-day. Знаки «+» и «-» показывают направление смещения — вперед (т. е., к востоку) или назад (к западу) от универсального времени. Первые две цифры показывают разницу с универсальным временем в часах, а две последних — дополнительную разницу в минутах. Следовательно, +hhmm означает смещение на +(hh * 60 + mm) минут от универсального времени, а -hhmm — на -(hh * 60 + mm) минут. Для индикации часового пояса, время которого совпадает с универсальным, следует использовать форму +0000. Хотя вариант -0000 указывает на тот же часовой пояс, этот вариант используется для индикации того, что время было указано системой, которая может находиться в часовом поясе, отличном от UT, а значение date-time не содержит информации о часовом поясе.

Значение date-time должно быть семантически корректным. Т. е., значение day-of-week (при его наличии) должно содержать день недели, числовое значение day-of-month должно находиться в диапазоне от 1 до числа дней в соответствующем месяце (указанного года), значение time-of-day должно находиться в диапазоне от 00:00:00 до 23:59:60 (число секунд, допустимое для смены суток; см. [RFC1305]), а две последних цифры поля zone должны иметь значение от 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 для адресов Internet приведено в параграфе 3.4.1.

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

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

3.4.1. Задание addr-spec

Поле addr-spec представляет собой специфический для Internet идентификатор, содержащий локально интерпретируемую строку, за которой следует символ @ (код ASCII — 64) и доменное имя Internet. Эта локально интерпретируемая строка представляет собой строку в кавычках или атом с точкой. Если строка может быть представлена атомом с точкой (т. е., не содержит символов, кроме atext и завершающей точки или, за которой следуют символы atext), следует использовать форму dot-atom и не следует применять форму quoted-string. Комментарии и пробельные символы фальцовки не следует помещать рядом с @ в поле addr-spec.

Примечание. Здесь приведен либеральный синтаксис для доменной части addr-spec. Однако доменная часть содержит адресную информацию, задаваемую и используемую другими протоколами (например, [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Следовательно, на реализации возлагается ответственность за соответствие синтаксиса адресов контексту, в котором они используются.

   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 /          ; Печатаемые символы US-ASCII,
                       %d94-126 /         ; не включая 
                       obs-dtext          ; "[", "]", "\"

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

Локальная часть (local-part) зависит от домена. В адресах она просто интерпретируется на конкретном хосте, как имя почтового ящика.

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

Сообщение состоит из полей заголовка, за которыми может следовать тело сообщения. Строки сообщения должны иметь размер не более 998 символов, не считая CRLF, но рекомендуется использовать строки не длиннее 78 без учета CRLF (см. параграф 2.1.1). Хотя в теле сообщения могут появляться любые символы, перечисленные в правиле text, использование управляющих символов US-ASCII (коды 1- 8, 11, 12, 14 — 31) не является хорошим тоном, поскольку их интерпретация при отображении на приемной стороне не гарантируется.

   message         =   (fields / obs-fields)
                       [CRLF body]
   body            =   (*(*998text CRLF) *998text) / obs-body
   text            =   %d1-9 /            ; Символы, за исключением CR и LF
                       %d11 /             
                       %d12 /
                       %d14-127

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

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

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

Важно подчеркнуть, что порядок следования полей заголовка не гарантируется. Поля заголовков могут появляться в произвольном порядке. Более того, известно, что порядок полей заголовков может изменяться при передаче сообщений через Internet. Однако в соответствиии с данной спецификацией порядок полей заголовка не следует менять при передаче или преобразовании сообщений. Более важно отметить, что порядок трассировочных полей и полей resent изменять недопустимо и следует сохранять эти поля в блоках, добавляемых в начало сообщения (prepend). Дополнительная информация об этих полях содержится в параграфах 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)

 

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

Поле	Минимум	Максимум	Примечания
trace	0	Не ограничен	Блок добавляется в начало, см. параграф 3.6.7
resent-date	0*	Не ограничен*	Одно на блок; требуется при наличии других полей resent, см. параграф 3.6.6
resent-from	0	Не ограничен*	Одно на блок, см. параграф 3.6.6
resent-sender	0*	Не ограничен*	Одно на блок; должно присутствовать при наличии множества адресов, см. параграф 3.6.6
resent-to	0	Не ограничен*	Одно на блок, см. параграф 3.6.6
resent-cc	0	Не ограничен*	Одно на блок, см. параграф 3.6.6
resent-bcc	0	Не ограничен*	Одно на блок, см. параграф 3.6.6
resent-msg-id	0	Не ограничен*	Одно на блок, см. параграф 3.6.6
orig-date	1	1
from	1	1	См. sender и параграф 3.6.2
sender	0*	1	Должно присутствовать при наличии множества адресов, см. параграф 3.6.2
reply-to	0	1
to	0	1
cc	0	1
bcc	0	1
message-id	0*	1	Следует включать, см. параграф 3.6.4
in-reply-to	0*	1	Следует включать, см. параграф 3.6.4
references	0*	1	Следует включать, см. параграф 3.6.4
subject	0	1
comments	0	Не ограничен
keywords	0	Не ограничен
optional-field	0	Не ограничен

Точная интерпретация каждого поля рассмотрена в последующих параграфах.

3.6.1. Поле даты создания

Поле даты создания состоит из имени поля «Date», за которым следуют значения даты и времени.

orig-date = "Date:" date-time CRLF

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

3.6.2. Поля источника

В число полей источника сообщения входят from и sender (когда применимо), а также опционально — reply-to. Поле from содержит имя «From» и разделенный запятыми список из одного или нескольких имен почтовых ящиков. Эсли это поле содержит более одного адреса почтового ящика в списке, в сообщение должно включаться поле «Sender» с указанием одного почтового ящика. Дополнительно может также включаться поле «Reply-To», содержащее список разделенных запятыми почтовых ящиков (не менее одного).

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

Поле источника показывает почтовый ящик(и) источника сообщения. Поле «From:» задает автора (авторов) сообщения, т. е., почтовый ящик(и) человека или системы, ответственных за создание данного сообщения. Поле «Sender:» указывает почтовый ящик агента, ответственного за реальную передачу сообщения. Например, если секретарь отправил письмо от имени своего руководителя, почтовый ящик секретаря будет указан в поле «Sender:», а адрес действительного автора сообщения — в поле «From:». Если источник сообщения может быть задан единственным почтовым ящиком (автор и отправитель совпадают), поле «Sender:» использовать не следует¹⁵. В остальных случаях это поле следует включать в заголовок.

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

В любом случае в поле «From:» не следует указывать адрес, не имеющий отношения к автору письма. Формирование адресов для отправки ответов на сообщения дополнительно рассматривается в параграфе 3.6.3.

3.6.3. Поля адресов получателей

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

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

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

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

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

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

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

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

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

Хотя в таблице параграфа 3.6 поле «Message-ID:» указано, как необязательное, это поле следует включать в каждое сообщение. Более того, в ответные сообщения следует включать поля «In-Reply-To:» и «References:» в соответствии с приведенным ниже описанием.

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

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

Примечание. Как и в случае addr-spec, для правой части msg-id (после символа @) дается либеральный синтаксис. Однако ниже в этом параграфе сказано, что рекомендуется использовать справа от знака @ доменное имя. Как и прежде, синтаксис доменного имени задается и используется в других протоколах (например, [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Следовательно, на реализации возлагается вопрос соответствия адресов контексту, в котором они используются.

   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:» обеспечивает уникальный идентификатор сообщения, который указывает на конкретный вариант конкретного письма. Уникальность идентификатора гарантируется хостом, создающим сообщение (см. ниже). Этот идентификатор предназначен для машинной обработки и не имеет большого смысла для человека. Идентификатор сообщения относится только к одному варианту конкретного письма — для следующего экземпляра сообщения будет создан другой идентификатор.

Примечание. Существует множество ситуаций, когда сообщения «изменяются», но эти изменения не порождают нового экземпляра данного сообщения и, следовательно, сообщение не получает нового идентификатора. Например, когда сообщения вводятся в транспортную систему, в начало сообщения зачастую добавляются дополнительные поля заголовков, такие, как поля трассировки (параграф 3.6.7) и поля пересылки (параграф 3.6.6). Добавление таких полей в заголовки не меняет сообщения, как такового, и, следовательно, значение «Message-ID:» сохраняется. Во всех случаях содержимое, которое желает передать отправитель (то же самое сообщение или другое), а не какое-либо синтаксическое отличие, которое появляется (или не появляется) в сообщении, определяет сохранение или изменение поля «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 подобен синтаксису addr-spec (за исключением запрета на включение строк в кавычках, комментариев и фальцовочных пробелов), хорошим методом является включение в идентификатор доменного имени (или полного адреса IP) хоста, на котором создается идентификатор сообщения, справа от знака @ (доменные имена и адреса IP обычно уникальны) и включение текущего абсолютного значения даты и времени в комбинации с неким другим уникальным в данный момент (возможно последовательным) идентификатором, доступным в системе (например, идентификатором процесса), слева от @. Хотя будут работать и другие алгоритмы, рекомендуется использовать в правой части некий идентификатор домена (имя хоста или нечто иное), чтобы генератор идентификатора сообщения мог гарантировать уникальность левой части идентификатора в масштабе данного домена.

Семантически угловые скобки не являются частью 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: » только один раз, поскольку использование другого текста или включение нескольких префиксов может приводить к нежелательным последствиям. Поле «Comments:» содержит произвольную информацию, дополняющую текст в теле письма. Поле «Keywords:» содержит список разделенных запятыми слов и фраз » field contains a comma-separated list of important words and phrases that might be useful for the recipient.

3.6.6. Поля пересылки

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

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

При использовании полей пересылки должны передаваться поля «Resent-From:» и «Resent-Date:». Следует передавать также поле «Resent-Message-ID:». Поле «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:») пересылает сообщение от имени одного или множества других лиц (идентифицируются полем «Resent-From:»).

Примечание. При ответе на пересланное сообщение исходные поля «From:», «Reply-To:», «Message-ID:» и др. используются в обычном порядке. Поля пересылки являются только информационными и недопустимо использовать их при ответе на сообщение.

Поле «Resent-Date:» указывает дату и время диспетчеризации сообщения при его пересылке. Подобно полю «Date:», оно содержит не дату и время реальной отправки сообщения, а дату и время постановки в очередь.

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

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

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

Поля трассировки представляют собой группу полей заголовка, включающую опциональное поле «Return-Path:» и одно или множество полей «Received:». Поле заголовка «Return-Path:содержит пару угловых скобок, в которые заключено необязательное значение addr-spec. Поле «Received:» содержит (возможно пустой) список маркеров, за которым следует точка с запятой (;) и значение даты и времени. Каждый маркер должен представлять собой элемент типа word, angle-addr, addr-spec или domain. Спецификации, описывающие использование полей трассировки (такие, как [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

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

3.6.8. Дополнительные поля

В сообщениях могут появляться поля, не рассмотренные в этом документе. Такие поля должны соответствовать синтаксису optional-field. Этот синтаксис включает имя поля, состоящее из печатаемых символов US-ASCII без двоеточий и пробелов (SP), за которым следует двоеточие и произвольный текст, соответствующий синтаксису бесструктурных полей.

Недопустимо совпадение имен дополнительных полей с именами полей, указанными в данном документе.

   optional-field  =   field-name ":" unstructured CRLF
   field-name      =   1*ftext
   ftext           =   %d33-57 /          ; Печатаемые символы US-ASCII, 
                       %d59-126           ; за исключением «:».

В настоящей спецификации дополнительные поля считаются неинтерпретируемыми.

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

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

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

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

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

В этом разделе также рассматриваются некоторые символы, которые раньше разрешалось использовать в сообщениях. Символ NUL (код ASCII — 0) считался разрешенным, но сейчас к таковым не относится. Аналогично, управляющие символы US-ASCII, отличные от 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-phrase¹⁸. Поддерживается лексема obs-phrase-list для (возможно пустых) списков разделенных запятыми фраз, которые могут включать «пустые» элементы. Т. е. в таком списке могут быть две и более запятых, между которыми не содержится ничего; возможны также запятые в начале и в конце списка.

   obs-NO-WS-CTL   =   %d1-8 /            ; Управляющие символы US-ASCII, 
                       %d11 /             ; не включая символов
                       %d12 /             ; возврата картеки, 
                       %d14-31 /          ; перевода строки и 
                       %d127              ; пробельных символов
   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])

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

4.2. Устаревшие пробелы для фальцовки

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

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

4.3. Устаревшие форматы даты и времени

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

   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" /     ; Смещение от UT для Северной Америки
                       "EST" / "EDT" /    ; восток:  - 5/ - 4
                       "CST" / "CDT" /    ; центр:  - 6/ - 5
                       "MST" / "MDT" /    ; горы: - 7/ - 6
                       "PST" / "PDT" /    ; тихоокеанское побережье:  - 8/ - 7
                                          ;
                       %d65-73 /          ; Военные часовые пояса — от A 
                       %d75-90 /          ; до I и от K
                       %d97-105 /         ; до Z, 
                       %d107-122          ; в верхнем и нижнем регистре

При использовании 2 или трех цифр в поле года интерпретация выполняется следующим образом — если 2-значное обозначение года лежит в диапазоне от 00 до 49, к значению прибавляется 2000, т. е., год принимает значение от 2000 до 2049; если 2-значное обозначение года лежит в диапазоне от 50 до 99, к значению прибавляется 1900.

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

Оставшиеся три символа часового пояса являются обозначениями часовых поясов США. Первая буква («E», «C», «M» или «P») означает «Eastern» (восточный), «Central» (центральный), «Mountain» (горный) и «Pacific» (тихоокеанский). Вторая буква может быть «S» (Standard — стандартное время) или «D» (Daylight Savings — летнее время).

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

EDT семантически эквивалентно -0400

EST семантически эквивалентно -0500

CDT семантически эквивалентно -0500

CST семантически эквивалентно -0600

MDT семантически эквивалентно -0600

MST семантически эквивалентно -0700

PDT семантически эквивалентно -0700

PST семантически эквивалентно -0800

Один символ военного часового пояса был определен нестандартным способом в [RFC0822] и, следовательно, его значение непредсказуемо. Исходные определения военных часовых поясов от «A» до «I» эквивалентны поясам от «+0100» до «+0900», соответственно; «K», «L» и «M» эквивалентны «+1000», «+1100» и «+1200», соответственно; «N» — «Y» эквивалентны поясам от «-0100» до «-1200», соответственно; «Z» эквивалентно «+0000». Однако в результате ошибки в [RFC0822] все эти обозначения следует трактовать, как эквивалентные «-0000» если явно не задано иное их толкование.

В почтовых сообщениях Internet применяются и другие многосимвольные (обычно от 3 до 5 букв) обозначения часовых поясов. Все обозначения, смысл которых непонятен, следует трактовать, как эквивалент «-0000» если явно не указано иное их толкование.

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

В адресации имеется четыре основных различия. Во-первых, в адресе почтового ящика разрешалось использовать перед addr-spec маршрутную часть, заключенную в угловые скобки. Маршрут является просто списком разделенных запятыми доменных имен, каждое из которых имеет префикс «@»; для завершения списка используется двоеточие (:). Во-вторых, разрешалось включать символы CFWS между разделенными точками элементами локальной части и домена (т. е., лексема dot-atom не использовалась). Кроме того, в local-part можно было в дополнение к атомам включать строки в кавычках. В-третьих, разрешалось включать в списки почтовых ящиков (mailbox-list) и списки адресов (address-list) пустые (null) элементы. Т. е., в списке могли следовать две или более запятых подряд, а также разрешалось присутствие запятых в начале и в конце списков. В-четвертых, разрешалось использовать управляющие символы 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 в local-part и domain не является частью 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-received приведены здесь, как шаблоны определений, идентичные return и received в разделе 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-последовательности из сообщения перед его выводом. Однако некоторые escape-последовательности могут быть нужны в сообщениях (см. [ISO.2022.1994], [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) и поэтому не следует удалять escape-последовательности без разбора.

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

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

6. Согласование с IANA

Этот документ обновляет регистрации, перечисленные в [RFC4021], которые относятся к определениям из [RFC2822]. Агентство IANA обновило реестр Permanent Message Header Field Repository, включив в него в соответствии с [RFC3864] перечисленные ниже поля заголовков.

Имя поля: Date
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.1)

Имя поля: From
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.2)

Имя поля: Sender
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.2)

Имя поля: Reply-To
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.2)

Имя поля: To
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.3)

Имя поля: Cc
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.3)

Имя поля: Bcc
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.3)

Имя поля: Message-ID
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.4)

Имя поля: In-Reply-To
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.4)

Имя поля: References
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.4)

Имя поля: Subject
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.5)

Имя поля: Comments
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.5)

Имя поля: Keywords
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.5)

Имя поля: Resent-Date
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-From
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-Sender
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-To
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-Cc
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-Bcc
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Resent-Reply-To
Применимый протокол: Mail
Состояние: устарел
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 4.5.6)

Имя поля: Resent-Message-ID
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.6)

Имя поля: Return-Path
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.7)

Имя поля: Received
Применимый протокол: Mail
Состояние: стандарт
Автор/контроль изменений: IETF
Спецификация: Данный документ (параграф 3.6.7)
Дополнительная информация: [RFC5321]

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

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

Примеры сообщений отделены от текста строками «—-», которые не являются частью сообщений.

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

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

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

Этот пример можно назвать каноническим сообщением. Письмо имеет одного автора (John Doe), одного получателя (Mary Smith), тему, дату, идентификатор сообщения и текст в теле письма.

   ----
   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".
   ----

Если у John есть секретарь Michael, который на самом деле отправляет сообщение, автором которого является по-прежнему John и ответы на письмо должны направляться секретарю, следует использовать поле sender:

   ----
   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".
   ----

 

Приложение A.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; «Big» Box требуется заключать в двойные кавычки, поскольку первое имя включает точку, а во втором содержится точка с запятой и символы двойных кавычек (в форме пар с квотированием). Отображаемое имя Who?, напротив, может использоваться без кавычек, поскольку в атомах допускается использование вопросительного знака. Отметим также, что в адресах jdoe@example.org и boss@nil.test не указаны связанные с ними отображаемые имена, а для адреса jdoe@example.org используется упрощенная форма без угловых скобок.

Приложение A.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.
   ----

В этом примере поле «To:» включает группу «A Group», в состав которой входят 3 адреса, а в поле «Cc:» указана пустая группы получателей Undisclosed recipients (нераскрытые получатели).

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

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

Отметим специально поля «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".
   ----

При отправке ответов поле Subject зачастую сохраняется с добавлением префикса «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:» в приведенном выше сообщении. Когда John отвечает на приведенное выше письмо Mary, ответ следует направлять по адресу из поля «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.
   ----

 

Приложение A.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".
   ----

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

   ----
   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".
   ----

 

Если Jane, в свою очередь, решит переслать сообщение еще кому-либо, она будет добавлять свои поля пересылки перед сообщением, показанным выше (для краткости этот вариант примера опущен).

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

При пересылке сообщения через транспортную систему, как описано в [RFC5321], в начало сообщения добавляются трассировочные поля. Ниже приведен пример, показывающий, как могут выглядеть эти поля. Отметим, что первая строка «Received:» оказалась слишком длинной и в нее включены фальцовочные пробелы.

   ----
   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".
   ----

Приложение A.5. Пробелы, комментарии и другие странности

Пробеля, включая фальцовочные, и комментарии могут вставляться между разными элементами поля. Возьмем пример из параграфа A.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) комментарий в поле «From:» (включая скобку в паре с квотированием); (2) отсутствие пробела после двоеточия в поле «To:», а также комментарий и фальцовочные пробелы после имени группы, специальный символ (.) в комментарии поля с адресом Chris Jones и фальцовочные пробелы перед и после «joe@example.org,»; (3) множество вложенных комментариев в поле «Cc:», а также комментарий, следующий непосредственно за двоеточием после «Cc»; (4) фальцовочный пробел (но не комментарии, за исключением комментария в конце поля даты), а также отсутствие значения секунд; (5) пробелы после (но не внутри) идентификатора в поле «Message-ID:».

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

Здесь приведены примеры устаревших синтаксических элементов (которые недопустимо создавать), описанных в разделе 4 данного документа.

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

Отметим в приведенном ниже примере отсутствие кавычек вокруг Joe Q. Public, маршрут в адресе Mary Smith, две запятых в поле «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.
   ----

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

В приведенном ниже сообщении используется устаревший формат даты, включая символьное представление часового пояса и 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".
   ----

Приложение A.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".
   ----

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

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

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

Ниже перечислены изменения [RFC0822] и [RFC1123], внесенные в [RFC2822] и сохраненные здесь:

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

Далее перечислены отличия настоящего документа от [RFC2822].

1. Исправлены найденные опечатки и приведены разъяснения.
2. Термин «стандарт» применительно к данному документу заменен на «документ» или «спецификация».
3. Разделены понятия «поле заголовка» (header field) и «раздел заголовков» (header section).
4. Удалено NO-WS-CTL из ctext, qtext, dtext и бесструктурных полей.*
5. Исправлено обсуждение специальных символов (specials) в параграфе «Atom». Текст перенесен в параграф «3.5. Общий синтаксис сообщений».
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 и obs-char, добавлено obs-body.
16. Исправлен устаревший синтаксис дат, чтобы разрешить больше (или меньше) комментариев и пробелов.
17. Исправлен синтаксис всех устаревших списков (obs-domain-list, obs-mbox-list, obs-addr-list, obs-phrase-list и вновь добавленный obs-group-list).
18. Исправлен синтаксис obs-reply-to.
19. Исправлены obs-bcc и obs-resent-bcc, чтобы разрешить пустые списки.
20. Удалено obs-path.

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

В создании этого документа участвовало множество людей. В их число входят участники рабочей группы Detailed Revision and Update of Messaging standards (DRUMS) под эгидой IETF, председатель DRUMS, руководители направления (Area Directors) 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 Faeltstroem	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. Дополнительные ссылки

[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.

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

[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 (редактор)

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/

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

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

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

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

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

Network Working Group                                     J. Klensin
Request for Comments: 5321                              October 2008
Obsoletes: 2821
Updates: 1123
Category: Standards Track

Простой протокол передачи электронной почты (SMTP)

Simple Mail Transfer Protocol

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Аннотация

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

1. Введение

1.1. Транспортировка электронной почты

Целью протокола SMTP¹ является обеспечение надежной и эффективной доставки электронной почты.

Протокол SMTP не зависит от конкретных подсистем передачи и требует для работы лишь канал с гарантированной и упорядоченной доставкой потока данных. Хотя в этом документе обсуждается использование транспорта TCP, возможно использование и других транспортных протоколов. Описания некоторых протоколов этого типа даны в приложениях к RFC 821 [1].

Важным свойством протокола SMTP является возможность транспортировки почты через множество сетей, которые обычно называют «почтовыми трансляторами SMTP»² (см. параграф 3.6). Сети состоят из обоюдно доступных по протоколу TCP хостов публичной сети Internet, обоюдно доступных по TCP хостов приватных сетей TCP/IP, находящихся на межсетевыми экранами, или хостов некоторых иных локальных и распределенных сред, использующих на транспортном уровне протоколы, отличные от TCP. Используя протокол SMTP, процесс может передавать почту другому процессу в той же сети или некоторых других сетях через трансляторы или шлюзы, доступные из обеих сетей.

Таким путем почтовые сообщения можно передавать через множество промежуточных трансляторов (relay) или шлюзов на пути между отправителем и конечным адресатом. Для определения следующего промежуточного получателя (next-hop) на пути к адресату используется механизм Mail eXchanger (MX) системы доменных имен (RFC 1035 [2], RFC 974 [12], раздел 5 данного документа).

1.2. Предыстория и контекст документа

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

• исходная спецификация SMTP (Simple Mail Transfer Protocol) — RFC 821 [1];
• требования к системе доменных имен и ее использованию для передачи электронной почты — RFC 1035 [2] и RFC 974 [12];
• пояснения и вопросы применимости RFC 1123 [3];
• материалы из механизмов расширения SMTP Extension — RFC 1869 [13];
• редакторские правки и разъяснения к RFC 2821 [14] для повышения статуса до Draft Standard.

Данный документ отменяет действие RFC 821, RFC 974, RFC 1869, RFC 2821 и обновляет RFC 1123 (замена материалов по доставке электронной почты в RFC 1123). Однако в RFC 821 приведены спецификации некоторых свойств, которые не стали достаточно значимыми в среде Internet середины 1990-х, и (в приложениях) некоторые дополнительные транспортные модели. Эти разделы опущены здесь с целью снижения объема документа, интересующиеся читатели могут обратиться к RFC 821.

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

Хотя SMTP разрабатывался как протокол транспортировки и доставки электронной почты, данная спецификация содержит также информацию, которая важна для использования протокола в качестве средства представления сообщений³, как рекомендовано спецификациями протоколов POP⁴ (RFC 937 [15], RFC 1939 [16]) и IMAP (RFC 3501 [17]). В общем случае предпочтительно использовать для представления почтовых сообщений отдельный протокол, описанный в RFC 4409 [18]; далее в документе этот вопрос рассматривается более подробно.

В параграфе 2.3 приводятся определения специфических для данного документа терминов. За исключением тех случаев, когда исторически сложившаяся терминология нужна для понимания, в данном документе применяются современные трактовки терминов «клиент» и «сервер» для обозначения передающих и принимающих процессов SMTP, соответственно.

В дополнительном документе RFC 5322 [4] обсуждаются разделы заголовков и тел почтовых сообщений, а также их структура и форматы.

1.3. Соглашение о терминах

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [5]. Такие термины в документе используются очень аккуратно в целях повышения уровня взаимодействия систем электронной почты. Каждое использование таких терминов должно трактоваться как уровень требований в части соответствия данной спецификации.

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

2. Модель SMTP

2.1. Базовая структура

Структура SMTP показана на рисунке.

            +----------+                +----------+
+------+    |          |                |          |
|Польз.|<-->|          |Команды/отклики |          |
+------+    |  Клиент  |      SMTP      |  Сервер  |
+------+    |   SMTP   |<-------------->|   SMTP   |    +------+
|Файлов|<-->|          |    и почта     |          |<-->|Файлов|
| сист.|    |          |                |          |    | сист.|
+------+    +----------+                +----------+    +------+
             Клиент SMTP                 Сервер SMTP

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

Способ представления почтовых сообщений клиенту SMTP и способ определения клиентом идентификаторов (имен) доменов, в которые данное сообщение будет передаваться, определяются локальными условиями и не рассматриваются в этом документе. В некоторых случаях указанный или определенный клиентом SMTP домен идентифицирует конечного получателя сообщения. В других случаях, когда клиенты SMTP связаны с реализациями протоколов POP (RFC 937 [15], RFC 1939 [16]) или IMAP (RFC 3501 [17]) или клиент располагается внутри изолированной транспортной среды, идентифицированный домен будет определять промежуточного получателя, через которого будут транслироваться все почтовые сообщения. Клиенты SMTP, которые передают весь трафик, независимо от домена адресата, связанного с конкретным сообщением, или не поддерживают очередей для повтора попыток передачи сообщений при неудаче, могут соответствовать данной спецификации, но не обеспечивать всех возможностей. Предполагается, что полнофункциональные реализации SMTP, включая трансляторы, которые используются неполными системами и их получателями, будут поддерживать очереди, повторы и альтернативную адресацию, рассматриваемые в данном документе. Во многих случаях упомянутым выше неполнофункциональным клиентам следует использовать протокол представления сообщений (RFC 4409 [18]) взамен SMTP.

Способ, с помощью которого клиент SMTP после определения домена адресата, находит сервер SMTP для передачи сообщения, а также процесс передачи определяются данной спецификацией. Для передачи почты SMTP-серверу клиент SMTP организует двухсторонний канал связи с сервером. SMTP-клиент определяет адрес подходящего хоста, на котором работает сервер SMTP, преобразуя доменное имя получателя в MX-запись (Mail exchanger) промежуточного или конечного хоста-получателя.

Сервер SMTP может быть конечным или промежуточным транслятором⁵ (после приема письма сервер выполняет функции клиента SMTP, пересылая сообщение дальше) или шлюзом⁶ (может передавать сообщение дальше, используя отличный от SMTP протокол). Команды SMTP генерируются клиентом SMTP и передаются серверу SMTP. Сервер SMTP передает отклики в ответ на команды клиента SMTP.

Иными словами, передача сообщения может осуществляться в один прием путем соединения исходного отправителя SMTP с конечным получателем SMTP или через цепочку промежуточных систем. В любом случае после того, как сервер сообщил об успешном завершении операции в конце передачи почтовых данных, происходит формальная передача ответственности — в соответствии с требованиями протокола сервер должен принять на себя ответственность за доставку сообщения или должным образом предоставить отчет о невозможности доставки (см. параграфы 6.1, 6.2 и 7.8 ниже).

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

Сервер обеспечивает отклик на каждую полученную команду – отклик может показывать восприятие команды (в таких случаях ожидаются дополнительные команды), а также содержать сообщение о временной или постоянной ошибке. Команды, задающие отправителя или получателей, могут включать поддерживаемые сервером SMTP расширения, описанные в параграфе 2.2. Диалог между клиентом и сервером осуществляется поэтапно (команда – отклик – команда …), хотя можно использовать по взаимному согласию конвейерную обработку (RFC 2920 [19]).

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

Как сказано выше, протокол обеспечивает механизм передачи электронной почты. Эта передача обычно осуществляется непосредственно с хоста отправителя на хост получателя, когда оба хоста используют один транспортный сервис. Если же хосты не подключены к общей транспортной системе, передача осуществляется с использованием одного или нескольких промежуточных серверов SMTP. Сегодня в Internet обычной практикой является представление исходного сообщения промежуточному серверу «представления сообщений»⁷, который похож на транслятор, но выполняет некоторые дополнительные функции; такие серверы рассматриваются в параграфе 2.3.10 и RFC 4409 [18]. Промежуточный хост в таких случаях действует как транслятор (SMTP relay) или шлюз в другие среды передачи и выбирается обычно с использованием MX-записей DNS (служба доменных имен).

Обычно промежуточные хосты определяются по записям DNS MX, а не путем явного задания маршрута отправителем (см. раздел 5, приложение C и параграф F.2).

2.2. Модель расширений

2.2.1. Базовые вопросы

В рамках программы, начатой в 1990, приблизительно через 10 лет после выпуска RFC 821, протокол был обновлен за счет добавления модели «расширения услуг»⁸, позволяющей клиентам и серверам согласовать использование общих функций, выходящих за пределы исходной спецификации SMTP. Механизм расширения SMTP определяет способ согласования расширенных возможностей клиента и сервера SMTP; сервер может информировать клиента о поддерживаемых расширениях.

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

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

• команда EHLO взамен прежней команды HELO;
• реестр расширений сервиса SMTP;
• дополнительные параметры команд MAIL и RCPT;
• возможность замены команд, определенных в данном протоколе (таких, как DATA) при передаче символов, отличных от ASCII (RFC 3030 [20]).

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

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

2.2.2. Определение и регистрация расширений

Реестр расширенных служб SMTP поддерживается агентством IANA. С каждым расширением связано соответствующее ключевое значение EHLO. Каждая дополнительная служба, регистрируемая IANA, должна быть определена на основе стандартного протокола или одобренного IESG экспериментального протокола. Определение должно включать:

• текстовое имя расширенного сервиса SMTP;
• ключевое значение EHLO связанное с этим расширением;
• синтаксис и возможные значения параметров, связанных с ключевым значением EHLO;
• все дополнительные команды SMTP, связанные с расширением (такие команды обычно используются, но не являются обязательными, как и ключевое значение EHLO);
• все новые параметры расширения, связанные с командами MAIL или RCPT;
• описание воздействия поддержки расширения на поведение клиентов и серверов SMTP;
• размер увеличения максимальной длины команд MAIL и/или RCPT сверх заданного настоящим стандартом.

Кроме того, все ключевые значения EHLO, начинающиеся с X или x, указывающие на локальные расширения сервиса SMTP, используются только на основе двухсторонних соглашений. Ключевые слова, начинающиеся с X (независимо от регистра) недопустимо использовать в регистрируемых расширениях сервиса. И наоборот, ключевые значения, представляемые в отклике EHLO, который не начинается с X, должны соответствовать стандарту, проекту стандарта или одобренному IESG экспериментальному расширению SMTP, зарегистрированному IANA. Для соответствующих требованиям стандарта серверов недопустимо предлагать начинающиеся с отличных от X символов расширения сервиса, если они не зарегистрированы.

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

2.2.3. Дополнительные вопросы, связанные с расширениями

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

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

2.3. Терминология SMTP

2.3.1. Почтовые объекты

Протокол SMTP обеспечивает транспортировку объектов электронной почты. Каждый объект состоит из конверта (envelope) и содержимого.

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

Содержимое SMTP передается в виде протокольного элемента SMTP DATA и состоит из двух частей – заголовков и тела. Если содержимое соответствует другим современным стандартам, заголовок состоит из набора полей, каждое из которых включает имя заголовка, двоеточие (;) и данные, структурированные в соответствии со спецификацией формата сообщения (RFC 5322 [4]); тело сообщения, при наличии в нем структуры, соответствует спецификации MIME (RFC 2045 [21]). Содержимое является текстовым по своей природе и выражается с использованием набора символов US-ASCII [6]. Хотя расширения SMTP (типа 8BITMIME, RFC 1652 [22]) могут обходить это ограничение для содержимого, заголовки всегда должны кодироваться с использованием набора символов US-ASCII. Два расширения MIME (RFC 2047 [23] и RFC 2231 [24]) определяют алгоритм представления в заголовках символов, не входящих в US-ASCII, с использованием комбинаций символов набора US-ASCII.

2.3.2. Отправители и получатели

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

2.3.3. Почтовые агенты и хранилища сообщений

В данной спецификации используется современная терминология, устоявшаяся с момента публикации RFC 821. В частности, клиенты и серверы SMTP обеспечивают почтовый транспортный сервис и, следовательно, называются «агентами доставки почты» — АДП (Mail Transfer Agent или MTA). Пользовательские почтовые агенты – ППА (Mail User Agent, MUA или UA) выступают в качестве исходных отправителей и конечных получателей почтовых сообщений. На стороне отправителя ППА может собирать почту от пользователя для передачи ее АДП; агент АДП на стороне получателя передает почту ППА (по крайней мере, передает этому агенту ответственность за доставку почты; например, помещая ее в «почтовое хранилище» — message store). Однако, хотя эти термины достаточно точно выражают суть и применимы к другим средам, границы между ППА (MUA) и АДП (MTA) определены недостаточно четко. Следовательно, читатель должен внимательно относиться к терминологии.

2.3.4. Хост

В рамках данной спецификации термин «хост» обозначает компьютерную систему, подключенную к Internet (или, в некоторых случаях, к частной сети TCP/IP) и поддерживающую протокол SMTP. Хосты обозначаются именами (см. следующий параграф); не следует использовать для идентификации хостов полные адреса (см. параграф 4.1.2).

2.3.5. Доменные имена

Доменное имя (или просто домен) состоит из одной или нескольких разделенных точками компонент. В случае использования в качестве адреса домена верхнего уровня, строка доменного имени не содержит точек. Это ведет к возникновению требования, более подробно рассмотренного ниже, об использовании при транзакциях SMTP в публичной сети Internet только полных доменных имен (FQDN¹⁰), что особенно важно при использовании доменов верхнего уровня. Компоненты доменных имен (метки в терминах DNS RFC 1035 [2]) при транзакциях SMTP могут содержать только последовательности букв¹¹, цифр, дефиса (-) и знака подчеркивания (_) из набора символов ASCII [6]. Доменные имена используются для обозначения хостов и других объектов иерархии доменных имен. Например, доменное имя может указывать на псевдоним (метка CNAME RR) или метку записи MX (Mail exchanger), которая будет использоваться для доставки почты вместо представленного имени хоста. Дополнительные сведения о доменных именах можно найти в RFC 1035 [2] и разделе 5 данной спецификации.

Доменное имя, как описано в данном документе и RFC 1035 [2], представляет собой полное имя (fully-qualified domain name или FQDN). Доменные имена, не являющиеся FQDN, есть ни что иное, как локальные псевдонимы. В транзакциях SMTP появление локальных псевдонимов недопустимо.

При использовании доменных имен в SMTP допускаются только полные (FQDN), преобразуемые DNS имена. Иными словами, разрешено использовать имена, которые могут быть преобразованы в записи MX RR или адреса (RR типа A или AAAA, как сказано в разделе 5), а также CNAME RR, псевдонимы которых могут быть преобразованы в MX или адреса. Локальные псевдонимы и неполные имена использовать недопустимо. Указанное правило имеет два исключения:

• доменное имя, указываемое в команде EHLO должно быть основным именем хоста (именем, преобразуемым в адрес) или, если у хоста нет имени, полным адресом, описанным в параграфе 4.1.3 и дополнительно рассмотренным при обсуждении команды EHLO в параграфе 4.1.4;
• зарезервированное имя почтового ящика postmaster может использоваться в команде RCPT без полного доменного имени (см. параграф 4.1.1.3) и, в случае такого использования, должно приниматься.

2.3.6. Буфер и таблица состояний

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

2.3.7. Команды и отклики

Команды SMTP и (если расширение сервиса не задает иного) данные сообщений передаются от отправителя к получателю через коммуникационный канал в форме строк.

Отклик SMTP представляет собой подтверждение (или отказ), передаваемое в форме строк от получателя к отправителю через коммуникационный канал в ответ на полученную команду. Общей формой отклика является цифровой код результате (отказ или успешное завершение), за которым обычно следует текстовая строка. Коды служат для использования программами, а текст обычно предназначен для человека. В RFC 3463 [25] содержится спецификация дополнительного структурирования текстовых строк, включая использование дополнений и более специфических кодов завершения (см. также RFC 5248 [26]).

2.3.8. Строки

Строка состоит из некоторого (возможно, нулевого) числа символов данных и завершается символами ASCII для возврата каретки (CR — 0Dh) и перевода строки (LF — 0Ah). Последовательность завершения строки в этом документе будет обозначаться <CRLF>. Для реализаций, соответствующих требованиям данной спецификации, недопустимо принимать или генерировать в качестве завершения строки любые другие символы или последовательности символов. Серверы могут вносить ограничения на длину строк (см. раздел 4).

В дополнение отметим, что использование в тексте отдельных символов CR или LF (не в комбинации <CRLF>) имеет долгую историю проблем в реализациях почтовых систем и приложениях, работающих с электронной почтой. Для клиентов SMTP недопустима передача этих символов за исключением тех случаев, когда комбинация символов служит для завершения строки, а в этом случае должна применяться только стандартная последовательность <CRLF>.

2.3.9. Содержимое сообщения и почтовые данные

Термины «содержимое сообщения» (message content) и «почтовые данные (mail data) в этом документе являются взаимозаменяемыми и служат для обозначения информации, передаваемой после восприятия команды DATA до завершения передачи. Содержимое сообщения включает заголовки и (возможно структурированное) тело сообщения. Спецификация MIME (RFC 2045 [21]) обеспечивает стандартные механизмы структурирования тела сообщений.

2.3.10. Отправитель, система доставки, транслятор, шлюз

В данной спецификации различаются четыре типа систем SMTP на основе выполняемых ими функций передачи электронной почты. Система-отправитель (SMTP originator) вносит сообщение в Internet или, в более общем случае, в среду транспортного сервиса. Система доставки (delivery) SMTP принимает почту от транспортного сервиса и передает ее пользовательскому почтовому агенту или размещает в хранилище сообщений, из которого пользовательский агент может взять почту впоследствии. Транслятор (relay) SMTP получает почту от клиента SMTP и передает ее другому серверу SMTP (для доставки или следующей трансляции) без изменения данных, добавляя лишь трассировочную информацию в заголовок.

Шлюзами (gateway) SMTP называют системы, получающие почту от клиентов из одной транспортной среды и передающие ее серверу другой среды. Различия в протоколах и семантике сообщения по разные стороны шлюза могут потребовать преобразования, которое не может быть выполнено трансляторами SMTP. В контексте данной спецификации межсетевые экраны (firewall), переписывающие адреса, следует рассматривать как шлюзы, даже если по обе стороны экрана используется среда SMTP (см. RFC 2979 [27]).

2.3.11. Почтовый ящик и адрес

В данной спецификации термин «адрес» означает текстовую строку, идентифицирующую пользователя, которому предназначено сообщение, или место, в котором почта будет сохранена. Термин «почтовый ящик» (mailbox) обозначает место хранения почты. Обычно эти термины взаимозаменяемы, если не имеет значения разница между местом хранения почты (почтовый ящик) и ее конкретным получателем (адрес). Адрес обычно состоит из пользовательской и доменной части. Стандартные соглашения об именах почтовых ящиков предполагают использование формата local-part@domain — современная терминология поддерживает значительно более широкий спектр применений, нежели просто имена пользователей. По этой причине, а также в результате исторической проблемы, связанной с попытками промежуточных хостов менять локальную часть адреса в целях оптимизации, эта часть адреса должна интерпретироваться только хостом, указанным в доменной части адреса.

2.4. Общие синтаксические принципы и модель транзакции

Команды и отклики SMTP подчиняются жестким синтаксическим правилам. Все команды начинаются с «командного глагола» (command verb), а все отклики – с 3-значного цифрового кода. В некоторых командах и откликах за командой или кодом должны следовать аргументы. Некоторые команды не принимают аргументов (после команды), а за некоторыми кодами откликов может следовать произвольный текст. Во всех случаях присутствия текста он отделяется от команды или кода символом пробела. Полные описания команд и откликов приведены в разделе 4.

Регистр символов в командах и значениях аргументов не имеет значения (т. е., TO: и to: в команде RCPT не различаются), однако это правило имеет исключения для локальной части названия почтового ящика (расширения SMTP могут явно указывать чувствительные к регистру символов элементы). Команды, значения аргументов (кроме локальной части имени почтового ящика) и свободный текст могут содержать произвольную комбинацию символов верхнего и нижнего регистра. Для локальной части имен почтовых ящиков регистр символов должен приниматься во внимание. Следовательно, реализации SMTP должны пытаться сохранить регистр символов в локальной части имени почтового ящика. В частности, для некоторых хостов пользователь smith может отличаться от пользователя Smith. Однако использование чувствительных к регистру локальных частей в именах почтовых ящиков снижает уровень взаимодействия – следует избегать такого применения локальных имен. Домены в почтовых адресах соответствуют обычным правилам DNS и, следовательно, не чувствительны к регистру символов.

Некоторые серверы SMTP в нарушение данной спецификации (и RFC 821) требуют от клиентов представления команд в верхнем регистре. В реализациях могут приниматься меры для представления команд в соответствии с требованиями таких серверов.

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

Синтаксис каждой команды рассматривается ниже вместе с описаниями команд. Общие элементы и параметры рассмотрены в параграфе 4.1.2.

Команды и отклики состоят из символов ASCII [6]. Когда транспортный сервис обеспечивает 8-битовый (байты или октеты) канал передачи, каждый 7-битовый символ передается с выравниванием по правому краю (старший бит октета имеет нулевое значение). Стандартный сервис SMTP обеспечивает поддержку только 7-битовых символов. Клиенту-отправителю SMTP, который не смог согласовать подходящее расширение с сервером (см. следующий параграф), недопустимо передавать сообщения, содержащие информацию в старших битах октетов. Если в нарушение этого правила такое сообщение передается, принимающий сервер SMTP может сбросить старший бит или отвергнуть сообщение как некорректное. В общем случае транслятору SMTP следует предполагать, что содержимое принятого сообщения корректно и, в предположении что конверт позволяет это сделать, транслировать сообщение без проверки его содержимого. Конечно, если содержимое некорректно и путь передачи не может его воспринять, такое решение может привести к доставке конечному адресату искаженного сообщения. Системы доставки SMTP могут отвергать такие сообщения или возвращать их, как недоставляемые, вместо попытки доставки. В отсутствии предлагаемого сервером расширения, явно позволяющего делать это, никаким передающим системам SMTP не дозволяется передавать envelope-команды, содержащие символы, не включенные в набор US-ASCII; принимающим системам следует отвергать такие команды, используя стандартный отклик 500 syntax error — invalid character.

Клиент может запросить у сервера передачу 8-битового содержимого сообщений с использованием расширенных возможностей SMTP, прежде всего 8BITMIME RFC 1652 [22]. Серверам SMTP следует поддерживать режим 8BITMIME. Однако это недопустимо трактовать, как разрешение на неограниченную передачу 8-битовых символов и не позволяет передавать в конвертах сообщений символы, отличные от ASCII. Для отправителя недопустимо запрашивать режим 8BITMIME при передачи данных, где в качестве старшего бита не используется соответствующий формат MIME с подходящим транспортным кодирование; серверы могут отвергать такие сообщения.

Используемая в этом документе металингвистическая нотация соответствует нотации Augmented BNF, принятой в документах других почтовых систем Internet. Читателям, которые незнакомы с этим синтаксисом, следует прочесть спецификацию ABNF в RFC 5234 [7]. Для ясности термины метаязыка, используемые в тексте, обозначены угловыми скобками (например, <CRLF>). Читателям следует отдавать отчет в том, выражения метаязыка могут быть неполными. Имеется множество случаев, когда представленная в тексте информация ограничивает или иначе меняет синтаксис или семантику метаязыка.

3. Обзор процедур SMTP

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

3.1. Инициирование сеанса

Сеанс SMTP инициируется, когда клиент соединяется с сервером и сервер отвечает соответствующим сообщением.

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

Протокол SMTP позволяет серверу формально отвергать транзакцию, не запрещая изначальные соединения: код 554 может возвращаться в открывающем сообщении взамен кода 220. Сервер, использующий такой вариант, должен по-прежнему ждать, пока клиент передаст команду QUIT (см. параграф 4.1.1.10) перед закрытием соединения, а на любую мешающую команду следует возвращать отклик 503 bad sequence of commands (некорректная последовательность команд). Поскольку попытка организации SMTP-соединения с такими системами может приводить к ошибке, серверу, возвращающему код 554, следует передавать вместе с кодом информацию, которая позволит передающей системе понять причину ошибки.

3.2. Инициирование клиента

После того, как сервер передал приглашающее сообщение (приветствие) и клиент получил его, последний обычно передает серверу команду EHLO, идентифицирующую клиента. В дополнение к открытию сеанса использование EHLO показывает, что клиент способен работать с расширенным сервисом и запрашивает у сервера список поддерживаемых им расширений. Старые системы SMTP, не способные поддерживать расширения сервиса, и современные клиенты, которым не требуется расширенный сервис в инициируемом почтовом сеансе, могут использовать HELO взамен EHLO. Для серверов недопустимо возвращать расширенные отклики в стиле EHLO в ответ на команду HELO. Для конкретной попытки соединения, если сервер возвращает отклик command not recognized (команда не распознана) на команду EHLO, клиенту следует начать процесс заново и передать команду HELO.

Хост, передающий команду EHLO, идентифицирует в ней себя; команду можно интерпретировать как Hello, I am <domain> (Привет, я домен …), а для случая EHLO – and I support service extension requests (и я поддерживаю расширения …).

3.3. Почтовые транзакции

Почтовая транзакция SMTP состоит из трех этапов. Началом транзакции служит команда MAIL, дающая идентификацию отправителя (в общем случае команда MAIL может быть введена только при отсутствии незавершенных почтовых транзакций; см. параграф 4.1.4.). После этого следует одна или несколько команд RCPT, указывающих получателей сообщения. Последний этап транзакции начинается командой DATA, которая инициирует передачу почтовых данных и завершается индикатором end of mail, который также подтверждает транзакцию.

Первым этапом транзакции является команда MAIL.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

Эта команда говорит получателю SMTP о начале новой почтовой транзакции и сбрасывает все таблицы состояний и буферы, включая любые данные получателя или почтовые данные. Часть <reverse-path> (обратный путь) первого или единственного аргумента команды содержит название почтового ящика отправителя (между скобками < и >), которое может использоваться для передачи отчетов об ошибках (см. параграф 4.2). Восприняв команду, сервер SMTP возвращает отклик 250 OK. Если указанный почтовый ящик по каким-то причинам неприемлем, сервер должен возвратить отклик, показывающий временной тип отказа – постоянная (т. е., повторится при повторе команды клиентом) или временная (т. е., адрес клиента может быть принят при следующем вызове) ошибка. Несмотря на очевидность этого требования, существуют обстоятельства, при которых возможность восприятия обратного пути невозможно определить, пока не будет получен по крайней мере один прямой путь (в команде RCPT). В таких случаях сервер может воспринять обратный путь (отклик 250) и сообщить о возникновении проблем после получения и проверки прямых путей. Обычно это делается с помощью откликов 550 или 553.

Исторически <reverse-path> может содержать больше данных, нежели просто имя почтового ящика, но современным системам не следует использовать маршрутизацию почты отправителем — source routing (см. Приложение C).

Дополнительные параметры <mail-parameters> связываются с согласованным расширением сервиса SMTP (см. 2.2).

Вторым этапом транзакции является команда RCPT. Данный этап может повторяться много раз.

RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

Первый или единственный аргумент этой команды включает прямой путь forward-path (обычно имя почтового ящика и домена, обязательно заключенные в скобки <>), идентифицирующий получателя. Восприняв команду, сервер SMTP возвращает отклик 250 OK и сохраняет прямой путь. Если известно, что почта не может быть доставлена адресату, сервер SMTP возвращает отклик 550, обычно сопровождаемый строкой типа «no such user — » с именем почтового ящика, для которого невозможна доставка (возможны также другие обстоятельства и коды возврата).

Параметр <forward-path> может содержать не только адрес получателя. Исторически <forward-path> может включать маршрут (source routing) к получателю в виде списка промежуточных хостов, однако современным клиентам SMTP не рекомендуется использовать маршрутизацию почты отправителем (см. Приложение C). Сервер должен быть готов к восприятию списка source route в прямом пути, но рекомендуется игнорировать эти маршруты и можно отклонять предлагаемую таким маршрутом трансляцию. Подобно этому, сервер может отказаться от приема почты, предназначенной для других хостов или систем. Эти ограничения делают сервер бесполезным в качестве транслятора для клиентов, не полностью поддерживающих функциональность SMTP. Следовательно, для клиентов с ограниченными возможностями недопустимо предполагать, что любой SMTP-сервер в Internet можно использовать для обработки (трансляции) почты. Если команда RCPT принята без предшествующей команды MAIL, сервер должен возвращать отклик 503 Bad sequence of commands¹². Дополнительные параметры <rcpt-parameters> связываются с согласованным расширением сервиса SMTP (см. параграф 2.2).

Поскольку такая ошибка встречается достаточно часто, подчеркнем, что не допускается включение пробелов с любой стороны от знака двоеточия (:) после FROM в команде MAIL или после TO в команде RCPT. Точный синтаксис показан выше.

Третьим этапом транзакции является команда DATA (или соответствующая команда протокольного расширения).

DATA <CRLF>

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

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

Индикатор завершения почтовых данных также подтверждает почтовую транзакцию и говорит серверу SMTP, что нужно обрабатывать сохраненные пользовательские и почтовые данные. Восприняв данные, сервер SMTP возвращает отклик 250 OK. Сбой при обработке команды DATA может происходить только на двух этапах обмена данными.

Если команды MAIL и RCPT не были введены или были отвергнуты, сервер может возвращать отклик command out of sequence (503) или no valid recipients (554 – нет корректных получателей) в ответ на команду DATA. При получении одного из таких откликов (или любого отклика 5yz) для клиента недопустима передача данных серверу (точнее, передача данных недопустима, пока не будет получен отклик 354).

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

Однако на практике некоторые серверы не проверяют адресата после приема текста сообщения. Таким серверам следует трактовать отказ для одного или нескольких получателей как «отказ обусловленный другим отказом» (subsequent failure) и возвращать почтовое сообщение, как указано в главе 6 и, в частности, в параграфе 6.1. Использование отклика 550 mailbox not found (или его эквивалента) после восприятия данных делает для клиента сложной или невозможной диагностику причины отказа.

При использовании формата RFC 822 ([28], [4]) почтовые данные включают элементы заголовка, такие как Date, Subject, To, Cc, From¹³. Серверам SMTP не рекомендуется отвергать сообщения на основе дефектов в заголовках RFC 822 и MIME (RFC 2045 [21]) или в теле сообщения. В частности, недопустимо отвергать сообщения, в которых число полей Resent не соответствует или Resent-to появляется без Resent-from и/или Resent-date.

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

3.4. Пересылка для коррекции и обновления адресов

Поддержка пересылки чаще всего требуется для консолидации адресов и упрощения адресации в сети предприятия (или применительно к такой сети) и реже для случаев изменения адресов. Пересылка без уведомления отправителя (Silent forwarding) в целях обеспечения безопасности или сокрытия внутренней структуры весьма распространена сегодня в Internet.

В обоих перечисленных случаях приходится решать вопрос сокрытия (в некоторых случаях – безопасности) информации – следует ли показывать отправителю данные о пересылке почты. Это может быть особо важным, когда конечный адресат просто недоступен для отправителя. Следовательно, механизм пересылки, описанный в параграфе 3.2 RFC 821 и особенно строки откликов 251 (скорректированный получатель) и 551 на команду RCPT должны осторожно оцениваться при разработке и, когда это возможно, при настройке конфигурации системы (см. также параграф 7.4).

В частности:

• Сервер может пересылать сообщения, когда ему известно об изменении адреса. При такой пересылке сервер может предоставлять сведения о смене адреса с кодом 251 или «по-тихому» пересылать сообщение, возвращая код 250. При использовании кода 251 недопустимо предполагать, что клиент будет обновлять информацию об адресе получателя на основе принятого от сервера отклика.

Или:

• Сервер может отвергнуть или «завернуть» сообщения, когда их невозможно доставить по указанному адресу. В таких случаях сервер может сообщить о смене адреса в отклике 551 или отвергнуть сообщение как недоставляемое с кодом 550 без дополнительных сведений. При использовании кода 551 недопустимо предполагать, что отправитель будет обновлять адрес на основе полученных сведений или доводить эту информацию до пользователя.

Реализациям серверов SMTP, поддерживающим отклики с кодами 251 и/или 551, следует обеспечивать конфигурационный механизм, позволяющий отключить или ограничить дополнительную информацию для сайтов, которые могут использовать ее нежелательным способом.

3.5. Команды для отлаживания адресов

3.5.1. Обзор

Протокол SMTP обеспечивает команды для проверки имен пользователей или получения содержимого списков рассылок. Такие операции осуществляются с помощью команд VRFY и EXPN, которые получают текстовые строки в качестве аргументов. Реализациям следует поддерживать команды VRFY и EXPN (особенности использования этих команд рассмотрены в параграфах 3.5.2 и 7.3).

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

User Name <local-part@domain>
local-part@domain

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

553 User ambiguous

или

553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>

или

553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>

При нормальных условиях предполагается, что клиент, получивший отклик 553, доведет эту информацию до пользователя. Использование приведенных здесь форм и ключевых слов user ambiguous (пользователя не определить однозначно) или ambiguous (неоднозначность), возможно дополненных расширенными кодами отклика (типа рассмотренных в RFC 3463 [25]), помогает при необходимости обеспечивать автоматический перевод на другие языки. Клиенты с высоким уровнем автоматизации и поддержкой других языков могут попытаться перевести отклик, возвратить пользователю нестандартную индикацию или предпринять некоторые автоматические операции типа обращения к службе каталогов для получения дополнительных данных перед возвратом отклика пользователю.

Для команды EXPN строка параметров идентифицирует список рассылки и при успешном выполнении команды возвращается отклик 250, который может включать полные имена пользователей и должен включать имена почтовых ящиков из списка.

На некоторых хостах различия между списками рассылок и псевдонимами выражены весьма слабо, поскольку оба типа записей могут сохраняться в единой структуре данных и возможны списки рассылок, содержащие единственный адрес. Если дается запрос на применение команды VRFY к списку рассылок, позитивный отклик может быть возвращен, если направленное по адресу списка сообщение может быть доставлено кому-либо из списка, в остальных случаях следует возвращать сообщение об ошибке (например, отклик 550 That is a mailing list, not a User¹⁴ или 252 Unable to verify members of mailing list¹⁵). Если делается запрос имени пользователя из списка, сервер может давать позитивный отклик, содержащий список из одного имени, или сообщение об ошибке (например, 550 That is a user name, not a mailing list¹⁶).

При успешном выполнении возвращаемый многострочный отклик (обычный для EXPN) содержит имя одного почтового ящика в каждой строке. Ситуации с неоднозначными запросами были рассмотрены выше.

Термин User name (имя пользователя) является недостаточно четким и должен использоваться осмотрительно. Реализации команд VRFY и EXPN должны, по крайней мере, распознавать локальные почтовые ящики, как имена пользователей. Однако в сети Internet зачастую один хост обслуживает почту для множества доменов и хостам (особенно тем, которые работают с разными доменами) следует обеспечивать такую функциональность и воспринимать форму local-part@domain, как имя пользователя; хосты также могут распознавать, как имена пользователей, строки других типов.

Случай получения имен почтовых ящиков из списка рассылок требует многострочных откликов типа приведенного ниже (C – клиент, S – сервер; прим. перев.):

C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>

или

C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.

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

3.5.2. Нормальные отклики VRFY

Когда возвращается нормальный код (2yz или 551) в результате запроса VRFY или EXPN, отклик должен включать имя почтового ящика в формате <local-part@domain>, где domain является полным доменным именем (FQDN). В ситуациях, исключающих нарушение требований данной спецификации, может возвращаться текстовая строка произвольной формы. Для облегчения анализа и разделения имени почтового ящика и данных человека (или компании) адрес следует выводить в угловых скобках. При возврате адресов (а не произвольной текстовой строки) команды EXPN и VRFY должны возвращать только корректные значения доменной части адреса, которые можно использовать в команде RCPT. Следовательно, если адрес может передаваться программе или другой системе, должно указываться имя почтового ящика, используемого для доступа к адресату. Возврат путей (явные маршруты source route) для команд VRFY и EXPN недопустим.

Реализациям серверов следует поддерживать обе команды VRFY и EXPN. В целях безопасности может обеспечиваться локальная возможность отключить любую из этих команд (или обе) с помощью конфигурационных параметров. Когда эти команды поддерживаются, не требуется обеспечивать их работу через трансляторы, если трансляция разрешена. Обе эти команды были необязательными в спецификации RFC 821, но команда VRFY стала обязательной в RFC 1123 [3]. Если команда EXPN поддерживается, она должна быть указана как расширение сервиса в отклике EHLO. VRFY можно указывать удобным способом, но в силу обязательности ее поддержки, клиенты SMTP не обязаны проверять наличие этой команды в списке расширений перед началом ее использования.

3.5.3. Значения откликов при успешном завершении VRFY или EXPN

Для серверов недопустим возврат откликов 250 на команды VRFY и EXPN, пока адрес реально не проверен. В частности, для сервера недопустимо возвращать код 250, если его действия ограничились проверкой корректности синтаксиса. В таких случаях следует возвращать код 502 (команда не реализована) или 500 (синтаксическая ошибка, команда не распознана). Как было указано, реализация (в смысле проверки адресов и возврата информации) команд VRFY и EXPN настоятельно рекомендуется. Следовательно, реализации, возвращающие код 500 или 502 для команды VRFY не являются полностью совместимыми с данной спецификацией.

Существуют ситуации, когда адрес представляется корректным, но не может быть проверен в реальном масштабе времени (в частности, когда сервер используется при обмене почтой для другого сервера или домена). «Видимая корректность» (Apparent validity) в таких случаях будет включать, по крайней мере, проверку синтаксиса и может также включать проверку возможности трансляции для указанного адреса. В таких случаях следует возвращать код 252. Эти ситуации связаны с вопросами проверки RCPT, рассмотренными в параграфе 2.1. Аналогично ситуации, описанной в 3.4, коды 251 и 551 могут использоваться для команд VRFY и EXPN, чтобы показать адреса, которые распознаны, но почта для них будет пересылаться или отвергаться. Реализациям в общем случае следует быть более жесткими в вопросах проверки адресов для случая VRFY, нежели для команды RCPT, даже если это будет занимать немного больше времени.

3.5.4. Семантика и использование EXPN

Команда EXPN зачастую очень полезна для отладки и поиска проблем, связанных со списками рассылок и псевдонимами ко множеству адресов (multiple-target-address alias). Некоторые системы пытаются использовать поиск отправителя в списке рассылки для предотвращения дубликатов. Распространение системы псевдонимов с почтой в Internet для хостов (обычно записи MX и CNAME на серверах DNS), почтовых ящиков (различные типы локальных псевдонимов хоста) и в различных proxy-системах делает почти невозможной стратегию согласованного использования псевдонимов и почтовым системам не следует пытаться решить эту задачу.

3.6. Трансляция и маршрутизация почты

3.6.1. Маршрутизация, заданная отправителем, и трансляция

В общем случае доступность записей MX в DNS (RFC 1035 [2], RFC 974 [12]) избавляет от необходимости использования явно заданных маршрутов в почтовой системе Internet. С явной маршрутизацией почты связано множество проблем, делающих такое использование совершенно нежелательным. Клиентам SMTP не следует генерировать явные маршруты source route за исключением особых ситуаций. Серверы SMTP могут отказывать в трансляции или не воспринимать сообщения с указанным отправителем маршрутом. Обнаружив маршрутную информацию, сервер SMTP может игнорировать ее и просто переслать почту конечному адресату, указанному в последнем элементе заданного маршрута, — серверам следует поступать именно так. Встречаются случаи некорректного использования имен адресатов, отсутствующих в записях DNS, с использованием преобразования имен на промежуточных хостах, указанных в маршруте source route. При исключении (игнорировании) заданного отправителем маршрута в таких случаях возникают проблемы. Это одна из нескольких причин, по которым для клиентов SMTP недопустима генерация некорректных маршрутов source route или путей, зависящих от последовательного преобразования имен.

Когда заданные отправителем маршруты не используются, процесс, описанный в RFC 821 для конструирования обратного пути из прямого, неприменим и обратный путь во время доставки будет просто адресом, указанным в команде MAIL.

3.6.2. Записи MX и трансляция

Транслирующий сервер SMTP обычно определяется из записи MX и не является системой окончательной доставки почты. Такой сервер может принимать или отвергать трансляцию почты аналогично восприятию или отказу для почты локальных пользователей. Если сервер принял трансляцию, от становится клиентом SMTP, организуя канал передачи следующему серверу SMTP, указанному в DNS (в соответствии с правилами, описанными в разделе 5), и передает ему почту. Если сервер отвергает трансляцию почты для какого-либо адреса, ему следует возвращать отклик 550.

В данной спецификации не рассматриваются вопросы верификации путей возврата для передачи уведомлений о доставке. В последнее время были выполнены работы (такие, как SPF [29] и DKIM [30] [31]) по обеспечению способов проверки корректности адресов возврата и их принадлежности лицу, действительно отправившему сообщение. Сервер может попытаться проверить путь возврата перед использованием этого адреса для передачи уведомления о доставке, однако здесь не определяются способы такой проверки и не дается рекомендация по выбору способа проверки.

3.6.3. Серверы представления сообщений как трансляторы

Существует множество клиентов, передающих почту (часто эти же программы служат для приема почты по протоколу POP3 или IMAP), которые не обеспечивают полную поддержку данной спецификации (например, поддержка очередей для последующей передачи). Для таких клиентов обычной практикой является организация частного соглашения с сервером для отправки ему всей почты с целью последующей обработки и доставки. Как указано здесь, SMTP не является идеальным решением для таких задач. Разработан стандартизованный протокол представления почтовых сообщений (RFC 4409 [18]), учитывающий опыт использования систем SMTP. В любом случае, частный характер соглашения между сервером и клиентами выводит этот вопрос за пределы данной спецификации.

Важно отметить, что записи MX могут указывать на серверы SMTP, которые действуют как шлюзы в другие среды, а не только выполняют трансляцию и окончательный прием почты (см. параграф 3.8 и раздел 5).

Если сервер SMTP принял на себя задачу трансляции почты и позднее обнаружил, что получатель указан некорректно или почту невозможно доставить по тем или иным причинам, этот сервер должен создать уведомление о невозможности доставки почты и переслать его отправителю недоставленного сообщения, указанному в обратном пути. Для уведомления следует (по возможности) использовать стандартные форматы (см., например RFC 3461 [32] и RFC 3464 [33]).

Это уведомление должно передаваться сервером SMTP с хоста-транслятора или хоста, который обнаружил невозможность доставки. Естественно, что для серверов SMTP недопустима отправка уведомлений о невозможности доставки уведомлений¹⁷. Одним из способов предотвращения петель при передаче сообщений об ошибках является использование пустой строки обратного пути в команде MAIL при передаче уведомления. При передаче такого сообщения строка обратного пути должна быть пустой – null (см. параграф 4.5.5). Команда MAIL с пустым обратным путем имеет вид:

MAIL FROM:<>

Как указано в параграфе 6.4, транслятору SMTP не нужно проверять и обрабатывать заголовки и тело транслируемых сообщений, а также недопустимо предпринимать какие-либо любые действия по отношению к сообщению, за исключением добавления к заголовку строки Received: (см. параграф 4.4) и (необязательной) попытки обнаружения петель в почтовой системе (см. параграф 6.3). Естественно, запрет распространяется и на изменение любых полей заголовка и текста сообщения (см. также параграф 7.9).

3.7. Почтовые шлюзы

Описанные выше трансляторы работают в транспортной среде Internet SMTP, однако записи MX и разные формы явной маршрутизации могут потребовать использования промежуточных серверов SMTP, которые будут обеспечивать преобразование почты между различными транспортными системами. Как было отмечено в параграфе 2.3.10, такие системы, работающие на границах между двумя системами транспортного сервиса, называются шлюзами или почтовыми шлюзами¹⁸.

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

3.7.1. Поля заголовка при использовании шлюзов

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

Другие почтовые системы при передаче сообщений в Internet часто используют подмножество заголовков RFC 822 или обеспечивает похожую функциональность с использованием другого синтаксиса, но некоторые из таких почтовых систем не имеют эквивалента конвертов SMTP. Следовательно, когда сообщение покидает почтовую среду Internet, может потребоваться включение информации из конверта SMTP в заголовок сообщения. Возможным решением будет создание новых полей заголовка для передачи информации из конверта (например, X-SMTP-MAIL: и X-SMTP-RCPT:). Однако такое решение потребует изменения почтовых программ в чужой среде и может привести к разглашению частной информации (см. параграф 7.2).

3.7.2. Строки Received при использовании шлюзов

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

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

Шлюзу следует указывать среду и протокол в поле via строки Received, создаваемый шлюзом.

3.7.3. Адресация при использовании шлюзов

Со стороны Internet шлюзу следует воспринимать все корректные форматы адресов в командах SMTP и заголовках RFC 822, а также все корректные сообщения RFC 822. Генерируемые шлюзом адреса и заголовки должны соответствовать применимым стандартам Internet (включая данную спецификацию и RFC 5322 [4]). Шлюзы подчиняются тем же правилам обработки маршрутов source route, которые описаны в параграфе 3.3 для других систем SMTP.

3.7.4. Другие поля заголовков при использовании шлюзов

Шлюз должен обеспечивать соответствие требованиям Internet всех полей заголовков в сообщениях, передаваемых в почтовую среду Internet. В частности, все адреса в полях From:, To:, Cc: и т. п. должны преобразовываться (если нужно) в соответствии с синтаксисом RFC 5322 [4], должны указывать только полные доменные имена и должны быть эффективны и полезны для передачи откликов. Алгоритму, используемому для преобразования почты Internet в другие форматы, следует обеспечивать доставку сообщений об ошибках из чужой почтовой среды по пути возврата в конверте SMTP, а не отправителю, указанному в поле From:, Sender: (или других полях) заголовка сообщения.

3.7.5. Конверты при работе со шлюзами

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

3.8. Прерывание сеансов и соединений

Соединение SMTP разрывается при получении от клиента команды QUIT. Сервер возвращает в ответ на эту команду позитивный отклик и закрывает соединение.

Для серверов SMTP недопустимо преднамеренно закрывать соединения в нормальных условиях (см. параграф 7.8) за исключением следующих ситуаций:

• После получения команды QUIT и отклика на нее с кодом 221.
• После определения необходимости отключения (shut down) сервиса SMTP и возврата кода 421. Такой отклик может выдаваться после получения сервером любой команды или (при необходимости) асинхронно (независимо от команд) в предположении, что клиент будет получать отклик после ввода следующей команды.

• После тайм-аута (см. параграф 4.5.3.2) в процессе ожидания от клиента команды или данных.

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

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

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

3.9. Почтовые списки и псевдонимы

Хостам SMTP следует поддерживать как псевдонимы, так и списки для преобразования адресов при групповой рассылке сообщений. Когда сообщение доставляется или пересылается по каждому адресу из списка, адрес возврата в конверте (MAIL FROM:) должен заменяться на адрес администратора списка. Однако в таких случаях заголовок сообщения (RFC 5322 [4]) должен сохраняться неизменным; в частности, не должно меняться поле From.

Одним из важных свойств почтовой системы является механизм доставки одного сообщения множеству адресатов за счет преобразования (expanding или exploding) псевдоадреса в список реальных адресов получателей. Когда сообщение направляется по такому псевдоадресу (иногда его называют exploder), копия этого сообщения пересылается по каждому адресу из списка. Серверу следует просто использовать адреса из списка, применение эвристики или проверки соответствия для исключения некоторых адресов (например, отправителя исходного сообщения) настоятельно не рекомендуется. Псевдоадреса называют списками (list, mail list) или псевдонимами (alias) в зависимости от способа получения адресов из списка.

3.9.1. Псевдонимы

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

3.9.2. Списки

Почтовые списки обеспечивают перераспределение (redistribution), а не пересылку (forwarding) сообщений. Для преобразования списка почтовая программа-получатель заменяет в конверте псевдоадрес реальными адресами из списка. Адрес возврата в конверте заменяется так, чтобы все сообщения об ошибках приходили по адресу администратора списка (не отправителя сообщения), который обычно контролирует содержимое списков и доставку. Отметим, что основное различие между обработкой псевдонимов (параграф 3.9.1) и списков (данный параграф) заключается в изменении адреса возврата при рассылке по списку. Хотя списки ограничивают набор операций обработки описанными здесь действиями, они являются попыткой эмуляции АДП (MTA); такие списки можно рассматривать как продолжение процедур транзита почты.

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

4. Спецификации SMTP

4.1. Команды SMTP

4.1.1. Синтаксис и семантика команд

Команды SMTP определяют передачу почты и функции почтовой системы, запрашиваемые пользователем. Команды представляют собой текстовые строки, завершающиеся последовательностью <CRLF>. Команда, как таковая, представляет собой строку букв, завершаемую пробелом <SP> (при наличии параметров) или <CRLF>. В целях повышения уровня взаимодействия получателям SMTP следует быть терпимыми к пробелам перед завершающей последовательностью <CRLF>. Синтаксис локальной части имени почтового ящика соответствует соглашениям принимающего сайта и синтаксису, описанному в параграфе 4.1.2. Команды SMTP обсуждаются ниже, а рассмотрению откликов посвящен параграф 4.2.

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

Некоторые команды (RSET, DATA, QUIT) не поддерживают параметров. В отсутствие специфических расширений, предлагаемых сервером и принимаемых клиентом, для последних недопустимо передавать параметры таким командам, а серверу следует отвергать команды, как в случае некорректного синтаксиса.

4.1.1.1. Расширенное (EHLO) или стандартное (HELO) приветствие

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

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

Сервер SMTP представляет себя клиенту в данном соединении с помощью отклика на команду приветствия.

Клиентам SMTP следует начинать сессию SMTP с помощью команды EHLO. Если сервер SMTP поддерживает расширенные службы SMTP, он будет передавать позитивный отклик, сообщение об отказе или сообщение об ошибке. Если сервер SMTP (в нарушение данной спецификации) не поддерживает никаких расширений SMTP, он будет генерировать сообщение об ошибке. Старые клиенты SMTP могут (как обсуждалось выше) использовать команду HELO (в соответствии с RFC 821) взамен EHLO, а серверы должны поддерживать команды HELO и давать на них правильный отклик. В любом случае клиент должен использовать команду HELO или EHLO до начала почтовой транзакции.

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

Синтаксис:

ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF

Обычно в ответ на команду EHLO возвращается многострочный отклик, каждая строка которого содержит ключевое слово и может включать один или несколько параметров. В соответствии с требованиями к нормальному синтаксису многострочных откликов ключевые слова следуют после кода 250 и дефиса (для всех строк, кроме последней) или пробела (в последней строке). Ниже приведен пример позитивного отклика с использованием нотации ABNF и символов завершения из RFC 5234 [7]:

   ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
                    / ( "250-" Domain [ SP ehlo-greet ] CRLF
                    *( "250-" ehlo-line CRLF )
                    "250" SP ehlo-line CRLF )
   ehlo-greet     = 1*(%d0-9 / %d11-12 / %d14-127)
                    ; строка любых символов, кроме CR и LF

   ehlo-line      = ehlo-keyword *( SP ehlo-param )

   ehlo-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
                    ; дополнительный синтаксис ehlo-params зависит от ehlo-keyword

   ehlo-param     = 1*(%d33-126)
                    ; любые символы, включая <SP> и все коды управления (US-ASCII 0-31 и 127,
                    ; включительно)

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

Отклик на команду EHLO должен включать ключевые слова (и связанные с ними параметры при наличии последних) для всех команд, не перечисленных как «обязательные» в параграфе 4.5.1, за исключением команд для приватного использования, описанных в параграфе 4.1.5. Команды для приватного использования также можно включать в список.

4.1.1.2. Начало транзакции (MAIL)

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

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

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

Если согласовано использование расширенного сервиса, команда MAIL может содержать дополнительные параметры.

Синтаксис:

mail = "MAIL FROM:" Reverse-path [SP Mail-parameters] CRLF

4.1.1.3. Получатель (RCPT)

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

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

Подобно этому, трансляторам следует пропускать или игнорировать source route, а имена недопустимо копировать в поле обратного пути. Когда почта приходит к конечному адресату (прямой путь содержит только почтовый ящик получателя), сервер SMTP помещает сообщение в почтовый ящик адресата в соответствии с принятыми соглашениями.

Эта команда добавляет свой аргумент forward-path в буфер прямого пути, не меняя содержимого буферов обратного пути и почтовых данных.

Например, почта, полученная транслятором xyz.com и содержащая в конверте команды:

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

обычно будет пересылаться непосредственно на хост d.bar.org с командами в конверте:

MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>

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

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

или (для трансляции через jkl.org):

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>

Попытки такого использования трансляторов в настоящее время осуждаются. Поскольку хосты не обязаны транслировать почту, xyz.com может отвергнуть сообщение при получении команды RCPT, используя отклик 550 (отказ в соответствии с используемыми правилами).

Если согласовано использование расширенного сервиса, команда RCPT может также включать параметры, связанные с конкретным типом расширения, предлагаемого сервером. Для клиента недопустима передача параметров, кроме тех, которые связаны с расширением, предложенным сервером в отклике EHLO.

Синтаксис:

rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>"
/ Forward-path ) [SP Rcpt-parameters] CRLF

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

4.1.1.4. Данные (DATA)

Получатель обычно возвращает отклик 354 на команду DATA и после этого трактует дальнейшие строки (символьные последовательности, завершающиеся <CRLF>, как сказано в параграфе 2.3.7), как почтовые данные от отправителя. Эта команда добавляет почтовые данные в конец буфера данных. Данные могут включать любые из 128 символов ASCII, хотя опыт показывает, что использование управляющих символов (кроме SP, HT, CR, LF) может вызывать проблемы, поэтому следует избегать таких символов.

Данные завершаются строкой, содержащей только точку и последовательность завершения строки (в потоке символов это будет <CRLF>.<CRLF>, см. параграф 4.5.2). Такая последовательность символов указывает на завершение потока данных. Первая последовательность <CRLF> на самом деле завершает последнюю строку почтовых данных (текста сообщения) или (при отсутствии данных) – командную строку DATA (случай отсутствия данных не соответствует этой спецификации, поскольку он требует, чтобы не передавалось ни трассировочных полей заголовка, ни заголовка сообщения, требуемых RFC 5322 [4]). Недопустимо добавление лишних последовательностей <CRLF>, поскольку это будет приводить к вставке пустой строки в сообщение. Единственным исключением из этого правила является обработка сообщений, переданных исходному отправителю без завершающей последовательности <CRLF> в последней строке; в таких случаях отправляющая сообщение система SMTP должна отвергнуть сообщение как некорректное или добавить <CRLF> в конце, чтобы принимающий сервер SMTP смог зафиксировать условие end of data (конец сообщения).

Использование строк, завершающихся одиночным символом <LF>¹⁹, как это принято в некоторых UNIX-системах, порождает значительно больше проблем, нежели решает и для серверов SMTP такой подход недопустим, даже во имя повышения отказоустойчивости. В частности, последовательности <LF>.<LF> недопустимо трактовать как эквивалент последовательности <CRLF>.<CRLF> для завершения почтовых данных.

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

Когда сервер SMTP воспринимает сообщение для трансляции или окончательной доставки, он помещает трассировочную запись, которую также называют time stamp line (строка с временной меткой) или Received в верхней части почтовых данных. Эта запись показывает хост, передавший сообщение, хост-приемник (сервер), а также дату и время приема сообщения. Транслируемые сообщения могут содержать на финальном этапе множество трассировочных записей. Детальное описание трассировки и синтаксиса записей приводится в параграфе 4.4.

Дополнительную информацию по обработке команд DATA можно найти в параграфе 3.3.

Синтаксис:

data = "DATA" CRLF

4.1.1.5. Сброс (RSET)

Эта команда служит для прерывания текущей почтовой транзакции. Все сохраненные в буферах данные должны быть отброшены с очисткой буферов и таблиц состояния. Принимающая сторона в ответ на команду RSET должна передать отклик 250 OK без дополнительных аргументов. Команду RSET клиент может вводить в любой момент транзакции. Эта команда является эквивалентом NOOP (не выполняется никаких действий) при введении сразу после EHLO, до первого использования EHLO в данном сеансе, после завершения и подтверждения передачи данных или непосредственно перед командой QUIT. Для серверов SMTP недопустимо закрывать соединение в результате получения команды RSET – для разрыва соединения служит команда QUIT (см. параграф 4.1.1.10).

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

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

Синтаксис:

rset = "RSET" CRLF

4.1.1.6. Проверка (VRFY)

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

Данная команда не воздействует на содержимое буферов обратного и прямого пути, а также буфера почтовых данных.

Синтаксис:

vrfy = "VRFY" SP String CRLF

4.1.1.7. Преобразование списка (EXPN)

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

Данная команда не воздействует на содержимое буферов обратного и прямого пути, а также буфера данных.

Синтаксис:

expn = "EXPN" SP String CRLF

4.1.1.8. Справка (HELP)

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

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

Серверам следует поддерживать команду HELP без аргументов и можно поддерживать команду с аргументами.

Синтаксис:

help = "HELP" [ SP String ] CRLF

4.1.1.9. Пустая операция (NOOP)

Эта команда не влияет на значения параметров и выполнение введенных ранее команд. По команде сервер просто передает отклик 250 OK.

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

Синтаксис:

noop = "NOOP" [ SP String ] CRLF

4.1.1.10. Завершение сеанса (QUIT)

Получив эту команду сервер должен возвратить отклик и 221 OK закрыть канал передачи.

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

Команда QUIT может быть введена в любой момент. Незавершенная почтовая транзакция прерывается.

Синтаксис:

quit = "QUIT" CRLF

4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses

Если сервер SMTP не распознает или не поддерживает один или более параметров конкретной команды MAIL FROM или RCPT TO, он будет возвращать код 555.

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

Ошибки, связанные с конкретными параметрами и их значениями, определяются в соответствующих RFC.

4.1.2. Синтаксис аргументов команд

Ниже приведен синтаксис полей аргументов перечисленных выше команд (по возможности, используется синтаксис, описанный в RFC 5234 [7]). Некоторые из приведенных ниже вариантов используются только с маршрутами source route, как описано в Приложении C. Обозначения, не определенные здесь (типа ALPHA, DIGIT, SP, CR, LF, CRLF), описаны в разделе 6 RFC 5234 [7] или при формальном определении синтаксиса сообщений в RFC 5322 [4].

   Reverse-path   = Path / "<>"
   Forward-path   = Path
   Path           = "<" [ A-d-l ":" ] Mailbox ">"
   A-d-l          = At-domain *( "," At-domain )
                  ; отметим, что эта форма, называемая source route, должна приниматься, 
                  ; ее не следует генерировать и следует игнорировать.
   At-domain      = "@" Domain
   Mail-parameters  = esmtp-param *(SP esmtp-param)
   Rcpt-parameters  = esmtp-param *(SP esmtp-param)
   esmtp-param    = esmtp-keyword ["=" esmtp-value]
   esmtp-keyword  = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
   esmtp-value    = 1*(%d33-60 / %d62-126)
                  ; любые символы кроме =, SP и управляющих кодов. Если эта строка 
                  ; представляет собой почтовый адрес (например, Mailbox), следует 
                  ; использовать синтаксис xtext [32].
   Keyword        = Ldh-str
   Argument       = Atom
   Domain         = sub-domain *("." sub-domain)
   sub-domain     = Let-dig [Ldh-str]
   Let-dig        = ALPHA / DIGIT
   Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig
   address-literal  = "[" ( IPv4-address-literal /
                    IPv6-address-literal /
                    General-address-literal ) "]"
                    ; см. параграф 4.1.3
   Mailbox        = Local-part "@" ( Domain / address-literal )
   Local-part     = Dot-string / Quoted-string
                  ; регистр символов может различаться
   Dot-string     = Atom *("."  Atom)
   Atom           = 1*atext
   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE
   QcontentSMTP   = qtextSMTP / quoted-pairSMTP
   quoted-pairSMTP  = %d92 %d32-126
                    ; т. е., обратная дробная черта, за которой следует символ 
                    ; псевдографики ASCII (включая \) или пробел (SP)
   qtextSMTP      = %d32-33 / %d35-91 / %d93-126
                  ; т. е., кавычках допускается использование любых символов псевдографики 
                  ; ASCII (за исключением \ и двойных кавычек) или пробелов без символа
                  ; обратной дробной черты
   String         = Atom / Quoted-string

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

Недопустимо определять почтовые ящики таким образом, чтобы в SMTP требовалось использование символов, не входящих в набор ASCII (октетов с 1 в старшем бите) или управляющих кодов ASCII (десятичные значения 0-31 и 127). Такие символы недопустимо использовать в командах MAIL и RCPT или других командах, содержащих имена почтовых ящиков.

Отметим, что обратный слэш (\) относится к символам квотирования, используемым для индикации буквального (literally) использования следующего символа (взамен обычной интерпретации). Например, запись «Joe\, Smith» соответствует “Joe, Smith”, т. е. Запятая после знака \ трактуется именно как запятая, а не специальный символ.

Для обеспечения взаимодействия и совместимости с DNS в именовании и приложениях (см., например, параграф 2.3.1 базового стандарта DNS — RFC1035 [2]) недопустимо включать в метки доменных имен для клиентов и серверов SMTP никакие символы, кроме букв латиницы, цифр и дефиса. В частности, символ подчеркивания (underscore) использовать нельзя. Серверы SMTP, получающие команды с некорректными символами (при отсутствии других причин для отказа), должны отвергать такие команды с возвратом отклика 501 (это правило, подобно другим, может быть изменено расширениями SMTP).

4.1.3. «Дословные» адреса

Иногда хост не знает доменного имени и почтовая связь (в частности, передача сообщений об ошибках) блокируется. Для решения этой проблемы в качестве альтернативы доменному имени может использоваться специальная форма адреса (literal address). Для адресов IPv4 эта форма использует десятичное представление байтов IP-адреса с разделением точками. Адреса заключаются в квадратные скобки (например, [123.255.37.2]), которые говорят об использовании адреса IPv4 в десятичном представлении с разделением точками. Для IPv6 и других форм адресации, которые могут быть в последствии стандартизованы, форма включает стандартизованный тег, идентифицирующий синтаксис адреса, (двоеточие — 🙂 и собственно адрес в формате, заданном стандартом [например, RFC 4291 [8] для IPv6].

В частности, используются следующие варианты:

   IPv4-address-literal  = Snum 3("."  Snum)
   IPv6-address-literal  = "IPv6:" IPv6-addr
   General-address-literal  = Standardized-tag ":" 1*dcontent
   Standardized-tag  = Ldh-str
                     ; должен быть опубликован в RFC со статусом Standards-Track  и 
                     ; зарегистрирован IANA
   dcontent       = %d33-90 / ; Печатаемый символ US-ASCII
                  %d94-126    ; исключая "[", "\", "]"
   Snum           = 1*3DIGIT
                  ; значения от 0 до 255 в десятичном представлении
   IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
   IPv6-hex       = 1*4HEXDIG
   IPv6-full      = IPv6-hex 7(":" IPv6-hex)
   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; "::" представляет по крайней мере две 16-битовых группы нулей. В 
                  ; дополнение может использоваться до 6 групп.
   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                 ; :: представляет по крайней мере две 16-битовых последовательности нулей
                 ; в дополнение к :: может присутствовать не более 4 групп и
                 ; IPv4-address-literal

4.1.4. Порядок команд

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

Сеанс, который будет включать почтовую транзакцию, должен быть сначала инициализирован командой EHLO. Серверам SMTP следует воспринимать без инициализации команды, не использующие почтовых транзакций (например, VRFY или EXPN).

Команда EHLO может вводиться клиентом в действующем сеансе. При первом использовании команды в данной сессии сервер SMTP должен очистить все буферы и сбросить состояние, как при получении команды RSET. Иными словами, последовательность команд RSET — EHLO является избыточной, и мало полезна ввиду выполнения ненужных повторяющихся действий.

Если команда EHLO неприемлема для сервера SMTP, он должен возвращать отклик 501, 500, 502 или 550. Сервер SMTP должен сохранять после передачи таких откликов состояние, которое было до получения команды EHLO.

Клиент SMTP должен (по возможности) предоставлять в параметрах команд EHLO первичное доменное имя (не CNAME или MX) своего хоста, как сказано в параграфе 2.3.5. Если это невозможно (например, клиент использует динамический адрес и не имеет явного имени), следует взамен имени использовать «дословный» адрес.

Сервер SMTP может проверять соответствие доменного имени в команде EHLO реальному IP-адресу клиента. Однако для сервера недопустимо отвергать сообщение по результатам проверки. Эти результаты могут использоваться для протоколирования и трассировки. Отметим, что этот запрет применим только к соответствию параметра и адреса IP; дополнительное рассмотрения вопросов отказа от приема входящих соединений или почтовых сообщений проводится в параграфе 7.9.

Команды NOOP, HELP, EXPN, VRFY и RSET могут использоваться любой момент на протяжении всего сеанса и даже без предварительной организации сеанса. Серверам SMTP следует нормально обрабатывать эти команды (т. е., не выдавать в ответ отклик 503) даже в тех случаях, когда эти команды используются до получения команды EHLO; клиентам следует открывать сессию с помощью команды EHLO до ввода перечисленных команд.

Если следовать этим правилам, пример из RFC 821, показывающий отклик «550 access denied to you» в ответ на команду EXPN некорректен, если команда EHLO не была введена до EXPN или клиенту не было отказано в обслуживании на основе IP-адреса клиента или по результатам аутентификации или аналогичных механизмов.

Команда MAIL (или устаревшие команды SEND, SOML, SAML) начинает почтовую транзакцию. После начала транзакции последняя включает начальную команду, одну или несколько команд RCPT и команду DATA, вводимые в указанном порядке. Почтовая транзакция прерывается командой RSET, новой командой EHLO или командой QUIT. В сеансе может происходить множество последовательных транзакций или не быть транзакций вообще. Недопустимо передавать команду MAIL (или SEND, SOML, SAML), если почтовая транзакция уже открыта, т. е., эту команду можно передавать только при отсутствии в сеансе продолжающейся почтовой транзакции – предыдущая транзакция должна быть завершена успешным выполнением команды DATA или прервана командой RSET или новой командой EHLO.

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

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

4.1.5. Команды частного использования

Как было сказано в параграфе 2.2.2, команды, начинающиеся с X, могут использоваться в результате двухстороннего соглашения между клиентом (отправитель) и сервером (получатель) SMTP. Предполагается, что сервер SMTP, не распознающий такие команды, будет возвращать отклик 500 Command not recognized. Сервер SMTP с расширенными функциями может перечислить имена, связанные с командами частного использования, в своем отклике на команду EHLO.

Команды, переданные или воспринятые системами SMTP и не начинающиеся с X, должны соответствовать требованиям параграфа 2.2.2.

4.2. Отклики SMTP

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

Детальное описание последовательностей команда – отклик приводится в параграфе 4.3.

Отклик SMTP содержит трехзначный номер (передается как три числовых символа), за которым обычно следует строка текста, если в данной спецификации явно не указано иное. Числовые коды предназначены для автоматического определения состояния, в которое нужно перейти, текст – для человека. Цифровой код обеспечивает требуемую информацию и программе-клиенту не требуется просматривать текстовую часть отклика, которую в результате можно просто отбрасывать или передавать пользователю. Имеющиеся исключения из этого правила явно указаны в спецификации. В частности, коды откликов 220, 221, 251, 421 и 551 связаны с текстовыми сообщениями, которые клиентская программа должна разбирать и интерпретировать. В общем случае текст может зависеть от сервера или текущего контекста, т. е. каждый оклик может содержать разный текст. Обсуждение теоретических вопросов генерации откликов приводится в параграфе 4.2.1. Формально отклик определяется как последовательность: трехзначный код, <SP>, строка текста, <CRLF> или многострочный текст (см. параграф 4.2.1). Поскольку (в нарушение данной спецификации) текст иногда не включается в отклик, получившим такой отклик клиентам следует быть готовыми к обработке только числового кода (возможно, после кода в отклик будет помещен символ пробела). Предполагается, что лишь команды EHLO, EXPN и HELP могут возвращать многострочные отклики при нормальных обстоятельствах, однако такие отклики допускаются для всех команд.

В формате ABNF отклик сервера имеет вид:

   Greeting       = ( "220 " (Domain / address-literal)
                  [ SP textstring ] CRLF ) /
                  ( "220-" (Domain / address-literal)
                  [ SP textstring ] CRLF
                  *( "220-" [ textstring ] CRLF )
                  "220" [ SP textstring ] CRLF )
   textstring     = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
   Reply-line     = *( Reply-code "-" [ textstring ] CRLF )
                  Reply-code [ SP textstring ] CRLF
   Reply-code     = %x32-35 %x30-35 %x30-39

где Greeting появляется только в откликах с кодом 220, анонсирующих открытие сервером своей части соединения. Другие возможные варианты откликов сервера на открытие соединения следуют синтаксису Reply-line.

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

Клиенты SMTP должны определять свои действия только на основе кода отклика, а не его текста (за исключением change of address 251 и 551, а при необходимости и 220, 221, 421). В общем случае клиент должны воспринимать любой текст и отклики без текста (хотя серверам не следует передавать откликов, содержащих только код). Пробел после кода отклика рассматривается как часть текста. По возможности клиенту SMTP следует проверять первую цифру кода отклика (индикация важности).

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

При отсутствии согласованных с клиентом расширений для серверов SMTP недопустимо передавать отклики, в которых первая цифра кода отличается от 2, 3, 4 или 5. Клиентам при получении таких кодов следует трактовать их как признак неисправимой ошибки и прерывать почтовую транзакцию.

4.2.1. Важность кодов отклика и теоретические вопросы

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

Первая цифра кода может принимать 4 значения:

2yz – позитивный отклик о завершении

Запрошенная операция успешно завершена и могут вводиться новые команды.

3yz – позитивный промежуточный отклик

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

4yz – негативный отклик о временных проблемах

Команда не принята и запрошенная операция не выполнена. Однако условия, не позволяющие выполнить команду, носят временный характер и операция может быть запрошена вновь. Отправителю следует вернуться к началу последовательности команд (если таковая была). Понятие «временный» является недостаточно строгим и взаимодействующие стороны (клиент и сервер SMTP) должны одинаково интерпретировать его. Для каждого отклика этой группы время может различаться, но клиенту SMTP следует продолжать попытки. Различия между временными и постоянными проблемами (коды 5yz) достаточно условны и отклики 4yz обычно возвращаются в тех случаях, когда возможен позитивный результат при повторе без изменения формы команды и свойств отправителя или получателя (т. е., команда просто может быть повторена без изменений).

5yz — негативный отклик о постоянных проблемах

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

Нет ничего дурного в том, что протокол FTP [34] использует сходную архитектуру откликов и коды SMTP основаны на модели FTP. Однако в SMTP используется модель «команда — отклик», тогда как командный протокол FTP является асинхронным; кроме того, принятая в FTP группа кодов 1yz не используется в модели SMTP.

Вторая цифра отклика показывает категорию ошибки:

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

x1z Информация: отклик на запрос информации (например, справка или состояние).

x2z Соединение: отклики, относящиеся к каналу передачи.

x3z Не задан.

x4z Не задан.

x5z Почтовая система: отклики показывают состояние принимающей почтовой системы по отношению к запрошенной передаче или другим действиям почтовой системы.

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

Например, команды типа NOOP, при успешном завершении которых клиент SMTP не получает новой информации, будут возвращать код 250. Отклик 502 возвращается при запросе нереализованной команды, а отклик 504 – для реализованных команд с неподдерживаемыми параметрами.

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

Формат многострочных откликов требует, чтобы каждая строка (кроме последней) начиналась кодом отклика, после которого следует дефис (-), а далее — текст. В последней строке вместо дефиса используется пробел — <SP>, после которого может следовать текст, и <CRLF>. Как указано выше, серверам следует передавать символ <SP>, если далее не будет текста, но клиент должен быть готов к отсутствию символа пробела.

Ниже приведен пример многострочного отклика:

250-Первая строка
250-Вторая строка
250-234 Текст, начинающийся с числа
250 Последняя строка

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

4.2.2. Коды откликов (по группам)

500	Syntax error, command unrecognized	Синтаксическая ошибка, команда не распознана (это может говорить о слишком длинной команде).
501	Syntax error in parameters or arguments	Синтаксическая ошибка в параметрах или аргументах.
502	Command not implemented	Команда не реализована (см. параграф 4.2.4).
503	Bad sequence of commands	Некорректный порядок команд.
504	Command parameter not implemented	Параметр команды не реализован.
211	System status, or system help reply	Отклик с системной справкой или состоянием системы.
214	Help message	Информация о работе с сервером или отдельных командах.
220	<domain> Service ready	Служба для указанного домена готова.
221	<domain> Service closing transmission channel	Закрывается канал передачи для указанного домена.
421	<domain> Service not available, closing transmission channel	Для указанного домена обслуживание невозможно и канал связи закрывается. Это может быть откликом на любую команду, если известно, что сервис должен быть отключен.
250	Requested mail action okay, completed	Операция благополучно завершена.
251	User not local; will forward to <forward-path>	Нелокальный пользователь – почта будет пересылаться по прямому пути (см. параграф 3.4).
252	Cannot VRFY user, but will accept message and attempt delivery	Не удается проверить почтовый ящик, но сообщение принято и сервер попытается его доставить (см. параграф 3.5.3).
455	Server unable to accommodate parameters	Сервер не может принять параметры.
555	MAIL FROM/RCPT TO parameters not recognized or not implemented	Параметры команды MAIL FROM или RCPT TO не удалось распознать или их поддержка не реализована.
450	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, занят или временно заблокирован в соответствии с политикой).
550	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, почтовый ящик не найден, к нему нет доступа или команда отвергнута в соответствии с заданной политикой).
451	Requested action aborted: error in processing	Запрошенная операция прервана в результате ошибки.
551	User not local; please try <forward-path>	Нелокальный пользователь – попытайтесь использовать прямой путь (см. параграф 3.4).
452	Requested action not taken: insufficient system storage	Запрошенная операция не выполнена по причине нехватки пространства (на диске).
552	Requested mail action aborted: exceeded storage allocation	Запрошенная операция прервана по причине превышения выделенного (дискового) пространства.
553	Requested action not taken: mailbox name not allowed	Запрошенная операция не выполнена – недопустимый почтовый ящик (например, синтаксическая ошибка в имени ящика).
354	Start mail input; end with <CRLF>.<CRLF>	Начало ввода данных. Завершение по <CRLF>.<CRLF>
554	Transaction failed или No SMTP service here	Отказ транзакции или отсутствие поддержки сервиса SMTP (при попытке соединения)

4.2.3. Коды откликов в порядке номеров

211	System status, or system help reply	Отклик с системной справкой или состоянием системы.
214	Help message	Информация о работе с сервером или отдельных командах.
220	<domain> Service ready	Служба для указанного домена готова.
221	<domain> Service closing transmission channel	Закрывается канал передачи для указанного домена.
250	Requested mail action okay, completed	Операция благополучно завершена.
251	User not local; will forward to <forward-path>	Нелокальный пользователь – почта будет пересылаться по прямому пути (см. параграф 3.4).
252	Cannot VRFY user, but will accept message and attempt delivery	Не удается проверить почтовый ящик, но сообщение принято и сервер попытается его доставить (см. параграф 3.5.3).
354	Start mail input; end with <CRLF>.<CRLF>	Начало ввода данных. Завершение по <CRLF>.<CRLF>.
421	<domain> Service not available, closing transmission channel	Для указанного домена обслуживание невозможно и канал связи закрывается. Это может быть откликом на любую команду, если известно, что сервис должен быть отключен.
450	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, занят или временно заблокирован в соответствии с политикой).
451	Requested action aborted: error in processing	Запрошенная операция прервана в результате ошибки.
452	Requested action not taken: insufficient system storage	Запрошенная операция не выполнена по причине нехватки пространства (на диске).
455	Server unable to accommodate parameters	Сервер не может принять параметры.
500	Syntax error, command unrecognized	Синтаксическая ошибка, команда не распознана (это может говорить о слишком длинной команде).
501	Syntax error in parameters or arguments	Синтаксическая ошибка в параметрах или аргументах.
502	Command not implemented	Команда не реализована (см. параграф 4.2.4).
503	Bad sequence of commands	Некорректный порядок команд.
504	Command parameter not implemented	Параметр команды не реализован.
550	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, почтовый ящик не найден, к нему нет доступа или команда отвергнута в соответствии с заданной политикой).
551	User not local; please try <forward-path>	Нелокальный пользователь – попытайтесь использовать прямой путь (см. параграф 3.4).
552	Requested mail action aborted: exceeded storage allocation	Запрошенная операция прервана по причине превышения выделенного (дискового) пространства.
553	Requested action not taken: mailbox name not allowed	Запрошенная операция не выполнена – недопустимый почтовый ящик (например, синтаксическая ошибка в имени ящика).
554	Transaction failed или No SMTP service here	Отказ транзакции или отсутствие поддержки сервиса SMTP (при попытке соединения).
555	MAIL FROM/RCPT TO parameters not recognized or not implemented	Параметры команды MAIL FROM или RCPT TO не удалось распознать или их поддержка не реализована.

4.2.4. Отклик 502

У разработчиков часто возникают вопросы об использовании отклика 502 (Command not implemented – команда не реализована). Код 502 следует использовать в тех случаях, когда сервер SMTP распознал команду, но не умеет ее выполнять. Если команда не распознана, следует возвращать код 500. Для систем SMTP с расширенными функциями в откликах на команду EHLO недопустимо указывать команды, приводящие к отклику 502 или 500.

4.2.5. Коды откликов после DATA и последующих <CRLF>.<CRLF>

Когда сервер SMTP возвращает позитивный отклик (код 2yz) после завершения команды DATA с последовательностью <CRLF>.<CRLF>, этот сервер принимает на себя ответственность за следующие операции:

• доставка сообщения (если почтовый ящик получателя существует);
• при неудачной попытке доставки в результате временных проблем предпринимается разумное число повторных попыток с перерывами (см. параграф 4.5.4);
• при неудаче вследствие долгосрочных проблем или после исчерпания заданного числа попыток в случае временных проблем исходному отправителю сообщения посылается уведомление (по адресу из команды MAIL).

Когда сервер SMTP возвращает отклик о временных проблемах (4yz) после команды DATA с завершающей последовательностью <CRLF>.<CRLF>, недопустимо предпринимать какие-то последующие попытки доставки этого сообщения. Клиент SMTP сохраняет за собой ответственность за доставку этого сообщения и может возвратить его пользователю или снова поставить в очередь на доставку (см. параграф 4.5.4.1).

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

Когда сервер SMTP возвращает информацию о долгосрочных проблемах (код 5yz) после выполнения команды DATA с завершающей последовательностью <CRLF>.<CRLF>, недопустимо предпринимать какие-либо дополнительные попытки доставки сообщения. Как и для случая временных проблем, ответственность за доставку сообщения сохраняется за клиентом SMTP, но клиенту не следует пытаться повторить доставку тому же серверу без просмотра сообщения пользователем и внесения соответствующих изменений.

4.3. Порядок следования команд и откликов

4.3.1. Обзор

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

Примечание. Все отклики-приветствия включают официальное имя хоста (FQDN), на котором работает сервер, в качестве первого слова после кода. В некоторых случаях у хоста может не быть собственного имени. Обсуждение альтернативных имен для таких ситуаций приводится в параграфе 4.1.3.

Ниже приведены 3 примера приветствий:

220 ISIF.USC.EDU Service ready
220 mail.example.com SuperSMTP v 6.1.2 Service ready
220 [10.0.0.1] Clueless host service ready

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

4.3.2. Последовательности команда — отклик

Для каждой команды указаны обычные позитивные отклики. Используемые перед позитивными откликами префиксы включают I (промежуточный), S (успех) и E (ошибка). Поскольку некоторые серверы могут генерировать иные отклики в соответствующих обстоятельствах и с учетом возможности появления новых кодов, клиентам SMTP следует (по возможности) интерпретировать только первую цифру кода. Кроме того, клиент должен быть готов к работе с неизвестными кодами, также интерпретируя в них только первую цифру. За исключением расширений, использующих механизмы, описанные в параграфе 2.2, для серверов SMTP недопустима передача кодов, содержащих что-либо сверх 3 цифр или использующих цифры, не входящие в разрешенный диапазон 2 — 5 (включительно).

Описанные здесь варианты откликов на команды (в принципе, и сами коды) могут дополняться или изменяться при использовании расширений SMTP, предлагаемых сервером и понятных (запрашиваемых) клиентом. Однако, если целью является более четкая грануляция кодов, а не определение кодов для совершенно новых случаев, следует использовать систему, описанную в RFC 3463 [25], чтобы не изобретать новых кодов.

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

500 — для случая command line too long (слишком длинная команда) или при получении непонятной команды. Отметим, что отклик command not recognized (неизвестная команда) в ответ на команду из обязательного набора является нарушением данной спецификации. Аналогично, генерация сообщения command too long в ответ на команду, длина которой не превышает 512 будет нарушением требований параграфа 4.5.3.1.4.

501 Syntax error in command or arguments (синтаксическая ошибка в команде или аргументах). Для поддержки будущих расширений командам, включенным в данную спецификацию, как команды без аргументов (DATA, RSET, QUIT), следует возвращать отклик 501 при получении команды с аргументами, если иное не согласовано в анонсированном EHLO расширении.

421 Service shutting down and closing transmission channel — сервис отключен с разрывом коммуникационного канала.

В нормальных условиях в ответ на команды могут возвращаться следующие отклики:

Команда	Успех (S)	Неудача (E)
Организация соединения	220	554
EHLO или HELO	250	50420, 550, 50221
MAIL	250	552, 451, 452, 550, 553, 503, 455, 555
RCPT	250, 25122	550, 551, 552, 553, 450, 451, 452, 503, 455, 555
DATA (промежуточный отклик 354)	250	552, 554, 451, 452, 450, 550 (отказ в соответствии с политикой)
DATA		503,55
RSET	250
VRFY	250, 251, 252	550, 551, 553, 502, 504
EXPN	250, 252	550, 500, 502, 504
HELP	211, 214	502, 504
NOOP	250
QUIT	221

4.4. Трассировочная информация

Когда сервер SMTP получает сообщение для доставки или дальнейшей обработки, он должен вставить трассировочную информацию (time stamp или Received) в начало содержимого, как описано в параграфе 4.1.1.4.

Трассировочная строка должна иметь следующую структуру:

• В поле FROM, которое должно обеспечиваться в среде SMTP, следует включать (1) имя хоста-отправителя, представленное в команде EHLO, и (2) IP-адрес отправителя, определенный из соединения TCP.
• Поле ID может включать @, как предложено в RFC 822, но это необязательно.
• Поле FOR (если оно присутствует) должно содержать список элементов <path>, даже при использовании множества команд RCPT. Это может влиять на безопасность системы, поэтому нежелательно включать такие списки (см. параграф 7.2).

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

По мере расширения сети Internet просмотр строк Received становится все более важным средством диагностики почтовых систем, особенно для обнаружения медленно работающих трансляторов. Серверам SMTP, которые создают поля Received, следует явно задавать временной сдвиг (например, -0800), а не использовать имена часовых поясов. По возможности следует указывать локальное время (с учетом пояса), а не UT²³. Такая информация дает больше сведений о локальных условиях. Если требуется использовать UT, получателю достаточно использовать простую арифметику для получения нужного значения. Использование формата UT приводит к потере информации о часовом поясе сервера. Если желательно указывать имя часового пояса, его следует давать как комментарий.

Когда сервер SMTP обеспечивает «окончательную доставку» сообщения, он вставляет строку обратного пути (return-path) в начало почтовых данных. Использование return-path является обязательным и почтовые системы должны поддерживать это. Строка обратного пути сохраняет значение параметра <reverse-path> из команды MAIL. Окончательная доставка сообщения все еще сохраняет его в среде SMTP. Обычно сообщение доставляется в почтовый ящик пользователя или почтовое хранилище, но в некоторых случаях сообщение может подвергаться дополнительной обработке или передаваться другими почтовыми системами.

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

В приведенном выше тексте предполагается, что окончательные почтовые данные будут начинаться со строки обратного пути, за которой будет следовать одна или несколько строк с временными метками. После этих строк будет следовать оставшаяся часть почтовых данных — почтовый заголовок и тело сообщения (RFC 5322 [4]).

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

Генерирующей сообщение системе SMTP не следует передавать сообщений, в заголовок которых уже включено поле Return-path. Для серверов SMTP, обеспечивающих трансляцию, недопустимо проверять данные сообщения и, особенно, наличие поля заголовка Return-path. Сервер SMTP, обеспечивающий окончательную доставку, может удалять имеющийся заголовок Return-path перед добавлением своего.

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

Историческое замечание. Приведенные в RFC 822 сведения, отвергающие использование заголовка Return-path (или адреса возврата из команды MAIL в конверте) для доставки информации об ошибках, неприменимы в среде Internet. Адрес обратного пути (копируемый в Return-path) должен использоваться для доставки всех сообщений об ошибках в процессе доставки.

В частности:

• Шлюзам из SMTP в другие среды следует вставлять обратный путь, если у них нет информации о том, что другая среда также использует в адресах доменные имена Internet и поддерживает отдельный конверт с адресом отправителя.
• Шлюзам из других сред в SMTP следует удалять из заголовка строку обратного пути и копировать эту информацию в конверт SMTP или объединять ее с присутствующей в конверте информацией из другой транспортной системы для построения обратного пути для команды MAIL в конверте SMTP.

Сервер должен принимать специальные меры в случаях, когда обработка принятых почтовых данных успешна лишь отчасти. Это может произойти, если после приема нескольких адресов получателей и почтовых данных для них сервер SMTP обнаружит, что возможна доставка только некоторым из указанных адресатов. В таких случаях на команду DATA должен возвращаться отклик OK. Однако сервер SMTP должен подготовить и передать уведомление о невозможности доставки отправителю сообщения.

Должно передаваться одно уведомление со списком всех адресатов, которым невозможно передать сообщение, или отдельные уведомления для каждого из таких адресатов. Из соображений экономии следует, по возможности, использовать первый вариант. Отметим, что основная разница между обработкой псевдонимов (параграф 3.9.1) и пересылкой (данный параграф) состоит в изменении в данном случае обратного адреса. Все уведомления о невозможности доставки передаются с использованием команды MAIL (даже в тех случаях, когда проблема возникла при обработке устаревших команд SEND, SOML или SAML) и должны содержать пустое поле обратного пути (см. параграф 3.6).

Временные метки и пути возврата формально определяются следующим образом (определения FWS и CFWS даны в RFC 5322 [4]):

   Return-path-line  = "Return-Path:" FWS Reverse-path <CRLF>
   Time-stamp-line  = "Received:" FWS Stamp <CRLF>
   Stamp          = From-domain By-domain Opt-info [CFWS] ";" FWS date-time
                  ; date-time определено в RFC 5322 [4], но формы «obs-», особенно для лет,
                  ; обозначенных 2 цифрами, запрещены в SMTP и их использование недопустимо.
   From-domain    = "FROM" FWS Extended-Domain
   By-domain      = CFWS "BY" FWS Extended-Domain
   Extended-Domain  = Domain / ( Domain FWS "(" TCP-info ")" ) 
                      / ( address-literal FWS "(" TCP-info ")" )
   TCP-info       = address-literal / ( Domain FWS address-literal )
                  ; сервер берет информацию из соединения TCP, а не из клиентской команды EHLO.
   Opt-info       = [Via] [With] [ID] [For] [Additional-Registered-Clauses]
   Via            = CFWS "VIA" FWS Link
   With           = CFWS "WITH" FWS Protocol
   ID             = CFWS "ID" FWS ( Atom / msg-id )
                  ; msg-id определено в RFC 5322 [4]
   For            = CFWS "FOR" FWS ( Path / Mailbox )
   Additional-Registered-Clauses  = CFWS Atom FWS String
                                  ; В этом месте могут добавляться определения из новых
                                  ; стандартов, зарегистрированные в IANA. Серверам SMTP 
                                  ; не следует использовать незарегистрированные имена.
                ; См. раздел 8.
   Link           = "TCP" / Addtl-Link
   Addtl-Link     = Atom
                  ; Дополнительные стандартные имена каналов, зарегистрированные IANA. Via -
                  ; предварительное значение для транспорта, отличного от Internet. Серверам 
                  ; SMTP не следует использовать незарегистрированные имена.
   Protocol       = "ESMTP" / "SMTP" / Attdl-Protocol
   Attdl-Protocol = Atom
                  ; Дополнительные стандартные имена для протоколов, зарегистрированных IANA
         ; в реестре mail parameters [9]. Серверам SMTP не следует использовать
                  ; незарегистрированные имена.

 

4.5. Другие вопросы реализации

4.5.1. Минимальная реализация

Для обеспечения работы SMTP должна быть обеспечена по крайней мере минимальная функциональность. Ниже перечислены команды, которые каждая реализация должна поддерживать в соответствии с данной спецификацией:

EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY

Любые системы, которые включают сервер SMTP, поддерживающий трансляцию или доставку почты, должны поддерживать зарезервированный почтовый ящик postmaster, как независимое от регистра символов локальное имя. Без такого адреса можно обойтись, если сервер всегда возвращает отклик 554 на открытие соединений (см. параграф 3.1). Требование принимать почту для адресата postmaster, ведет к тому, что команды RCPT, указывающие адрес postmaster в любом из доменов, для которых сервер SMTP обеспечивает почтовое обслуживание, а также специальный случай команды RCPT TO:<Postmaster> (без указания домена), должны поддерживаться сервером.

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

4.5.2. Прозрачность

Без принятия некоторых специальных мер последовательность <CRLF>.<CRLF> будет восприниматься как завершение почтовых данных и не может включаться пользователем в текст. Обычно пользователи даже не знают о таких «запрещенных» последовательностях. Для прозрачной передачи подготовленного пользователем текста служат следующие процедуры:

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

Почтовые данные могут включать любые из 128 символов ASCII. Все символы доставляются в почтовый ящик получателя, включая пробелы, табуляторы и другие управляющие символы. Если канал передачи поддерживает поток данных в форме 8-битовых байтов (октетов), 7-битовые коды ASCII передаются с выравниванием по правому краю октета и нулевым значением старшего бита. Трансляторы SMTP используют специальную трактовку 8-битовых символов (см. 3.6).

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

4.5.3. Размеры и тайм-ауты

4.5.3.1. Ограничения размеров

Существуют некоторые объекты, для которых требуется ограничение размера. Каждая реализация должна быть способна принимать объекты, размеры которых не выходят за эти ограничения. Следует (по возможности) избегать передачи объектов большего размера. Однако некоторые почтовые системы Internet создают такие адреса в формате X.400 (RFC 2156 [35]), которые могут потребовать большего размера объектов. Клиенты могут пытаться передать такие объекты, но они должны быть готовы к отказу серверов от обслуживания слишком больших объектов. Для снижения вероятности возникновения проблем в реализациях следует использовать методы, не ограничивающие размеры объектов.

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

4.5.3.1.1. Локальная часть

Максимальный размер имени пользователя или локальной части адреса составляет 64 октета.

4.5.3.1.2. Домен

Максимальный размер доменного имени составляет 255 октетов.

4.5.3.1.3. Путь

Максимальная длина прямого и обратного пути составляет 256 октетов (включая разделители и пунктуацию).

4.5.3.1.4. Строка команды

Максимальная длина командной строки с учетом завершающей последовательности <CRLF> составляет 512 октетов. Расширения SMTP могут разрешать более длинные команды.

4.5.3.1.5. Строка отклика

Максимальная длина строки отклика с учетом кода и <CRLF> составляет 512 октетов. Дополнительную информацию можно передать, используя многострочный отклик.

4.5.3.1.6. Строка текста

Максимальная длина строки текста с учетом <CRLF> составляет 1000 октетов (без учета добавляемую для обеспечения прозрачности точки в начале). Расширения SMTP могут использовать более длинные строки.

4.5.3.1.7. Содержимое письма

Ограничение максимального размера содержимого сообщения (включая заголовки и тело) должно быть не менее 64K октетов. После введения стандартов Internet на multimedia-почту (RFC 2045 [21]) размеры почтовых сообщений Internet многократно возросли и по возможности следует избегать ограничения размера сообщений. Системам SMTP, которые не могут отказаться от ограничения размеров следует реализовать сервисное расширение SIZE (RFC 1870 [10]), а клиентам SMTP, передающим большие сообщения, следует по возможности использовать это расширение.

4.5.3.1.8. Буфер адресатов

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

4.5.3.1.9. Трактовка выхода за пределы

Ошибки, связанные с выходом за допустимые пределы, приводят к передаче соответствующих откликов:

500 Line too long – слишком длинная строка
501 Path too long – слишком длинный путь
452 Too many recipients – слишком много получателей (см. ниже)
552 Too much mail data – слишком много почтовых данных.

4.5.3.1.10. Слишком много получателей

В RFC 821 [1] некорректно указано, что сервер SMTP в случаях превышения числа команд RCPT (too many recipients) генерирует отклик с кодом 552. Корректным кодом для таких откликов является 452. Клиентам следует трактовать код 552 в таких случаях как временную проблему, а не постоянную, чтобы описанная ниже логика могла работать.

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

Если сервер SMTP имеет предел для числа команд RCPT и этот предел превышен, сервер должен использовать отклик с кодом 452 (но клиенту следует быть готовым и к получению кода 552, как было указано выше). Если ограничения сервера заданы правилами, он может использовать отклик с кодом 5yz. В частности, если задача состоит в том, чтобы запретить передачу сообщений с числом получателей, превышающим заданное для сайта значение, а не просто ограничить число адресатов для данной почтовой транзакции, разумно будет возвращать отклик 503 на любую команду DATA, полученную после отклика 452 (или 552), или просто возвращать код 503 после команды DATA без предшествующего негативного отклика.

4.5.3.2. Тайм-ауты

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

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

4.5.3.2.1. Стартовое сообщение 220: 5 минут

Клиентский процесс SMTP должен отличать сбои в соединениях TCP от задержки получения стартового приветствия с кодом 220. Многие серверы SMTP воспринимают соединение TCP, но задерживают передачу отклика 220, пока в системе не освободится достаточное для обработки почты количество ресурсов.

4.5.3.2.2. Команда MAIL: 5 минут

4.5.3.2.3. Команда RCPT: 5 минут

Если обработка списков рассылки и псевдонимов не откладывается до приема сообщения, требуется увеличение тайм-аута.

4.5.3.2.4. Инициирование команды DATA: 2 минуты

Этот тайм-аут определяет время ожидания отклика 354 Start Input на команду DATA.

4.5.3.2.5. Блок данных: 3 минуты

Время ожидания завершения каждого вызова TCPSEND для передачи блока данных.

4.5.3.2.6. Прерывание команды DATA: 10 минут

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

4.5.3.2.7. Тайм-аут сервера: 5 минут

Серверам SMTP следует использовать тайм-аут не менее 5 минут при ожидании от клиента следующей команды.

4.5.4. Стратегии повтора

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

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

4.5.4.1. Стратегия передачи

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

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

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

Клиенту следует сохранять список хостов, которым не удалось отправить почту, и соответствующие значения тайм-аутов для соединений вместо использования «тупых» попыток повтора.

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

Клиент SMTP может сократить задержку перед повтором, согласовав такое совращение с сервером SMTP. Например, при получении почты с какого-то адреса очевидна возможность передачи по этому адресу почты из очереди (если она есть). Применяя такой подход, приложение в большинстве случаев может обойтись без явного использования функций «передать сообщения из очереди сейчас» типа ETRN (RFC 1985 [36]).

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

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

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

Когда сообщение доставляется множеству адресатов и сервер SMTP, на который копируется сообщение для передачи, совпадает для множества получателей, следует передавать единственную копию сообщения. Т. е., клиенту SMTP следует использовать последовательность команд MAIL, RCPT, RCPT,… RCPT, DATA вместо последовательности MAIL, RCPT, DATA, …, MAIL, RCPT, DATA. Однако при большом количестве адресатов может быть превышено допустимое число повторов команды RCPT на одну команду MAIL. Описанный метод повышения эффективности следует реализовать.

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

4.5.4.2. Стратегия приема

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

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

4.5.5. Сообщения с пустым полем обратного пути

Некоторые типы уведомлений, требуемые существующими или предложенными стандартами, передаются с пустым полем обратного пути. К числу таких сообщений относятся уведомления об ошибках при доставке (см. параграф 3.7), другие типы сообщений DSN (Delivery Status Notifications – уведомления о состоянии доставки RFC 3461 [32]) и сообщения MDN (Message Disposition Notifications – уведомления о диспозиции сообщений RFC 3798 [37]). Все типы указанных сообщений являются уведомлениями о предыдущем сообщении и посылаются по обратному пути из заголовка письма, с которым связано данное уведомление. Невозможность доставки зачастую связана с проблемами в почтовой системе на хосте адресата, поэтому некоторые АДП настраиваются на пересылку таких уведомлений кому-нибудь, кто будет способен исправить проблему с почтой (например, с использованием псевдонима postmaster).

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

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

5. Преобразование адресов и обработка почты

5.1. Обнаружение целевого хоста

После того, как клиент SMTP лексически идентифицирует домен, для которого предназначена передаваемая на обработку почта (см. параграфы 2.3.5 и 3.6), должно выполняться обращение к серверу доменных имен (DNS lookup) для преобразования доменного имени (RFC 1035 [2]). Предполагается, что в адресах используются полные имена (FQDN) – механизм определения FQDN по частичному имени или локальному псевдониму выходит за пределы данной спецификации. В силу сложившейся практики, серверам SMTP, используемым для начального представления сообщений, не следует выполнять преобразований неполных имен (серверы представления сообщений [18] имеют более мощные механизмы таких преобразований), а для транслирующих серверов SMTP такие преобразования недопустимы.

При поиске сначала предпринимается попытка найти локальную запись MX, связанную с именем. Если взамен этого будет найдена запись CNAME, полученное в результате имя обрабатывается как исходное. Если сервер имен сообщает об отсутствии искомого домена, должно генерироваться сообщение об ошибке. При возврате сообщения о временной ошибке письмо должно помещаться в очередь для последующего повтора попытки передачи (см. параграф 4.5.4.1). Если возвращается пустой список записей MX, адрес трактуется, как связанный с неявной записью MX RR, имеющей уровень предпочтения 0 и указывающей на данный хост. Если записи MX присутствуют, но ни одна из них не может быть использована, или неявная запись MX не может быть использована, должно генерироваться сообщение об ошибке.

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

Когда найдено доменное имя, связанное с MX RR, и полученное соответствующее поле данных, этот отклик должен включать доменное имя. При запросе по этому имени должна возвращаться по крайней мере одна адресная запись (например, A или AAAA), которая дает IP-адрес сервера SMTP для отправки тому сообщения.

Все прочие отклики, включая значения, возвращающие при запросе запись CNAME, выходят за пределы рассмотрения данного стандарта. Запрет меток, которые преобразуются в записи CNAME более подробно рассматривается в параграфе 10.3 RFC 2181 [38].

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

Для ранжирования адресов хостов используется два типа данных – множественные записи MX и многодомные хосты.

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

Хост получателя (возможно с предпочтительной записью MX) может оказаться многодомным – в таких случаях доменное имя будет преобразовываться в список адресов IP. Ответственность за упорядочивание этого списка лежит на интерфейсе преобразователя имен (domain name resolver), который должен упорядочивать список в порядке снижения предпочтений, а отправитель SMTP должен пытаться использовать адреса в предложенном порядке.

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

Если сервер SMTP принимает сообщение, для адресата которого данный сервер означен в записи MX, этот сервер может транслировать сообщение (потенциально, после получения переписанных адресов для MAIL FROM и/или RCPT TO), обеспечивая его окончательную доставку, или передать его дальше, используя тот или иной механизм, не относящийся к транспортной среде SMTP. Естественно, для второго случая сначала должен быть проверен список записей MX.

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

5.2. IPv6 и записи MX

В современной сети Internet клиенты и серверы SMTP могут использоваться на хостах IPv4, IPv6 или смешанных, которые поддерживают обе версии протокола IP. Домены хостов, на которые указывают записи MX, могут, следовательно, включать записи A RR (IPv4), AAAA RR (IPv6) и комбинации таких записей. Хотя в RFC 3974 [39] рассмотрен некоторый опыт использования в смешанных средах, этого опыта недостаточно для стандартизации, а некоторые из содержащихся в документе рекомендаций не вполне совместимы с настоящей спецификацией. Предпринимаемые действия могут зависеть от локальных условий (таких, как производительность участвующих в процессах сетей) и требуемых преобразований или быть обычными (например, клиентам, поддерживающим только IPv6, не нужно пытаться отыскать записи A RR или обращаться к серверам, которые поддерживают только IPv4). Разработчикам реализаций SMTP, которые могут работать в IPv6 или смешанных средах, следует изучить упомянутые выше процедуры, особенно комментарии по поводу многодомных хостов, и, предпочтительно, обеспечить механизмы, облегчающие тонкую настройку рабочей среды и взаимодействие почтовых систем IPv4 и IPv6 с учетом локальных условий.

6. Обнаружение и решение проблем

6.1. Гарантированная доставка и отклики по электронной почте

Когда получатель SMTP принимает порцию почты (передав отклик 250 OK в ответ на команду DATA), он принимает на себя ответственность за доставку или трансляцию сообщения. К этой ответственности следует относиться серьезно. Недопустима потеря сообщений по незначительным причинам, типа последующего «падения» хоста или предсказуемой нехватки ресурсов. Некоторые серьезные причины потери сообщений рассмотрены в следующем параграфе и параграфе 7.8.

Если после восприятия сообщения обнаруживается невозможность его доставки, получатель SMTP должен подготовить и передать уведомление об этом. При передаче уведомления должен использоваться пустой (<>) путь возврата в конверте. Получателем такого уведомления должен быть адрес из обратного пути в конверте (или строке Return-Path:). Если обратный путь пустой («<>»), для сервера SMTP недопустима передача уведомления. Обычно, ничто не запрещает на локальном уровне (в той же среде, к которой относится получатель SMTP) принимать решение о протоколировании или иной фиксации сведений о пустом пути возврата. Если адресом является явный маршрут source route, из него должен выделяться последний интервал (final hop).

В качестве примера предположим, что нужно передать уведомление для сообщения, принятого по команде:

MAIL FROM:<@a,@b:user@d>

Уведомление должно передаваться с помощью команды:

RCPT TO:<user@d>

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

Во избежание дублирования сообщений в результате тайм-аутов, получатель SMTP должен пытаться минимизировать время отклика на индикатор завершения данных <CRLF>.<CRLF>. Подробное обсуждение этого вопроса приводится в RFC 1047 [40].

6.2. Нежелательная и незапрошенная почта, почтовые атаки

Практичность и предсказуемость почтовой системы Internet требует, чтобы сообщения, которые могут быть доставлены, доставлялись на практике независимо от синтаксических ошибок и других отказов, связанных с сообщениями, а также независимо от содержимого почты. Если почта не может быть доставлена и не может быть отвергнута сервером SMTP в транзакции SMTP, эта почта должна быть возвращена (bounced) с уведомлением о невозможности доставки, как описано выше. В современном мире, когда многие операторы серверов SMTP убедились в том, что количество нежелательной почты большого размера во много раз превышает объем желаемой почты и когда восприятие сообщения может вызвать дополнительный нежелательный трафик, связанный с верификацией адреса, приведенный выше принцип утрачивает практический смысл.

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

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

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

6.3. Детектирование петель

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

6.4. Компенсация отклонений от стандартов

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

Проблемы, связанные с некорректным форматом сообщений, обострились после введения специальных протоколов для чтения (загрузки) почты с серверов [POP2 [15], POP3 [16], IMAP2 [41], PCMAIL [42]). Эти протоколы поддерживают использование SMTP в качестве протокола передачи (представления сообщений) и серверов SMTP для трансляции почты на хосты клиентов этих протоколов (которые часто не имеют прямого постоянного подключения к Internet). Исторически многие из таких хостов не поддерживают часть механизмов и данных, используемых SMTP (и протоколом почтовых форматов RFC 822 [28]). Некоторые могут не сохранять значение текущего времени, другие не понимают часовых поясов, третьи не знают своего имени и, конечно, ни один из таких хостов не может удовлетворять тем требованиям, которые заложены в концепцию заверенных адресов RFC 822.

В ответ на появление «ущербных» клиентов SMTP многие системы SMTP сейчас дополнительно обрабатывают сообщения, полученные от таких клиентов в неполном или некорректном формате. Такая стратегия в общем случае приемлема, когда сервер может идентифицировать или аутентифицировать клиента и между клиентом и сервером существует предварительное соглашение. Такое решение значительно лучше по сравнению с исправлениями, которые могут вносить серверы доставки или трансляции для малознакомых или совсем неизвестных пользователей и клиентских машин. Многие из этих проблем решаются за счет использования отдельного протокола для представления сообщений (типа RFC 4409 [18]) взамен использования для этих целей исходных серверов SMTP.

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

• добавление поля message-id при его отсутствии;
• добавление даты, времени и часового пояса при их отсутствии;
• корректировка адреса в соответствии с форматом FQDN.

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

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

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

7.1. Безопасность почты и обманки

Природа почты SMTP не обеспечивает безопасности, поскольку любой пользователь может напрямую взаимодействовать с принимающим или транслирующим сервером SMTP, создавать сообщения и обманывать простодушных получателей, полагающих, что это почта от кого-то другого. Создание таких сообщений, обманный характер которых не обнаруживается, – задача более сложная, но вполне посильная для людей с нужными знаниями и соответствующей мотивацией. Следовательно, по мере повышения уровня знаний в сфере почты Internet человек начинает понимать, что почта SMTP не может быть заверена на транспортном уровне, равно как не обеспечивается и проверка целостности почты. Реальная безопасность почты обеспечивается только сквозными методами, включающими контроля тела сообщения, использования цифровых подписей (см. RFC 1847 [43] и, например, PGP²⁴ в RFC 4880 [44] или S/MIME²⁵ в RFC 3851 [45]).

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

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

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

7.2. Скрытые копии — BC

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

Не существует неразрывных отношений между обратным (из команд MAIL, SAML и т. п.) или прямым (RCPT) адресом в транзакции SMTP (конверте) и адресами в заголовке. Принимающим системам не следует пытаться найти такие соотношения и использовать их для изменения заголовков с целью доставки сообщения. Популярный заголовок Apparently-to (видимо для) является нарушением данного принципа и хорошо известным случаем непреднамеренного разглашения информации; не следует пользоваться этим заголовком.

7.3. VRFY, EXPN, Security

Как обсуждалось в параграфе 3.5, отдельные сайты могут заблокировать использование команд VRFY и EXPN из соображений безопасности (см. ниже). Как следует из сказанного выше, для реализаций, обеспечивающих возможность такой блокировки, недопустимо показывать, что они могут проверять адреса, не проверяя их фактически. Если сайт блокирует команды из соображений безопасности, сервер SMTP должен возвращать отклик 252, а не код, который может ввести в заблуждение относительно результатов верификации адреса.

Возврат кода 250 в ответ на команду VRFY после проверки лишь синтаксиса команды (а не указанного адреса), является нарушением этого правила. Естественно, что реализации, «поддерживающие» команду VRFY, которые всегда будут возвращать отклик 550 независимо от корректности адреса, также нарушают это правило.

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

Использование команды EXPN для «сбора» адресов вынудило администраторов принять меры против недопустимого использования списков. Однако команды VRFY и EXPN остаются полезными инструментами для аутентифицированных пользователей и внутри административных доменов. Сайты, поддерживающие аутентификацию SMTP, могут выбрать вариант предоставления доступа к командам VRFY и EXPN только аутентифицированных пользователей. Разработчикам следует поддерживать команду EXPN, а сайтам следует быть осторожными при оценке возможности утечки информации.

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

7.4. Ремаршрутизация почты на основе откликов 251 и 551

До того, как клиент использует отклики 251 или 551 на команду RCPT для автоматического обновления своего поведения в будущем (корректировка адресной книги пользователя), ему следует проверить подлинность передавшего отклик сервера. Отказ от такой проверки оставляет возможность для организации атак с участием человека (MITM²⁶).

7.5. Разглашение информации в анонсах

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

7.6. Разглашение информации в полях трассировки

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

7.7. Разглашение информации при пересылке сообщений

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

7.8. Сопротивление атакам

В последние годы наблюдается рост числа атак на серверы SMTP в форме попыток получения адресов для проведения несанкционированных рассылок или попыток срыва работы почтовой службы (например, атаки на службы прикладного уровня). Хотя изучение таких атак выходит за пределы настоящего стандарта, для обеспечения нормального функционирования от серверов требуется возможность детектирования таких атак и принятия мер по своей защите. Например, если сервер обнаруживает передачу большого числа команд RCPT TO, по большей части или полностью включающих некорректные адреса, разумным поведением для сервера будет завершение соединения с генерацией соответствующего количества откликов 5yz (обычно 550).

7.9. Свобода действий сервера SMTP

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

В последние годы использование функций трансляции на случайных сайтах стало применяться как способ сокрытия истинного происхождения почты. Некоторые сайты в результате стали предоставлять функции трансляции только известным или идентифицируемым отправителям и разработчикам следует обеспечивать в программах возможность такой фильтрации. Когда почта отвергается по тем или иным причинам, определяемым политикой сайта, следует использовать код 550 в откликах на команды EHLO (или HELO), MAIL или RCPT.

8. Регистрация в IANA

Агентство IANA поддерживает три реестра, связанных с данной спецификацией, каждый из которых был открыт для RFC 2821 или раньше. В этом документе расширен третий реестр, как описано ниже. Ссылки на реестры даны на момент публикации документа; IANA не гарантирует постоянную корректность указанных URL. Реестры включают:

• Первый реестр (Simple Mail Transfer Protocol (SMTP) Service Extensions [46]) включает сервисные расширения SMTP и связанные с ними ключевые слова, а также (при необходимости) команды и их параметры. Как сказано в параграфе 2.2.2, ни одна из записей этого реестра не может начинаться с X. Записи могут создаваться только для расширений сервиса (и связанных с ними ключевых слов, параметров и команд), которые определены в стандартах или экспериментальных RFC, одобренных IESG для таких целей.
• Второй реестр (Address Literal Tags [47]) содержит теги, идентифицирующие «дословные» формы записи доменных имен, отличные от адресов IPv4 (эта форма включена в RFC 821 и настоящую спецификацию). Первая запись этого реестра относится к IPv6 (включена в эту спецификацию). Для использования дополнительных вариантов «дословного» представления требуется стандартизация, которой в настоящее время нет ни для одного из них.
• Третий реестр (Mail Transmission Types [46]), основанный RFC 821 и обновленный данной спецификацией, содержит идентификаторы каналов и протоколов, которые могут использоваться в субоператорах via и with трассировочных строк (заголовки Received:), описанных в параграфе 4.4. Идентификаторы каналов и протоколов в дополнение к указанным в этой спецификации могут регистрироваться только путем стандартизации или через экспериментальные расширения протоколов (RFC, одобренные IESG). Размер этого пространства имен для идентификации не ограничен, IESG поддерживает расширение пространства с учетом четкости документирования и отличия методов, нежели на основе предпочтительности самих методов.
  Добавлены подразделы VIA link types (типы каналов VIA) и WITH protocol types (типы протоколов WITH) для регистрации дополнительных пунктов (Additional-registered-clauses) в соответствии с описанным выше. Реестр будет включать имя пункта (clause), его описание, краткое описание синтаксиса связанной с пунктом строки, и ссылку на источник. По мере определения новых пунктов они могут, в принципе, задавать создание своих реестров, если значения String содержат зарезервированные или ключевые слова. Как идентификаторы каналов и протоколов, дополнительные пункты могут регистрироваться только путем стандартизации или разработки экспериментального протокола, документированного в RFC и одобренного IESG. Пространство имен дополнительных пунктов предназначено для идентификации и не ограничено по размеру. ESG поддерживает расширение пространства с учетом четкости документирования пунктов, реального применения или серьезных предпосылок для использования и отличия пунктов, нежели на основе предпочтительности свойств самих пунктов.

В дополнение к сказанному отметим, что при создании новых трассировочных полей заголовков (т. е. в дополнение к Return-path и Received) эти поля должны добавляться в реестр IANA, созданный BCP 90 (RFC 3864) [11] для использования с RFC 5322 [4].

9. Благодарности

Множество людей внесло вклад в подготовку RFC 2821 и отмечено в том документе. В настоящем документе редактор и сообщество должны поблагодарить Dawn Mann и Tony Hansen за помощь в мучительном процессе редактирования и преобразования документа из одного формата в другой.

Ни данный документ, ни RFC 2821 не увидели бы света без участия и проницательности Jon Postel. Его вклад включает и исходную спецификацию SMTP в RFC 821. Значительная часть текста RFC 821 сохранена в настоящем документе, наряду с исходными примерами, которые были слегка обновлены с учетом изменений в спецификации.

Многие люди внесли свои комментарии и предложения через списки рассылок или в письмах автору. Важные поправки и разъяснения предложили множество людей, включая Matti Aarnio, Glenn Anderson, Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman, Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J. Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett, Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos, David F. Skoll, Paul Smith и Brett Watson.

Работа директоров направления — Lisa Dusseault, Ted Hardie и Chris Newman — помогла начать и завершить подготовку этой спецификации, выполнению этой задачи помог и специальный комитет — все они заслуживают благодарности. Членами этого комитета были (в алфавитном порядке) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall Gellens, Tony Hansen, автор документа и Alexey Melnikov. Tony Hansen также выполнял функции руководства списками рассылок при рассмотрении этого документа, без его усилий не удалось бы беспристрастный и сбалансированный учет всех предложений; его терпеливость заслуживает отдельной благодарности.

10. Литература

10.1. Нормативные документы

[1] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821, August 1982.

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

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

[4] Resnick, P., «Internet Message Format», RFC 5322, October 2008.

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

[6] American National Standards Institute (formerly United States of America Standards Institute), «USA Code for Information Interchange», ANSI X3.4-1968, 1968.

[8] ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.

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

[8] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[9] Newman, C., «ESMTP and LMTP Transmission Types Registration», RFC 3848, July 2004.

[10] Klensin, J., Freed, N., and K. Moore, «SMTP Service Extension for Message Size Declaration», STD 10, RFC 1870, November 1995.

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

10.2. Дополнительная литература

[12] Partridge, C., «Mail routing and the domain system», RFC 974, January 1986.

[13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, «SMTP Service Extensions», STD 10, RFC 1869, November 1995.

[14] Klensin, J., «Simple Mail Transfer Protocol», RFC 2821, April 2001.

[15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. Reynolds, «Post Office Protocol: Version 2», RFC 937, February 1985.

[16] Myers, J. and M. Rose, «Post Office Protocol — Version 3», STD 53, RFC 1939, May 1996.

[17] Crispin, M., «INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1», RFC 3501, March 2003.

[18] Gellens, R. and J. Klensin, «Message Submission for Mail», RFC 4409, April 2006.

[19] Freed, N., «SMTP Service Extension for Command Pipelining», STD 60, RFC 2920, September 2000.

[20] Vaudreuil, G., «SMTP Service Extensions for Transmission of Large and Binary MIME Messages», RFC 3030, December 2000.

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

[22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, «SMTP Service Extension for 8bit-MIMEtransport», RFC 1652, July 1994.

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

[24] Freed, N. and K. Moore, «MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations», RFC 2231, November 1997.

[25] Vaudreuil, G., «Enhanced Mail System Status Codes», RFC 3463, January 2003.

[26] Hansen, T. and J. Klensin, «A Registry for SMTP Enhanced Mail System Status Codes», BCP 138, RFC 5248, June 2008.

[27] Freed, N., «Behavior of and Requirements for Internet Firewalls», RFC 2979, October 2000.

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

[29] Wong, M. and W. Schlitt, «Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1», RFC 4408, April 2006.

[30] Fenton, J., «Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)», RFC 4686, September 2006.

[31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, «DomainKeys Identified Mail (DKIM) Signatures», RFC 4871, May 2007.

[32] Moore, K., «Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)», RFC 3461, January 2003.

[33] Moore, K. and G. Vaudreuil, «An Extensible Message Format for Delivery Status Notifications», RFC 3464, January 2003.

[34] Postel, J. and J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, October 1985.

[35] Kille, S., «MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME», RFC 2156, January 1998.

[36] De Winter, J., «SMTP Service Extension for Remote Message Queue Starting», RFC 1985, August 1996.

[37] Hansen, T. and G. Vaudreuil, «Message Disposition Notification», RFC 3798, May 2004.

[38] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[39] Nakamura, M. and J. Hagino, «SMTP Operational Experience in Mixed IPv4/v6 Environments», RFC 3974, January 2005.

[40] Partridge, C., «Duplicate messages and SMTP», RFC 1047, February 1988.

[41] Crispin, M., «Interactive Mail Access Protocol: Version 2», RFC 1176, August 1990.

[42] Lambert, M., «PCMAIL: A distributed mail system for personal computers», RFC 1056, June 1988.

[43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, «Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted», RFC 1847, October 1995.

[44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, «OpenPGP Message Format», RFC 4880, November 2007.

[45] Ramsdell, B., «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification», RFC 3851, July 2004.

[46] Internet Assigned Number Authority (IANA), «IANA Mail Parameters», 2007, <http://www.iana.org/assignments/mail-parameters>.

[47] Internet Assigned Number Authority (IANA), «Address Literal Tags», 2007, <http://www.iana.org/assignments/address-literal-tags>.

Приложение A. Транспортный сервис TCP

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

Приложение B. Генерация команд SMTP из полей заголовка RFC 822

Некоторые системы используют раздел заголовков (и только его) RFC 822 в протоколах представления почты, а в остальных случаях генерируют команды SMTP на основе заголовков RFC 822, когда такие сообщения передаются АДП (MTA) от агентов ППА (MUA). Поскольку протокол взаимодействия АДП – ППА является частным и не задается стандартами Internet, в таких случаях могут возникать проблемы. Например, повторяющиеся проблемы могут возникать при обработке копий bcc и перераспределении списков, когда информация, потенциально относящаяся к почтовому конверту, не отделяется в процессе обработки от информации из заголовков и не хранится отдельно от нее.

Агентам ППА рекомендуется предоставлять своему первому АДП (submission client) конверт отдельно от сообщения. Однако, если конверты не поддерживаются, следует генерировать команды SMTP, используя приведенные правила:

1. Каждый адрес получателя из полей заголовка TO, CC, BCC следует копировать в команду RCPT (генерируя, при необходимости, нужное число копий сообщения для помещения в очередь или доставки). Сюда включаются все адреса, перечисленные в «группе» RFC 822. Все поля BCC следует удалять из заголовков. После завершения такой обработки оставшиеся поля заголовков следует проверить, чтобы убедиться, что осталось хотя бы одно поле TO, CC или BCC. При отсутствии следует поместить в заголовок поле BCC без дополнительной информации, как указано в работе [4].
2. Адрес возврата в команде MAIL следует (по возможности) получать из системной идентификации представляющего почту (локального) пользователя или из поля From:. При доступности системной идентификации, эти данные следует также копировать в поле заголовка Sender, если информация отличается от адреса в поле From (все имеющиеся поля Sender следует удалить). Система может позволять представляющим почту пользователям переписывать адрес возврата в конверте, но можно ограничить доступ к этому только привилегированными пользователями. Это не предотвращает подмены почтовых адресов, но осложняет такую подмену (см. параграф 7.1).

При таком использовании агентов АДП они несут ответственность за корректность передаваемого сообщения. Механизм проверки корректности и обработка (или возврат) сообщений, некорректность которых обнаружена по прибытии, являются частью интерфейса АДП – ППА (MUA-MTA) и не рассматриваются в данной спецификации.

Протокол представления почты, основанный только на стандарте RFC 822, недопустимо использовать на шлюзах из других (не SMTP) почтовых систем в среду SMTP. Дополнительные данные для конструирования заголовков требуется получать из некоторых источников в другой среде (дополнительные заголовки или конверт).

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

Приложение C. Маршруты Source Route

Исторически поле <reverse-path> содержало в source routing список промежуточных хостов и имя почтового ящика отправителя. Исторически, первым в списке <reverse-path> указывался хост, подавший команду MAIL; сегодня не следует использовать маршруты source route в обратном пути. Подобно этому поле <forward-path> может быть списком хостов source routing и адреса получателя. Однако, в общем случае, в поле <forward-path> следует включать только почтовый ящик и доменное имя получателя, отдавая решение задачи маршрутизации почты на откуп системе DNS. Использование явных маршрутов осуждается (см. Приложение F.2) — хотя серверы и должны быть готовы к получению и обработке таких маршрутов (см. 3.3 и Приложение F.2), клиентам не следует передавать явные маршруты и этот параграф включен в спецификацию только для обеспечения преемственности. Данная спецификация несколько отличается от RFC 821 для предотвращения действий серверов, приводящих к путанице последующие серверы и клиентов, которые не ожидают полной реализации source route.

Для целей трансляции прямой путь может быть маршрутом source route в форме @ONE,@TWO:JOE@THREE, где ONE, TWO, THREE должны быть полными доменными именами. Такая форма используется для того, чтобы можно было отличить адреса от маршрутов. Почтовый ящик (в данном случае, JOE@THREE) представляет собой абсолютный адрес, а маршрут — информацию для доставки. Эти понятия не следует путать.

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

Отметим, что прямой и обратный пути появляются в командах и откликах SMTP, но не являются необходимыми в сообщении (т. е., нет необходимости включения таких путей и особенно описанного здесь синтаксиса в поля To:, From:, CC: и т. п.). И наоборот, для серверов SMTP недопустимо получать информацию на основе этих полей при окончательной доставке сообщения.

Когда, несмотря на приведенные выше рекомендации, список хостов присутствует, этот список является «обратным» маршрутом source route и показывает, что почта транслировалась через каждый хост в списке (первым в списке указан последний по времени транслятор). Этот список используется как source route для возврата отправителю уведомлений о невозможности доставки. Если в нарушение приведенных здесь рекомендаций хост-транслятор добавляет себя в начало списка, он должен использовать имя, которое известно в транспортной среде, куда транслируется почта, а не в среде, откуда почта поступила (если эти имена различаются). Отметим, что такие ситуации могут с легкостью возникать из случаев, когда некоторые транслирующие хосты добавляют свои имена в обратный путь source route, а другие не делают этого, создавая разрывы в маршрутном списке. Это другая причина, по которой серверам при необходимости возврата сообщения следует полностью игнорировать source route и просто использовать домен, указанный в Mailbox.

Приложение D. Сценарии

В этом приложении приведено несколько примеров полных сценариев сеансов SMTP. Знаком C: обозначается отправитель (клиент SMTP), а знаком S: — сервер SMTP.

D.1. Сценарий типовой транзакции SMTP

Рассматриваемый ниже пример показывает передачу сообщения, отправленного Смитом (Smith) с хоста bar.com адресатам Jones, Green, Brown на foo.com. Предполагается, что bar.com контактирует с foo.com напрямую. Почта для Jones и Brown принимается, а Green не имеет почтового ящика на foo.com.

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RCPT TO:<Brown@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

D.2. Сценарий прерванной транзакции SMTP

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RSET
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

D.3. Сценарий с трансляцией

Этап 1 — Отправитель → транслятор.

Хост-отправитель запрашивает у DNS данные для XYZ.COM (адрес получателя) и получает записи DNS MX, указывающие xyz.com, как наиболее предпочтительный хост, а foo.com — как наименее предпочтительный. Отправитель пытается соединиться с xyz.com, но терпит неудачу. Тогда он организует соединение с foo.com, сценарий которого показан ниже:

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<JQP@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@XYZ.COM>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Date: Thu, 21 May 1998 05:33:29 -0700
      C: From: John Q. Public <JQP@bar.com>
      C: Subject: The Next Meeting of the Board
      C: To: Jones@xyz.com
      C:
      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C: John.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

Этап 2 — Транслятор → хост получателя

Хост foo.com, получивший сообщение, запрашивает у DNS данные для xyz.com. Он получает такой же набор записей MX, но не может использовать ни свой адрес, ни любой адрес из списка, который менее предпочтителен, по сравнению с xyz.com. Тогда транслятор организует соединение с xyz.com:

           S: 220 xyz.com Simple Mail Transfer Service Ready
           C: EHLO foo.com
           S: 250 xyz.com is on the air
           C: MAIL FROM:<JQP@bar.com>
           S: 250 OK
           C: RCPT TO:<Jones@XYZ.COM>
           S: 250 OK
           C: DATA
           S: 354 Start mail input; end with <CRLF>.<CRLF>
           C: Received: from bar.com by foo.com ; Thu, 21 May 1998
           C:     05:33:29 -0700
           C: Date: Thu, 21 May 1998 05:33:22 -0700
           C: From: John Q. Public <JQP@bar.com>
           C: Subject:  The Next Meeting of the Board
           C: To: Jones@xyz.com
           C:
           C: Bill:
           C: The next meeting of the board of directors will be
           C: on Tuesday.
           C:                         John.
           C: .
           S: 250 OK
           C: QUIT
           S: 221 foo.com Service closing transmission channel

 

D.4. Сценарий проверки и передачи

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250-VRFY
      S: 250 HELP
      C: VRFY Crispin
      S: 250 Mark Crispin <Admin.MRC@foo.com>
      C: MAIL FROM:<EAK@bar.com>
      S: 250 OK
      C: RCPT TO:<Admin.MRC@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

Приложение E. Другие вопросы, связанные со шлюзами

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

Приложение F. Отмененные возможности RFC 821

Некоторые возможности RFC 821 признаны проблематичными и их не следует использовать в почте Internet.

F.1. Команда TURN

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

F.2. Задаваемая отправителем маршрутизация

RFC 821 использует концепцию явного задания маршрута отправителем для доставки почты с одного хоста на другой через промежуточные трансляторы. Необходимость использования такой маршрутизации в обычной почте отпала после появления в DNS записей MX. Существенный вклад в отказ от такой маршрутизации внес документ RFC 1123, в соответствии с которым после символа @ в адресе должно указываться полное доменное имя (FQDN). Следовательно, единственной причиной поддержки source route является взаимодействие со старыми клиентами SMTP или агентами MUA, а также отладка почтовых систем. Однако такая маршрутизация может быть полезна при возникновении серьезных проблем временного характера (типа релевантности записей DNS).

Серверы SMTP должны продолжать восприятие синтаксиса source route в соответствии с данной спецификацией и RFC 1123. При необходимости серверы могут игнорировать явные маршруты, используя из адреса только доменное имя. При использовании source route сообщение должно пересылаться в первый указанный в адресе домен. В частности, для серверов недопустимо сокращение маршрута source route.

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

F.3. Команда HELO

Как было указано в параграфах 3.1 и 4.1.1, следует отдавать предпочтение команде EHLO, нежели устаревшей команде HELO. Серверы должны принимать и обрабатывать команды HELO для поддержки старых клиентов.

F.4. #-литералы

В RFC 821 указана возможность задания адресов Internet с помощью десятичного представления номера хоста с префиксом #. На практике с появлением TCP/IP актуальность такого представления была утрачена. В настоящее время этот вариант осуждается и недопустим для использования.

F.5. Даты и годы

При включении клиентами и серверами SMTP значений даты в сообщения (например, в поля трассировки) должно использоваться 4-значное представление года. Двухзначное представление осуждается, а трехзначное никогда не допускалось в почтовых системах Internet.

F.6. Дополнительные команды прямой передачи

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

Клиентам не следует предоставлять услуги SEND, SAML или SOML, но серверы их могут реализовать. При реализации этих служб сервером должна использоваться модель, приведенная в спецификации RFC 821, а имена команд должны публиковаться в отклике на команду EHLO.

Адрес автора

John C. Klensin

1770 Massachusetts Ave, Suite 322

Cambridge, MA 02140

USA

EMail: john+smtp@jck.com

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

---

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

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

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

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

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

Заменен RFC 7042.

Network Working Group                                        S. Burleigh
Request for Comments: 5325                NASA/Jet Propulsion Laboratory
Category: Informational                                       M. Ramadas
                                                            ISTRAC, ISRO
                                                              S. Farrell
                                                  Trinity College Dublin
                                                          September 2008

Протокол LTP — мотивация

Licklider Transmission Protocol — Motivation

PDF

Статус документа

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

Примечание IESG

Данный RFC не рассматривается в качестве кандидата на роль стандарта Internet. Документ является согласованным результатом работы исследовательской группы DTN¹ Комитета по исследованиям Internet (IRTF). Дополнительную информацию о процедурах можно найти в RFC 3932.

Аннотация

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

В межпланетной сети Internet, использующей Bundle Protocol, который был разработан исследовательской группой DTN, протокол LTP предназначен для работы в качестве надежного протокола уровня конвергенции между парами смежных узлов межпланетной сети, связанных по радиоканалам (RF) с одним интервалом. LTP выполняет автоматический повтор запросов (ARQ) на передачу данных за счет использования селективных подтверждений доставки. Этот механизм учитывает состояние и не требует какого-либо дополнительного согласования.

Данный документ является результатом работы исследовательской группы DTN и согласован с членами этой группы. Публикация документа как RFC не встретила возражений.

1. Введение

Протокол быстрой передачи LTP разработан для обеспечения надежной передачи данных по каналам с экстремально большими значениями времени кругового обхода и/или частыми разрывами связи. Связь в межпланетном пространстве является наиболее типичным примером таких сред и протокол LTP предназначен, прежде всего, для поддержки надежной дальней связи через межпланетные радиоканалы. В частности, протокол LTP предназначен для обеспечения надежного протокола уровня конвергенции, работающего «под» протоколом DTN [DTN] Bundle [BP], в разворачиваемых DTN средах, где каналы данных характеризуются очень большим временем кругового обхода.

В этом документе рассмотрены мотивы создания протокола LTP, возможности и функции протокола, а также его общее устройство. Этот документ является частью серии RFC, описывающих протокол LTP. Два других документа содержат спецификацию протокола [LTPSPEC] и описание протокольных расширений [LTPEXT].

Протокол назван в честь пионера ARPA/Internet — JCR Licklider.

2. Постановка задачи

2.1. Рабочая среда IPN

Существует множество фундаментальных различий между средами наземных коммуникаций (такими, которые используются в Internet) и рабочими средами, которые могут применяться в межпланетных сетях (IPN³) [IPN].

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

Основной причиной задержки является конечная скорость распространения сигналов. Задержка при прохождении сигнала от Земли до Европы (спутник Юпитера) и обратно составляет от 66 до 100 минут.

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

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

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

Для дальней космической связи, даже не относящейся к сфере деятельности NASA, в настоящее время используется поддерживаемая NASA сеть DSN⁴ [DSN]. Коммуникационные ресурсы в настоящее время полностью расписаны и такое состояние сохраниться в обозримом будущем. Следовательно, радиообмен через DSN требуется планировать заблаговременно и выделяемые ресурсы весьма ограничены.

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

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

• Большое время кругового обхода означает существенную задержку между передачей блока данных и приемом подтверждения доставки от получателя. Если LTP будет откладывать передачу последующих блоков данных до того момента, когда будет подтверждена доставка всех отправленных ранее блоков, дорогостоящие ресурсы каналов дальней космической связи (используемая полоса) будут практически полностью потеряны. Требуется организация множества параллельных «сеансов» передачи данных для предотвращения неполного использования канала связи.

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

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

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

• Кроме того, расчет интервалов тайм-аута для сред, в которых обычно используется LTP, существенно отличается от расчета этих параметров в Internet. Поскольку одновременно может существовать множество параллельных сессий, задержка передачи в любой отдельной сессии в ожидании тайм-аута не снижает производительности соединения в целом. Интервалы тайм-аутов, которые могут быть недопустимыми для TCP, в LTP могут даже не снижать эффективность использования полосы канала.
  Однако полудуплексная двухсторонняя передача данных в LTP делает невозможным использование статистического анализа времени кругового обхода для предсказания значений этого параметра. Время кругового обхода для переданного сегмента N может оказаться на несколько порядков больше аналогичного параметра для сегмента N-1 просто по тому, что между передачей этих сегментов наблюдался период отсутствия связи. Поэтому требуется иной механизм расчета интервалов тайм-аута.

2.2. Почему не TCP или SCTP?

Такие характеристики сред, как большие задержки со значительными вариациями, прерывающаяся связность и сравнительно высокая частота ошибок, делают невозможным использование обычного протокола TCP для сквозной передачи данных в IPN. Используя уравнение для расчета пропускной способности TCP из работы [TFRC], мы можем определить частоту случаев потери (p), при которой может быть достигнута заданная полоса пропускания в установившемся состоянии. Предполагая, что минимальное значение RTT при связи между Землей и Марсом равно 8 минутам (при минимальном расстоянии между планетами на прохождение света между планетами в одном направлении требуется 4 минуты), размер пакета составляет 1500 байтов, а получатель подтверждает каждый второй пакет, и игнорируя пренебрежимо малые компоненты высоких порядков в p (т. е., второй дополнительный член в знаменателе уравнения для пропускной способности TCP), мы получим значения частоты потерь, допустимой для достижения требуемой пропускной способности, показанные в таблице.

 

Пропускная способность	Допустимая частота потерь (p)
10 Мбит/с	4,68*10-12
1 Мбит/с	4,68*10-10
100 кбит/с	4,68*10-8
10 кбит/с	4,68*10-6

 

Отметим, что несмотря на трактовку множества потерь в течение одного периода RTT трактуется как одна потеря при расчете пропускной способности TCP с помощью уравнения [TFRC], приведенные в таблице значения вероятности потерь являются недостижимыми для каналов в дальний космос.

В контексте нашего обсуждения более жесткий расчет пропускной способности TCP, используемый для скоростных каналов (HighSpeed TCP) [HSTCP], просто не рассматривался.

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

Протокол SCTP⁵ [SCTP] может мультиплексировать блоки⁶ (объект данных приложения) для организации множества сессий в одном соединении (в SCTP это называется ассоциацией), как это делается в LTP, но в SCTP также затрачивается множество периодов кругового обхода до того, как начнется передача данных приложений. Очевидно, что такое решение не подходит для использования в средах IPN.

3. Обзор протокола

3.1. Штатная работа

Ниже описана обычная последовательность событий для сеансов передачи LTP.

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

LTP рассматривает каждый блок данных, как состоящий из двух частей — «красной», при доставке которой используются подтверждения и повторы передачи (при необходимости), и «зеленой», для которой предпринимаются попытки доставить без обеспечения гарантий. Размер каждой из частей может быть нулевым, т. е., любой юлок данных может трактоваться целиком, как «красный» или «зеленый». В первом случае попытки передачи блока повторяются, пока не будет получено подтверждение успешной доставки всего блока, а во втором просто предпринимается попытка передать данные без гарантии доставки. Таким образом, LTP может работать, подобно протоколу TCP и UDP одновременно в рамках одной сессии.

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

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

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

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

На следующем этапе выделяется полоса для очереди, в которую помещены сегменты данных блока, помещенные в очередь сегменты, их размеры передаются локальному протоколу канального уровня (это может быть UDP/IP) через поддерживаемый этим протоколом интерфейс API для передачи машине LTP обслуживающей удаленный экземпляр клиента.

Таймер запускается в момент EORP, поэтому при отсутствии отклика он может быть автоматически запущен снова.

Каждый модуль данных локального протокола канального уровня (кадр канального уровня или дейтаграмма UDP) должен содержать целое число сегментов LTP и локальный протокол канального уровня никогда не должен доставлять неполные сегменты LTP приемной машине LTP. Когда в качестве локального протокола канального уровня используется UDP, следует использовать расширение LTP для аутентификации [LTPEXT], чтобы гарантировать целостность данных в тех случаях. От использования этого расширения можно отказаться, если на всем пути обеспечивается пренебрежимо малая вероятность повреждения пакетов (как в некоторых приватных ЛВС) или последствиями повреждения данных в процессе передачи и/или обработки можно пренебречь (как в некоторых случаях при разработке приложений). Когда расширение LTP для аутентификации не используется, протокол LTP требует от локального протокола канального уровня контроля целостности всех принятых сегментов. В частности, локальный протокол канального уровня должен детектировать и отбрасывать принятые поврежденные сегменты.

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

При получении первого сегмента данных для блока принимающая машина запускает сеанс приема для этого блока и уведомляет локальный экземпляр соответствующего клиентского сервиса о начале сеанса. В обычных условиях все сегменты исходной передачи принимаются без ошибок. Следовательно, на получение сегмента данных EORP приемная машина отвечает (a) помещением в очередь для отправки передающей машине сегмента отчета, показывающего завершение приема, и (b) доставкой крайней части блока локальному экземпляру клиентского сервиса; на получение каждого сегмента зеленой части приемная машина реагирует незамедлительной доставкой принятых данных локальному экземпляру клиентского сервиса.

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

Отметим, что по причине однонаправленности потока данных LTP подтверждения LTP (отчеты о получении) не могут прицепляться к сегментам данных TCP и передаются в отдельном типе сегментов.

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

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

На следующем этапе помещенный в очередь сегмент подтверждения отчета незамедлительно передается приемной машине.

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

3.1.1. Сигналы о состоянии канала

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

• ориентацию приемной антенны;

• подстройку транспондера на выбранные частоты передачи и/или приема;

• точная подстройка питания транспондера в последний момент и отключение питания по окончании сеанса.

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

3.1.2. Отложенная передача

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

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

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

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

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

3.1.3. Таймеры

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

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

Расчет выполняется в два этапа, описанных ниже.

• Первое приближение RTT рассчитывается простым удвоением времени прохождения светового луча к получателю с добавлением произвольного значения предполагаемой дополнительной задержки (например, в очередях или при обработке в оконечных точках). Для операций в глубоком космосе такая добавка обычно составит несколько (немного) секунд. Хотя такая добавка представляется аномальной с точки зрения стандартов Internet, она невелика по сравнению со временем прохождения света туда и обратно. Мы предпочли риск запоздалого повтора передачи, который просто задержит доставку одного блока на сравнительно небольшое время, слишком раннему повтору, ведущему к неоправданному расходу пропускной способности и общему снижению производительности.

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

Приведенное ниже обсуждение служит базой для расчетов ожидаемого времени прибытия LTP.

Общее время, требуемое для одного «кругового обхода» (передача и прием исходного сегмента, а затем передача и прием сегмента подтверждения) состоит из перечисленных ниже компонент.

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

• Задержка в выходных очередях. Задержка у отправителя исходного сегмента на ожидание в очереди на передачу и задержка у отправителя подтверждения на ожидание в очереди на передачу.

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

• Время кругового обхода со скоростью света. Время распространения сигнала со скоростью света в обоих направлениях.

• Задержка во входных очередях. Задержка во входной очереди у получателя исходного сегмента и задержка во входной очереди у получателя сегмента подтверждения.

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

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

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

Применяется два механизма снижения задержки в выходных очередях до пренебрежимо малых значений.

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

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

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

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

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

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

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

3.2. Повтор передачи

Потеря или повреждение переданного сегмента может привести к отклонению работы LTP от обычной последовательности событий, описанной выше.

Потеря одного или нескольких сегментов данных красной части, отличных от сегмента EORP, вызывает повторную передачу данных — приемная машина возвращает отчет, указывающий все полученные непрерывные диапазоны красной части (в предположении, что не были получены описанные ниже дискреционные контрольные точки). Отчет о получении обычно передается в одном отчетном сегменте, содержащем уникальный порядковый номер отчета и охват красной части данных. Например, если данные красной части охватывали блок со смещениями [0:1000] и были получены все данные, кроме диапазона [500:600], сегмент отчета будет содержать уникальный номер (скажем, 100), а охват [0:1000] будет указан двумя записями — (0:500) и (600:1000). Максимальный размер сегмента отчета, как и всех сегментов LTP, ограничивается значением MTU в канале данных. Если было потеряно много дискретных сегментов одного большого блока и/или значение MTU в канале данных достаточно мало, может потребоваться создание множества сегментов отчета. В таких случаях LTP создает нужное число сегментов данных и делит область охвата красной части между сегментами отчетов так, что каждый из них может сохранять самостоятельность. Например, при генерации трех отчетных сегментов для красной части [0:1000000] они могут иметь вид: RS 19 с охватом [0:300000], RS 20 с охватом [300000:950000] и RS 21 с охватом [950000:1000000]. Во всех случаях таймер запускается при отправке каждого сегмента отчета о получении данных.

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

• Выключение таймера для контрольной точки, указанной полученным сегментом отчета (при наличии).

• Размещение в очереди подтверждения приема отчетного сегмента для отключения таймера повтора на приемной стороне). Этот сегмент передается при ближайшей возможности.

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

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

При получении сегмента подтверждения отчета приемная сторона выключает таймер для этого сегмента.

При получении сегмента контрольной точки с отличным от 0 порядковым номером приемная машина выполняет указанные ниже действия.

• Возвращение отчета о приеме, содержащего нужное количество отчетных сегментов для информирования о всех принятых данных в сфере охвата упомянутого сегмента отчета и запуск таймера для каждого сегмента.

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

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

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

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

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

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

3.3. Ускоренный повтор передачи

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

• Любой сегмент данных красной части до EORP можно дополнительно пометить как контрольную точку. Получение каждой такой дискреционной точки будет вызывать отправку приемной машиной сегмента отчета.

• В любой момент исходной передачи красной части блока (т. е. до получения любого сегмента данных зеленой части блока) принимающая машина может в одностороннем порядке передать дополнительные отчеты о получении. Отметим, что режим Immediate протокола CFDP является примером таких асинхронных отчетов о получении [CFDP]. Отчеты о получении создаются для ускорения повторной передачи точно так же, как обычные отчеты о получении.

3.4. Прерывание сессии

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

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

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

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

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

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

Потеря сегмента прерывания или соответствующего отклика на этот сегмент приводит к тайм-ауту. В этом случае прерывающая сессию машина повторно передает сегмент прерывания.

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

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

Поэтому имеется потребность в защите конфиденциальности и целостности, а также предотвращении DoS¹⁰-атак.

В частности, проблемы DoS более существенны для LTP по сравнению с типичными протоколами Internet, поскольку LTP по своей природе сохраняет состояния достаточно долго и использует продолжительное время ожидания. Кроме того, сброс узлов LTP для восстановления при атаке может быть достаточно сложен. Таким образом, любой злоумышленник, способный влиять на передачу LTP, может организовать серьезную DoS-атаку на приемник LTP.

Рассмотрим, например, наземную ситуацию, где LTP применяется в сети редко расположенных сенсоров. Здесь можно организовать DoS-атаки, в результате которых узлы потеряют критически важную информацию, такую как обновления расписания связи. В таких случаях одна успешная DoS-атака может полностью отключить узел от сети и потребовать его сброса при физическом посещении.

Даже при использовании LTP в глубоком космосе нужно учитывать организуемые с Земли атаки, в частности возможность вставки сообщений в текущий сеанс (обычно без просмотра байтов в предшествующих сообщениях сессии). Такие атаки вероятны при наличии сбоев межсетевых экранов на различных узлах сети или в результате применения троянских программ на легитимных хостах. Многие атаки со вставкой сообщений зависят от возможности атакующего корректно «предсказать» состояния узлов LTP, но опыт показывает, что сделать такие предсказания проще, чем это кажется [DDJ].

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

Уровень приложений (выше LTP)

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

Уровень LTP

Заголовок аутентификации (подобно IPsec [AH]) может помочь в защите от атак с воспроизведением (replay) и других поддельных пакетов. Однако злоумышленнику все еще доступны заголовки LTP, передаваемые через эфир. Такой подход также требует той или иной инфраструктуры управления ключами для обеспечения строгой проверки подлинности, что не всегда приемлемо. Заголовок аутентификации может ослабить многие DoS-атаки.

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

Кроме того, на уровне LTP можно применять различные решения для снижения вероятности успешных DoS-атак. В частности, можно потребовать случайного выбора некоторых полей заголовков (например, номеров сессий).

Уровень канала данных (ниже LTP)

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

В свете сказанного LTP включает в себя механизмы защиты, перечисленные ниже.

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

Необязательный механизм LTP является расширением сегмента LTP со случайным числовым значением cookie перед содержимым сегмента. За счет увеличения числа байтов в сегменте, которое не может быть точно предсказано поддельным источником данных, и требования отбрасывать сегменты, в которых нет корректного значения этих байтов, механизм cookie усложняет организацию DoS-атак на машины LTP.

Упомянутые механизмы подробно описаны в документе расширений LTP [LTPEXT].

В дополнение к этому порядковые номера в контрольных точках и отчетах LTP должны иметь случайные целочисленные значения, а разработчикам рекомендуется также выбирать случайные номера для сессий. Это повышает уровень защищенности от DoS-атак. Рекомендации по выбору случайных значений приведены в [PRNG].

5. Взаимодействие с IANA

См. одноименные разделы в документах [LTPSPEC] и [LTPEXT].

6. Благодарности

Большое спасибо Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss за их вклад в разработку протокола и архитектуры устойчивых к задержкам сетей (DTN).

Часть описанного здесь исследования была выполнена в Jet Propulsion Laboratory, California Institute of Technology по контракту с National Aeronautics and Space Administration (DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; NASA Contract NAS7-1407).

Спасибо также Shawn Ostermann, Hans Kruse и Dovel Myers из Ohio University за их предложения и советы при выборе решений. Эта работа была выполнена, когда Manikantan Ramadas был аспирантом EECS Dept., Ohio University в Internetworking Research Group Laboratory.

Часть этой работы была выполнена в Trinity College Dublin в рамках контракта SeNDT, финансируемого исследовательским инновационным фондом Enterprise Ireland.

7. Литература

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

[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, «Licklider Transmission Protocol — Specification», RFC 5326, September 2008.

[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, «Licklider Transmission Protocol — Security Extensions», RFC 5327, September 2008.

[AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[BP] Scott, K. and S. Burleigh, «Bundle Protocol Specification», RFC 5050, November 2007.

[CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 2002.

[DDJ] I. Goldberg and E. Wagner, «Randomness and the Netscape Browser», Dr. Dobb’s Journal, 1996, (pages 66-70).

[DSN] Deep Space Mission Systems Telecommunications Link Design Handbook (810-005) web-page, «http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/«

[DTN] K. Fall, «A Delay-Tolerant Network Architecture for Challenged Internets», In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, Aug 2003.

[IPN] InterPlanetary Internet Special Interest Group web page, «http://www.ipnsig.org«.

[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, «TCP Friendly Rate Control (TFRC): Protocol Specification», RFC 3448, January 2003.

[HSTCP] Floyd, S., «HighSpeed TCP for Large Congestion Windows», RFC 3649, December 2003.

[SCTP] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[PRNG] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

Адреса авторов

Scott C. Burleigh

Jet Propulsion Laboratory

4800 Oak Grove Drive

M/S: 301-485B

Pasadena, CA 91109-8099

Telephone: +1 (818) 393-3353

Fax: +1 (818) 354-1075

EMail: Scott.Burleigh@jpl.nasa.gov

Manikantan Ramadas

ISRO Telemetry Tracking and Command Network (ISTRAC)

Indian Space Research Organization (ISRO)

Plot # 12 & 13, 3rd Main, 2nd Phase

Peenya Industrial Area

Bangalore 560097

India

Telephone: +91 80 2364 2602

EMail: mramadas@gmail.com

Stephen Farrell

Computer Science Department

Trinity College Dublin

Ireland

Telephone: +353-1-896-1761

EMail: stephen.farrell@cs.tcd.ie

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

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

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

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

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

---

1Delay Tolerant Networking — устойчивая к задержкам сеть.

Network Working Group                                       S. Floyd
Request for Comments: 5348                                      ICIR
Obsoletes: 3448                                           M. Handley
Updates: 4342                              University College London
                                                           J. Padhye
                                                           Microsoft
                                                           J. Widmer
                                                              DoCoMo
                                                      September 2008

 

Дружественный к TCP контроль скорости (TFRC) — спецификация протокола

TCP Friendly Rate Control (TFRC): Protocol Specification

PDF

Статус документа

В этом документе содержится проект стандартного протокола Internet для сообщества Internet и приглашение к дискуссии в целях развития и совершенствования протокола. Информацию о текущем состоянии стандартизации протокола можно найти в текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Аннотация

В этом документе приведена спецификация протокола TFRC¹, который представляет собой механизм контроля насыщения для потоков с индивидуальной адресацией в среде Internet, обеспечивающей доставку по-возможности². Этот механизм обеспечивает достаточно беспристрастное деление полосы с конкурирующими потоками TCP, но отличается значительно меньшими временными вариациями пропускной способности по сравнению с TCP, что делает этот механизм более подходящим для таких приложений, как телефония или потоковая передача, где важна постоянная скорость потока данных.

Данный документ отменяет действие RFC 3448 и является обновлением RFC 4342.

1. Введение

В этом документе содержится спецификация TFRC — механизма контроля насыщения, предназначенного для потоков с индивидуальной адресацией в среде Internet при одновременной передаче с трафиком TCP [FHPW00]. Вместо задания полного протокола в данном документе просто дается спецификация механизма контроля насыщения, который может использоваться в транспортных протоколах типа DCCP (Datagram Congestion Control Protocol) [RFC4340] для приложений, включающих сквозной контроль насыщения на прикладном уровне, или в контексте контроля насыщения на оконечных точках [BRS99]. В документе не рассматриваются форматы пакетов и вопросы надежности доставки. Связанные с реализацией механизма вопросы рассмотрены кратко в главе 8.

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

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

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

Для некоторых приложений (например, звуковых) требуется обеспечение фиксированного интервала времени между передачей последовательных пакетов и варьирование размера сегментов (вместо изменения скорости передачи пакетов) в ответ на возникновение перегрузки. Механизм контроля насыщения, предложенный в этом документе, для таких приложений не подходит, однако эту задачу решает механизм TFRC-PS⁴, являющийся вариантом TFRC для приложений с фиксированной частотой передачи и изменением размера пакетов при возникновении насыщения. Спецификация TFRC-PS содержится в [RFC4828].

Механизм TFRC основан на работе принимающей стороны с расчетом параметров контроля насыщения (частоты фактов потери пакетов) на стороне получателя, а не отправителя. Такой способ хорош для приложений, в которых отправителем является большой сервер, обслуживающий множество одновременных соединений, а получатели имеют достаточно памяти и процессорных ресурсов для выполнения требуемых расчетов. Кроме того, реализованный на приемной стороне механизм лучше подходит для контроля насыщения в системах с групповой адресацией. Однако возможна реализация TFRC на серверной стороне, как в профиле CCID-3⁵ протокола DCCP [RFC4342].

Этот документ отменяет действие RFC 3448. В транспортном протоколе DCCP⁶ [RFC4340] профили CCID-3 [RFC4342] и CCID-4 [CCID-4] задают использование TFRC в соответствии с RFC 3448. Разработчикам CCID-3 и CCID-4 следует использовать этот документ взамен RFC 3448 для спецификации TFRC.

Нормативная часть спецификации TFRC приведена в главах 3 — 6. В главе 7 рассматриваются реализации механизма на серверах, в главе 8 — вопросы реализации механизма, а в главе 9 рассмотрены отличия от RFC 3448.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

В Приложении A приводится список использованных в документе технических терминов.

3. Механизм протокола

Для контроля насыщения TFRC напрямую использует уравнение пропускной способности для разрешенной скорости передачи, как функции от частоты фактов потери пакетов и времени кругового обхода. Для беспристрастной конкуренции с TCP, механизм TFRC использует принятое в TCP уравнение для пропускной способности, выражающее скорость передачи TCP, как функцию от частоты фактов потери пакетов, времени кругового обхода и размера сегментов. Определим факт потери, как случай утраты одного или более маркированного пакета из окна данных; маркированными считаются пакеты, помеченные явным индикатором насыщения ECN⁷ [RFC3168].

В общем виде механизм контроля насыщения TFRC можно описать следующим образом:

• Получатель определяет частоту фактов потери пакетов и передает эту информацию отправителю.
• Отправитель использует эти сообщения от получателя для определения времени кругового обхода (RTT⁸).
• Значения частоты фактов потери и RTT передаются в уравнение пропускной способности TFRC и результирующая скорость передачи ограничена значением не более удвоенной скорости приема.
• Отправитель подстраивает скорость передачи в соответствии с допустимой скоростью передачи X.

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

3.1. Уравнение для пропускной способности TCP

Любое реалистичное выражение пропускной способности TCP, как функции RTT и вероятности потери пакетов, следует рассматривать, как подходящее для использования с TFRC. Однако следует отметить, что используемое для пропускной способности TCP уравнение должно отражать поведение повторов передачи по тайм-ауту, поскольку это поведение доминирует при определении пропускной способности TCP в условиях высокой вероятности потерь. Отметим также, что допущения, принятые относительно вероятности потерь в уравнении для пропускной способности, зависят от реального механизма определения вероятности потерь. Хотя это допущение не вполне соответствует приведенному ниже уравнению для пропускной способности и описанным механизмам измерения, оно достаточно хорошо подходит на практике.

Уравнение пропускной способности, которое в настоящее время требуется использовать в TFRC, является слегка упрощенным вариантом уравнения для Reno TCP из работы [PFTK98]. В идеальном случае уравнение для пропускной способности следовало бы создавать на основе SACK⁹ TCP, однако тесты и эксперименты показывают, что различия между двумя уравнениями достаточно малы [FF99] (Приложение B).

Уравнение для средней скорости передачи TCP (в байтах в секунду) X_Bps имеет вид:

                               s
  X_Bps = ----------------------------------------------------------
          R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))

где:

X_Bps — средняя скорость передачи TCP (байт/сек); параметр X_Bps идентичен X_calc в RFC 3448;

s — размер сегмента (байт) с учетом заголовков транспортного уровня и IP;

R — время кругового обхода в секундах;

p — вероятность потерь (0 — 1.0) — доля потерянных пакетов в от общего числа переданных пакетов;

t_RTO — тайм-аут повторной передачи TCP в секундах;

b — максимальное число пакетов, подтверждаемых одним пакетом TCP ACK.

Выбор значения тайм-аута повторной передачи TCP — t_RTO.

Реализациям следует использовать значение t_RTO = 4*R. Возможно использование более точного метода расчета t_RTO. Реализации могут также выбирать в качестве t_RTO значение max(4*R, 1 секунда) в соответствии с рекомендуемым для значения RTO минимумом [RFC2988].

Выбор параметра b для отложенных подтверждений.

Некоторые современные реализации TCP используют отложенные подтверждения, передавая один пакет подтверждения для каждой пары принятых пакетов данных. Однако TCP также позволяет передавать подтверждения для каждого принятого пакета данных. Для пересмотренных механизмов контроля насыщения TCP [RFC2581bis] в настоящее время задает алгоритм отложенных подтверждений, который следует использовать. Однако [RFC2581bis] рекомендует увеличивать размер окна насыщения при предотвращении перегрузки по одному сегменту за период RTT даже при использовании отложенных подтверждений, в соответствии с уравнением пропускной способности TCP для случая b = 1. На основе экспериментальных данных [RFC2581bis] позволяет увеличивать окно насыщения в процессе замедленного старта, что также соответствует уравнению пропускной способности TCP для случая b = 1. Таким образом, использование b = 1 согласуется с [RFC2581bis]. Рекомендуется устанавливать значение b = 1.

При t_RTO=4*R и b=1 уравнение для пропускной способности X_Bps (скорость передачи TCP в байтах за секунду) может быть упрощено до:

                                s
   X_Bps = -----------------------------------------------
           R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))

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

Пропускную способность можно также выразить в X_pps (пакет/сек)

X_pps = X_Bps/s

Параметры s (размер сегмента), p (вероятность потерь) и R (RTT) должны измеряться или рассчитываться реализацией TFRC. Измерение s описано в параграфе 4.1, измерение R — в параграфе 4.3, а измерение p — в разделе 5. В оставшейся части документа скорости передачи данных измеряются байтами в секунду, если явно не указано иное.

3.2. Содержимое пакетов

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

3.2.1. Пакеты данных

Каждый пакет данных, передаваемый отправителем, содержит следующую информацию:

• Порядковый номер. Этот номер должен увеличиваться на 1 с каждым переданным пакетом. Поле должно быть достаточно большим, чтобы в списке недавних пакетов получателя не появлялись разные пакеты с одинаковым порядковым номером.
• Временная метка момента передачи. Будем обозначать ts_i временную метку пакета с порядковым номером i. Разрешение для временных меток в общем случае следует измерять в миллисекундах.Эти временные метки используются получателем для определения потерь пакетов, которые следует отнести к одному событию (факту потери). Метки получатель возвращает отправителю в качестве «эхо» для того, чтобы тот мог оценить время кругового обхода (это нужно для отправителей, не сохраняющих временных меток переданных пакетов).Отметим, что существует альтернативный вариант использования временных меток, когда значение метки инкрементируется каждую четверть периода кругового обхода; такие метки могут служить для отнесения потерь пакетов к одному факту потери в контексте протокола, где это понятно как отправителю, так и получателю, а отправитель сохраняет временные метки переданных пакетов.
• Оценка времени кругового обхода отправителем. Оценка, передаваемая в пакете i обозначается R_i. Оценка времени кругового обхода используется получателем вместе с временными метками для определения множества потерь пакетов, относящихся к одному событию.Если отправитель передает передает грубые «временные метки», которые увеличиваются каждую четверть периода кругового обхода, как описано выше, такому отправителю не нужно передавать свою оценку времени кругового обхода.

3.2.2. Пакеты обратной связи

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

• Временная метка последнего принятого пакета (t_recvdata). Если последний принятый пакет имеет номер i, то t_recvdata = ts_i. Эта временная метка используется отправителем для оценки времени кругового обхода и требуется только в тех случаях, когда отправитель не сохраняет временные метки переданных пакетов данных.
• Интервал времени между приемом последнего пакета и генерацией данного пакета обратной связи. Будем обозначать этот интервал t_delay.
• Оценка получателем скорости приема данных в предыдущем периоде кругового обхода. Будем обозначать этот интервал X_recv.
• Текущее значение вероятности потери по оценке получателя (p).

4. Протокол отправителя данных

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

Для протокола на передающей стороне зададим следующие этапы:

• измерение среднего размера передаваемого сегмента;
• инициализация отправителя;
• реакция отправителя на получение пакета обратной связи;
• поведение отправителя по завершении отсчета таймера обратной связи;
• предотвращение осцилляций (опционально);
• планирование передачи пакетов и допустимых пиков.

4.1. Измерение размера сегмента

Отправитель TFRC использует размер сегмента s в уравнении пропускной способности, при установке максимальной скорости приема, минимальной и начальной скорости передачи, а также значения таймера обратной связи. Получатель TFRC может использовать средний размер сегмента s при инициализации истории потерь. Как указано в параграфе 6.3.1, если получатель TFRC не знает размера сегмента, используемого отправителем, он может использовать взамен при инициализации истории потерь среднее число принимаемых в секунду пакетов.

Размер сегмента s обычно известен приложению, но возможны два исключения:

1. Размер сегментов меняется естественным образом в зависимости от данных. В этом случае, хотя размер сегментов меняется, его вариации не отражаются на скорости передачи. Отправитель TFRC может рассчитать размер сегмента или использовать максимальное значение размера сегмента s.
2. Для контроля насыщения приложение может менять размер сегментов, а не скорость их передачи. Это обычная практика для аудио-приложений, в которых пакеты данных передаются с фиксированным интервалом, требуемым для представления каждого пакета. Для таких приложений требуется совершенно иной способ измерения параметров.

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

Второй класс приложений рассматривается отдельно в документе, посвященном TFRC-PS [RFC4828]. В оставшейся части этого раздела предполагается, что отправитель может оценить размер сегмента и контроль насыщения осуществляется за счет управления числом пакетов, передаваемых за секунду.

4.2. Инициализация отправителя

Начальные значения X (допустимая скорость передачи, в байт/сек) и tld¹¹ (время последнего удвоения в процессе замедленного старта, в секундах) являются неопределенными, пока не будут установлены, как описано ниже. Если отправитель готов передавать данные, когда у него еще нет результатов измерения периода кругового обхода, в качестве X используется скорость s байт/с для сегмента размером s, для таймера обратной связи устанавливается значение 2 секунды, а для tld — 0 или -1 (если это подходит). При получении первого результата измерения времени кругового обхода (например, после первого пакета обратной связи, обмена SYN-пакетами на этапе организации соединения или из предшествующего соединения [RFC2140]), в качестве tld используется текущее значение времени кругового обхода, для X устанавливается значение initial_rate, определенное, как W_init/R для W_init в соответствии с [RFC3390]:

initial_rate = W_init/R
W_init = min(4*MSS, max(2*MSS, 4380))

При расчете W_init вместо максимального размера сегмента (MSS¹²) отправителю TFRC следует использовать максимальный размер сегмента, который используется в начальный период кругового обхода, если это значение известно отправителю TFRC в момент инициализации X.

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

В Приложении B объясняются причины для установки начального значения таймера обратной связи TFRC 2 секунды, взамен значения 3 секунды, рекомендуемого для таймера повтора передачи TCP [RFC2988].

4.3. Поведение отправителя при получении пакета обратной связи

Отправитель знает текущее значение допустимой скорости передачи X и поддерживает оценку текущего времени кругового обхода R. Отправитель также поддерживает параметр X_recv_set, включающий несколько недавних значений X_recv (обычно два).

Инициализация. X_recv_set инициализируется одним значением Infinity¹³. Возможна инициализация X_recv_set взамен Infinity достаточно большим числом (например, наибольшим целым числом в системе).

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

1. Расчет нового значения периода кругового обхода по формуле:

   R_sample = (t_now - t_recvdata) - t_delay

   Как было указано в параграфе 3.2.2, значение t_delay показывает время, затраченное на приемной стороне.

2. Обновление оценки времени кругового обхода:

         If no feedback has been received before {
             R = R_sample;
         } Else {
             R = q*R + (1-q)*R_sample;
         }

   Точное значение постоянной q не имеет существенного значения для TFRC, но по умолчанию рекомендуется использовать значение 0,9.

3. Обновление значения тайм-аута:

   RTO = max(4*R, 2*s/X)

4. Обновление значения допустимой скорости передачи с использованием переменных t_mbi и recv_limit:t_mbi — максимальный интервал снижения скорости 64 секунды.recv_limit — предельное значение скорости передачи, рассчитанной из X_recv_set.Эта процедура также использует процедуры Maximize X_recv_set() и Update X_recv_set(), определенные ниже.Псевдокод процедуры обновления значения допустимой скорости имеет вид:

         If (если весь интервал, закрываемый пакетом обратной связи, характеризуется 
               ограниченной передаче данных) {
             If (пакет обратной связи говорит о новом факте потерь или росте частоты
                          потерь p) {
                 уменьшить вдвое элементы X_recv_set;
                 X_recv = 0.85 * X_recv;
                 Maximize X_recv_set();
                 recv_limit = max(X_recv_set);
             } Else {
                 Maximize X_recv_set();
                 recv_limit = 2 * max (X_recv_set);
             }
         } Else {                      // типичное поведение
             Update X_recv_set();
             recv_limit = 2 * max (X_recv_set);
         }
         If (p > 0) {          // фаза предотвращения перегрузки
             рассчитать X_Bps с использованием уравнения пропускной способности TCP
             X = max(min(X_Bps, recv_limit), s/t_mbi);
         } Else if (t_now - tld >= R) {
             // начальная процедура замедленного старта
             X = max(min(2*X, recv_limit), initial_rate);
             tld = t_now;
         }

5. При использовании механизма подавления осцилляций рассчитывается мгновенная скорость передачи X_inst в соответствии с параграфом 4.5.
6. Таймер обратной связи сбрасывается и устанавливается на RTO секунд.

Процедура максимизации X_recv_set сохраняет наибольший элемент X_recv_set и новое значение X_recv:

      Maximize X_recv_set():
          добавить X_recv к X_recv_set;
          удалить начальное значение Infinity из X_recv_set, если оно еще не удалено;
          установить текущее время в качестве временной метки наибольшего элемента;
          удалить все элементы, кроме наибольшего.

Процедура обновления X_recv_set сохраняет набор значений X_recv с временными метками из двух последних периодов кругового обхода.

      Update X_recv_set():
          добавить X_recv к X_recv_set;
          Удалить из X_recv_set значения, не относящиеся к двум последним периодам RTT.

Определение интервала ограниченной передачи данных.

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

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

Если пакет обратной связи говорит, что скорость X_recv равна 0 (т. е., первый пакет обратной связи), отправитель не рассматривает весь интервал, покрываемый этим пакетом, как интервал с ограниченной передачей данных.

X_recv_set и первый пакет обратной связи.

Поскольку X_recv_set инициализируется с одним элементом Infinity, для recv_limit устанавливается значение Infinity на два первых интервала кругового обхода в соединении. В результате скорость передачи не ограничивается скоростью приема в течение данного периода. Это позволяет избежать проблем, связанных с ограничением скорости передачи данных по значению X_recv из первого пакета обратной связи.

Интервал, покрываемый пакетом обратной связи.

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

Отклик на потери в период ограниченной передачи.

В TFRC после начальной процедуры замедленного старта отправитель всегда обновляет расчетное значение скорости передачи X_Bps (после того, как будет получен пакет обратной связи) и допустимая скорость передачи X всегда ограничена значением X_Bps. Однако в периоды ограниченной передачи, когда реальная скорость обычно ниже X_Bps, скорость передачи остается ограниченной значением recv_limit, получаемым из X_recv_set. Если отправитель ограничивает передачу данных (возможно с изменением скорости от одного периода кругового обхода к другому) и наблюдаются потери данных, мы уменьшаем значение элемента X_recv_set для снижения допустимой скорости передачи.

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

Начальная процедура замедленного старта.

Отметим, что p=0 говорит о том, что отправитель еще не знает о фактах потерь и находится в начальной фазе замедленного старта. В этой фазе отправитель может приблизительно удваивать скорость передачи в каждый период кругового обхода, пока не начнутся потери. Параметр initial_rate term в п. 4) определяет минимальную дозволенную скорость передачи в течение замедленного старта.

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

Минимальная дозволенная скорость передачи.

Параметр s/t_mbi при p > 0 обеспечивает отправителю возможность передачи по крайней мере одного пакета каждые 64 секунды.

4.4. Завершение отсчета таймера обратной связи

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

В этом параграфе используется переменная recover_rate. Если отправитель TFRC бездействует с момента запуска таймера обратной связи, допустимая скорость передачи не устанавливается ниже recover_rate. В этой спецификации для recover_rate устанавливается значение initial_rate (см. параграф 4.2). В будущих вариантах спецификации могут быть заданы другие значения recover_rate.

При завершении отсчета таймера обратной связи отправитель должен:

1. Снизить дозволенную скорость передачи вдвое.Если в момент завершения отсчета таймера у отправителя имелось хотя бы одно измерение RTT, допустимая скорость передачи снижается путем изменения X_recv_set в соответствии с приведенным ниже псевдокодом (включая п. 2)). В общем случае скорость передачи ограничена значением не более двух X_recv. Изменение X_recv_set ограничивает скорость передачи, но позволяет отправителю выполнять процедуру замедленного старта с удвоением скорости передачи в каждый период RTT, если пакеты обратной связи не говорят о потерях.Если отправитель бездействовал с момента запуска таймера обратной связи и X_recv < recover_rate, дозволенная скорость передачи не снижается вдвое и X_recv_set не меняется. Это предотвращает снижение дозволенной скорости до значений меньше половины recover_rate в результате бездействия.В общем случае допустимая скорость передачи снижается вдвое в ответ на завершение отсчета таймера обратной связи. Детали приведенного ниже псевдокода зависят от состояния отправителя — процесс замедленного старта, предотвращение перегрузки с ограничением по X_recv или предотвращение перегрузки с ограничением на основе уравнения пропускной способности.

         X_recv = max (X_recv_set);
         If (у отправителя нет значения RTT, не было получено пакетов
             обратной связи и не наблюдалось бездействия с момента 
             запуска таймера обратной связи) {
             // У отправителя пока нет значений X_Bps и recover_rate.
             // Дозволенная скорость снижается вдвое.
             X = max(X/2, s/t_mbi);
         } Else if (((p>0 && X_recv < recover_rate) or (p==0 && X < 2 * recover_rate)) 
                и отправитель бездействовал с момента запуска таймера обратной связи) {
             // Не снижать вдвое дозволенную скорость передачи.
             Ничего не делать
         } Else if (p==0) {
             // Еще нет значения X_Bps.
             // Снизить вдвое дозволенную скорость передачи.
             X = max(X/2, s/t_mbi);
         } Else if (X_Bps > 2*X_recv)) {
             // Значение 2*X_recv уже ограничивает скорость передачи.
             // Снизить вдвое дозволенную скорость передачи.
             Update_Limits(X_recv;)
         } Else {
             // Скорость передачи ограничена X_Bps, а не X_recv.
             // Снизить вдвое дозволенную скорость передачи.
             Update_Limits(X_Bps/2);
         }

   Значение s/t_mbi ограничивает снижение скорости (по крайней мере 1 пакет за 64 секунды).

   Процедура Update_Limits() использует переменную timer_limit для ограничения скорости передачи, рассчитанной по завершению отсчета таймера обратной связи, как показано ниже:

         Update_Limits(timer_limit):
             If (timer_limit < s/t_mbi)
                 timer_limit = s/t_mbi;
             Заменить содержимое X_recv_set одним элементом timer_limit/2;
             Пересчитать X в соответствии с п. 4) параграфа 4.3;

2. Запустить таймер обратной связи на max(4*R, 2*s/X) секунд.

Если отправитель ограничивал передачу, но не простаивал с момента запуска таймера обратной связи, возможно завершение отсчета таймера в результате потери пакетов обратной связи в сети. В таких случаях таймер обратной связи является механизмом детектирования таких потерь, подобно таймеру повтора передачи в TCP.

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

Снижение отправителем TFRC скорости передачи по таймеру обратной связи похоже на уменьшение размера окна насыщения TCP по истечении каждых RTO периода бездействия для TCP с поддержкой Congestion Window Validation [RFC2861].

4.5. Предотвращение осцилляций

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

        Если ранее не было получено пакетов обратной связи
            R_sqmean = sqrt(R_sample);
        иначе
            R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);

Таким образом, R_sqmean изменяется пропорционально квадратному корню измеренного значения RTT. Константу q2 следует устанавливать по аналогии с q; по умолчанию рекомендуется использовать значение q2=0,9.

При sqrt(R_sample) > R_sqmean текущее время кругового обхода превышает среднее значение, что говорит о возможном увеличении задержки в очереди. В таких случаях скорость передачи снижается для минимизации осцилляций задержки в очередях.

Отправитель получает базовое значение дозволенной скорости передачи X, как описано в п. 4) параграфа 4.3. После этого рассчитывается новое мгновенное значение скорости передачи:

      X_inst = X * R_sqmean/sqrt(R_sample);
      If (X_inst < s/t_mbi)
          X_inst = s/t_mbi;

Благодаря использованию квадратного корня в общем случае мгновенная скорость передачи X_inst незначительно отличается от дозволенной скорости X. Например, в некой экстремальной ситуации, когда текущее значение RTT (R_sample) вдвое превышает среднее значение, sqrt(R_sample) будет отличаться от R_sqmean приблизительно в 1, 44 раза и дозволенная скорость будет снижаться путем умножения на коэффициент приблизительно равный 0,7.

Отметим, что такое изменение поведения для предотвращения осцилляций требуется не во всех случаях, особенно в тех случаях, когда уровень статистического мультиплексирования в сети достаточно велик. Отметим также, что подавление осцилляций может вызывать проблемы для соединений, на которых время кругового обхода слабо связано с задержкой в очередях (например, в беспроводных средах при частых изменениях маршрутизации). Однако такую возможность следует реализовать поскольку она улучшает поведение TFRC в некоторых средах с низким уровнем статистического мультиплексирования. Работа этого механизма проиллюстрирована в параграфе 3.1.3 документа [FHPW00]. Если подавление осцилляций не поддерживается, реализации следует использовать очень малое значение весового коэффициента q при определении среднего времени кругового обхода.

4.6. Планирование передачи пакетов

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

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

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

Например, реализация протокола может рассчитывать интервал между пакетами (t_ipi) следующим образом:

t_ipi = s/X_inst;

Пусть t_now показывает текущее время, а i является натуральным числом (i = 0, 1, …) и t_i показывает номинальное время передачи i-го пакета. Тогда номинальное время t_(i+1) можно рекурсивно определить следующим образом:

t_0 = t_now,
t_(i+1) = t_i + t_ipi.

Отправителя TFRC разрешается накапливать «кредиты на передачу» за неиспользованное для передачи время в течение последних T секунд отправителю разрешено передавать за неиспользованное номинальное время t_j в пока t_j < t_now — T для T, равного времени кругового обхода.

5. Расчет частоты потерь (p)

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

5.1. Детектирование потерь и маркированных пакетов

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

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

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

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

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

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

Если перед пакетами с маркерами ECN была возможна потеря пакетов¹⁴, детектированием факта насыщения считается потеря первого пакета. Например, если получатель принимает пакет с порядковым номером n-1, за которым следует немаркированный пакет с порядковым номером n+1, а затем маркированный пакет с порядковым номером n+2, тогда получатель обнаруживает насыщение по приему пакета n+2. Начало обнаруженного факта перегрузки связано с потерей пакета n. Рекомендации параграфа 5.2 позволяют определить принадлежность потерь и маркированных пакетов к одному или нескольким фактам потерь.

5.2. Преобразование истории потерь в факты потерь

TFRC требует устойчивости к нескольким последовательным потерям пакетов или приему маркированных пакетов, когда эти события относятся к одному факту потери. Это похоже на поведение протокола TCP, который (обычно) лишь однократно за период RTT уменьшает наполовину окно насыщения. Таким образом, получатель должен отобразить историю потери пакетов в запись о факте потери, трактуя как факт потери утрату одного или более пакетов или прием маркированных одного или более пакетов в течение периода RTT. Для выполнения такого отображения получателю нужно знать значение RTT, которое обычно периодически сообщается отправителем в форме управляющей информации, присоединяемой в конце пакета данных. Для TFRC способ передачи результатов измерения RTT получателю не имеет значения, однако рекомендуется использовать для этого рассчитанное отправителем значение RTT (R в параграфе 4.3).

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

S_loss — порядковый номер потерянного пакета;

S_before — порядковый номер последнего пакета, прибывшего с номером меньше S_loss прежде любого пакета с номером, превышающим S_loss;

S_after — порядковый номер первого пакета, прибывшего с после пакета S_before, с порядковым номером больше S_loss;

S_max — наибольший порядковый номер.

Следовательно, S_before < S_loss < S_after <= S_max.

T_loss — номинальное время, когда должен был прибыть потерянный пакет;

T_before — время приема пакета S_before;

T_after — время прибытия пакета S_after.

Отметим, что T_before < T_after.

Для потерянного пакета S_loss можно интерполировать номинальное «время прибытия» на основе времени прибытия пакетов S_before и S_after:

T_loss = T_before + ((T_after — T_before) * (S_loss - S_before)/(S_after - S_before))

Для случая перехода порядковых номеров через максимальное значение (0), предположим, что S_MAX = 2^b, где b — размер принятого в реализации поля порядковых номеров в битах. В этом случае мы можем интерполировать время прибытия T_loss следующим образом:

T_loss = T_before + (T_after — T_before) * Dist(S_loss, S_before)/Dist(S_after, S_before)

где

Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX

Если было определено, что потеря пакета S_old явилась началом предыдущего факта потери и мы детектировали потерю пакета S_new, можно интерполировать номинальное время прибытия пакетов S_old и S_new (T_old и T_new, соответственно).

Если T_old + R >= T_new, потеря пакета S_new относится к текущему факту потерь. В противном случае S_new относится к новому факту потери.

5.3. Размер интервала без потерь

После детектирования первого факта потери, получатель делит пространство порядковых номеров на интервалы без потерь. Если интервал без потерь A определен, как начинающийся с пакета S_A, а следующий интервал B начинается с пакета S_B, тогда к интервалу A относятся (S_B — S_A) пакетов. Таким образом, интервал A включает все пакеты, переданные отправителем с момента отправки первого пакета интервала A до первого пакета интервала B (не включая этот пакет).

Текущий интервал I_0 определяется как интервал без потерь, включающий последний факт потерь. Если интервал без потерь начинается с пакета S_A, а S_C является максимальным номером пакета в этом интервале, размер I_0 составляет S_C — S_A + 1. Например, если текущий интервал состоит из одного пакета с маркером ECN, то S_A == S_C и размер интервала без потерь равен одному пакету.

5.4. Средний интервал без потерь

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

Веса w_0 — w_(n-1) определяются следующим образом:

        If (i < n/2) {
            w_i = 1;
        } Else {
            w_i = 2 * (n-i)/(n+2);
        }

Таким образом, для n=8 значения w_0 — w_7 составляют:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2

Значение n для числа интервалов без потерь, используемых при расчете частоты потерь, определяет скорость отклика TFRC на изменение уровня насыщения. Рекомендуется использовать в качестве значения этого параметра 8. TFRC не следует использовать значения n > 8 для трафика, который может конкурировать в глобальной сети Internet с трафиком TCP. В крайнем случае при использовании значений n > 8 для обеспечения безопасной работы потребуется незначительное изменение механизмов TFRC для обеспечения более резкого отклика на два и более периода RTT с высоким уровнем потерь.

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

Пусть I_0 — I_n обозначают интервалы без потерь и I_0 относится к текущему факту потерь. Если имеется по крайней мере n интервалов без потерь, установим k = n, в остальных случаях в качестве значения k будем использовать максимальный номер имеющегося интервала без потерь. Тогда средний интервал рассчитывается следующим образом:

      I_tot0 = 0;
      I_tot1 = 0;
      W_tot = 0;
      for (i = 0 to k-1) {
          I_tot0 = I_tot0 + (I_i * w_i);
          W_tot = W_tot + w_i;
      }
      for (i = 1 to k) {
          I_tot1 = I_tot1 + (I_i * w_(i-1));
      }
      I_tot = max(I_tot0, I_tot1);
      I_mean = I_tot/W_tot;

Частота (вероятность) потерь p составит:

p = 1/I_mean;

5.5. Дисконтирование истории

Как было показано в параграфе 5.4, при расчете среднего значения по n интервалам без потерь последний интервал дает 1/(0.75*n) часть общего веса, независимо от продолжительности этого интервала. В этом параграфе описан дополнительный механизм «дисконтирования истории»¹⁵, рассмотренный в работах [FHPW00a] и [W00], который позволяет приемному узлу TFRC подбирать весовые параметры, придавая больший вес последнему интервалу без потерь, когда этот интервал более чем вдвое превышает рассчитанное значение среднего интервала.

Для дисконтирования истории свяжем коэффициент DF_i (число с плавающей запятой) с каждым интервалом L_i (для i > 0). Общая история дисконтирования для каждого интервала без потерь будет храниться в массиве коэффициентов. В начальный момент значения элементов массива DF_i устанавливаются в 1:

for (i = 0 to n) {
   DF_i = 1;
}

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

Как описано в параграфе 5.4, средний интервал без потерь вычисляется с использованием n значений предыдущих интервалов I_1, …, I_n и значения I_0 для текущего интервала без потерь. Расчет среднего интервала с использованием коэффициентов дисконтирования незначительно отличается от процедуры, описанной в параграфе 5.4:

      I_tot0 = I_0 * w_0;
      I_tot1 = 0;
      W_tot0 = w_0;
      W_tot1 = 0;
      for (i = 1 to n-1) {
          I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
          W_tot0 = W_tot0 + w_i * DF_i * DF;
      }
      for (i = 1 to n) {
          I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
          W_tot1 = W_tot1 + w_(i-1) * DF_i;
      }
      p = min(W_tot0/I_tot0, W_tot1/I_tot1);

Значение общего коэффициента DF обновляется по прибытии каждого пакета в соответствии с приведенным ниже описанием. Сначала получатель определяет средневзвешенное значение I_mean для интервалов без потерь I_1, …, I_n:

      I_tot = 0;
      W_tot = 0;
      for (i = 1 to n) {
          W_tot = W_tot + w_(i-1) * DF_i;
          I_tot = I_tot + (I_i * w_(i-1) * DF_i);
      }
      I_mean = I_tot / W_tot;

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

      if (I_0 > 2 * I_mean) {
          DF = 2 * I_mean/I_0;
          if (DF < THRESHOLD) {
              DF = THRESHOLD;
          }
      } else {
          DF = 1;
      }

Отличное от 0 значение порога THRESHOLD обеспечивает гарантию того, что информация о более ранних интервалах в периоды высокого насыщения не будет полностью обесценена. Рекомендуется устанавливать THRESHOLD = 0,25. Отметим, что прибытие каждого нового пакета ведет к дополнительному росту I_0 и коэффициент DF будет обновляться.

При новом факте потерь текущий интервал переходит из I_0 в I_1, интервал I_i — в I_(i+1), а интервал I_n отбрасывается. Предыдущий коэффициент DF включается в массив коэффициентов дисконтирования. Поскольку DF_i показывает коэффициент, связанный с интервалом I_i, значения DF_i в массиве также смещаются при новом факте потерь. Процедура сдвига имеет вид:

      for (i = 1 to n) {
          DF_i = DF * DF_i;
      }
      for (i = n-1 to 0 step -1) {
          DF_(i+1) = DF_i;
      }
      I_0 = 1;
      DF_0 = 1;
      DF = 1;

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

6. Протокол получателя данных

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

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

Если получатель передал k пакетов обратной связи за период RTT, для k>1 п. 4) параграфа 6.2 изменяется с установкой для таймера обратной связи значения R_m/k секунд. Однако каждый пакет обратной связи уведомляет пакета о скорости приема а течение последнего периода RTT, а не части этого периода. В этом документе не задаются изменения, которые могут потребоваться для передачи получателем множества пакетов обратной связи за период RTT. Отметим, что передача множества пакетов обратной связи за время RTT дает незначительные преимущества.

6.1. Поведение получателя при поступлении пакета данных

При получении пакета данных приемный узел выполняет ряд действий:

1. Добавление пакета в историю принятых пакетов.
2. Если новый пакет ведет к обнаружению нового факта потерь или не было передано пакета обратной связи на момент завершения отсчета таймера обратной связи, выполняется п. 3. В остальных случаях дополнительных действий не предпринимается (за исключением оптимизации, описанной в следующем параграфе).Для дополнительной оптимизации может выполняться проверка заполнения полученным пакетом пропуска в порядковых номерах (истории) и связанное с этим объединение интервалов без потерь. Если пакет заполняет пропуск, получатель может незамедлительно передать пакет обратной связи. Эффект от такой оптимизации в нормальных условиях предполагается незначительным.
3. Расчет p. Предыдущее значение p рассматривается, как p_prev. Рассчитывается новое значение в соответствии с разделом 5.
4. Завершение отсчета таймера обратной связи. Если p > p_prev, отсчет таймера считается завершенным и выполняются действия, описанные в параграфе 6.2.Если p <= p_prev и к моменту последнего завершения отсчета таймера обратной связи пакет обратной связи не был передан, выполняются действия, описанные в параграфе 6.2. Если же пакет обратной связи к этому моменту был передан, никаких дополнительных действий не требуется.

6.2. Завершение отсчета таймера обратной связи

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

Для m-го завершения отсчета таймера обратной связи предположим, что на приемной стороне максимальный номер полученного пакета имеет значение S_m, а включенный в этот пакет результат измерения RTT имеет значение R_m. Как описано в параграфе 3.2.1, R_m представляет собой наиболее свежую оценку отправителем периода кругового обхода, переданную в пакетах данных. Если с момента отправки предыдущего сообщения обратной связи были получены пакеты данных, получатель выполняет следующие операции:

1. Расчет средней частоты потерь с использованием алгоритма, описанного в разделе 5.
2. Расчет значения скорости приема X_recv на основе пакетов, полученных за предыдущие R_(m-1) секунд. Это выполняется в тех случаях, когда отсчет таймера обратной связи завершается естественным путем или констатируется в результате новой потери или приема маркированного пакета, как описано в п. 3) параграфа 6.1.В типичной ситуации, когда получатель передает только один пакет обратной связи за период кругового обхода и отсчет таймера обратной связи не завершается раньше времени в результате новой потери, время с момента предыдущего завершения отсчета таймера обратной связи будет составлять R_(m-1) секунд.Отметим, что при завершении отсчета таймера обратной связи в результате потери или приема маркированного пакета, время, прошедшее с момента предыдущего завершения отсчета, будет явно меньше R_(m-1) секунд.Для упрощения реализации в тех случаях, когда время с момента предыдущего завершения отсчета таймера обратной связи отлично от R_(m-1) секунд, скорость приема может рассчитываться за более продолжительный интервал вплоть до момента завершения отсчета таймера обратной связи, которое произошло не менее R_(m-1) секунд назад.
3. Подготовка и передача сообщения обратной связи с информацией, описанной в параграфе 3.2.2.
4. Сброс и повторный запуск таймера обратной связи на время R_m секунд.

Отметим, что приведенное выше правило 2) дает минимальное значение измеренной скорости приема X_recv, равное 1 пакету за период кругового обхода. Если отправитель ограничивает скорость передачи данных до значений меньше 1 пакета за RTT, это будет обусловлено потерей пакетов, а не ограничениями, вносимыми измеренным значением скорости приема.

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

6.3. Инициализация получателя

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

В момент получения первого пакета:

• устанавливается p = 0;
• устанавливается X_recv = 0;
• подготавливается и передается пакет обратной связи;
• таймер обратной связи запускается на время R_i секунд.

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

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

• Всякий раз при передаче пакета обратной связи получатель устанавливает для переменной last_counter наибольшее значение счетчика окон с момента последней передачи сообщения обратной связи, если с этого момента были получены какие-либо пакеты данных.
• Если получатель принимает пакет данных со значением счетчика окон, равным значению last_counter + 4 или превышающим его, получатель передает новый пакет обратной связи (отношения «больше или равно» определяются в циклическом пространстве счетчика окон).

6.3.1. Инициализация истории потерь после первого факта потери

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

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

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

TFRC рассчитывает первый интервал без потерь, находя значение p, для которого уравнение пропускной способности в параграфе 3.1 дает скорость передачи отличающуюся от X_target не более, чем на 5%, для данного времени кругового обхода R — для первого интервала без потерь устанавливается значение 1/p. Если получатель знает размер сегмента s, используемый отправителем, он может использовать уравнение пропускной способности, в противном случае получатель может измерить скорость приема в пакетах за секунду вместо байт/сек и использовать уравнение пропускной способности для X_pps (допуск 5% обусловлен тем, что уравнение пропускной способности трудно обратить и без такого допуска пришлось бы использовать ресурсоемкие численные методы расчета p).

Специальным случаем инициализации первого интервала без потерь является ситуация, когда первый пакет теряется или приходит с маркером насыщения. При потере первого пакета в TCP отправитель повторяет передачу этого пакета по завершении отсчета таймера повторной передачи. Если первый пакет TCP имеет маркер ECN, отправитель сбрасывает и заново запускает таймер повтора передачи и отправляет новый пакет данных только после того, когда будет завершен отсчет запущенного заново таймера [RFC3168] (параграф 6.1.2). Для TFRC, если первый пакет потерян или имеет маркер ECN, первый интервал без потерь не содержит пакетов данных. В этом случае размер этого (пустого) интервала следует устанавливать так, чтобы скорость передачи задавалась как в TCP (см. ниже).

Когда первый интервал без потерь в TFRC пуст (первый пакет потерян или имеет маркер ECN), для обеспечения аналогии с поведением TCP, TFRC желает установить допустимую скорость передачи в 1 пакет за каждые 2 периода кругового обхода (или 0,5 на RTT). Таким образом, получатель TFRC рассчитывает интервал без потерь так, чтобы он обеспечивал значение X_target = 0,5/R пакетов в секунду для периода кругового обхода R и использовал это расчетное значение для первого интервала без потерь. Получатель TFRC использует значение 0,5/R пакетов в секунду в качестве минимального значения X_target при инициализации первого интервала без потерь.

Отметим, что несмотря на использование получателем TFRC искусственного значения интервала без потерь после первой потери, получатель продолжает сообщать о скорости передачи X_recv, как указано в параграфе 6.2.

7. Серверные варианты

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

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

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

Документы RFC 4340 и RFC 4342 совместно задают спецификацию механизма DCCP CCID 3, который может применяться в серверных вариантах TFRC. В CCID 3 каждый пакет обратной связи от получателя содержит опцию Loss Intervals, показывающую размеры последних интервалов без потерь. Пакеты обратной связи могут также включать опцию Ack Vector, позволяющую отправителю точно определить, какие пакеты были отброшены или маркированы и проверить информацию из опций Loss Intervals. Опция Ack Vector может также включать маркеры ECN Nonce Echo, позволяющие отправителю проверить данные получателя о принятых пакетах данных без маркеров. Опция Ack Vector также позволяет отправителю самому увидеть, какие пакеты данных были потеряны или маркированы ECN для детектирования интервалов без потерь и расчета частоты потерь. Раздел 9 документа RFC 4342 включает обсуждение вопросов проверки информации, принятой от получателя.

8. Вопросы реализации

В этом документе приведена спецификация механизма контроля насыщения TFRC для использования прикладными и транспортными протоколами. В этом разделе кратко рассматриваются некоторые вопросы реализации механизма.

8.1. Расчет пропускной способности

Для t_RTO = 4*R и b = 1 уравнение пропускной способности из параграфа 3.1 можно представить в форме:

                  s
      X_Bps =  --------
               R * f(p)

где

f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2))

Значения функции f(p) могут сохраняться в специальной таблице.

Многие операции умножения (например, q и 1-q для расчета среднего времени кругового обхода, умножение на 4 для тайм-аута) могут быть реализованы с помощью операций сдвига регистра.

8.2. Поведение отправителя при получении пакета обратной связи

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

8.2.1. Детектирование интервалов с ограниченной передачей данных

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

Если все пакеты обратной связи содержат временную метку последнего принятого пакета, предположим, что t_new — это временная метка из данного пакета обратной связи. Поскольку все пакеты обратной связи покрывают интервал по крайней мере в один период кругового обхода, отправителю достаточно этой метки для того, чтобы определить наличие в интервале (t_old, t_new] времени с ограниченной передачей данных; если оценка времени кругового обхода отправителем составляет R, то в качестве t_old используется значение t_new — R (это оценка покрываемого пакетом обратной связи интервала, а не его точное определение, однако точность такой оценки вполне достаточна).

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

Инициализация

NotLimited1 = NotLimited2 = t_new = t_next = 0;
t_now = текущее время;

После передачи сегмента

       If (отправитель передал все, что ему было дозволено) {
           // отправитель не ограничивал передачу данных в этом интервале
           If NotLimited1 <= t_new
               // цель: NotLimited1 > t_new.
               NotLimited1 = t_now
           Else if (NotLimited2 <= t_next)
               // цель: NotLimited2 > t_next.
               NotLimited2 = t_now;
       }

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

       t_new = временная метка из пакета обратной связи
       t_old = t_new - R                         // локальная переменная
       t_next = t_now;
       If ((t_old < NotLimited1 <= t_new) or (t_old < NotLimited2 <= t_new))
           отправитель не ограничивал передачу данных в этом интервале;
       Else
           отправитель ограничивал передачу данных в этом интервале.
       If (NotLimited1 <= t_new && NotLimited2 > t_new)
           NotLimited1 = NotLimited2;

Времена передачи указывают на отправку сегмента или сегментов нижележащему уровню.

В промежутке между пакетами обратной связи (t_old, t_new] дает интервал передачи по оценке покрываемый последним пакетом обратной связи, а t_next показывает время последнего периода кругового обхода после t_new. Предполагается, что следующий пакет обратной связи будет покрывать интервал (t_new, t_next], если получатель не передаст пакет обратной связи раньше в ответ на новый факт потери. Целью является сохранение в переменной NotLimited1 времени передачи без ограничений в интервале (t_new, t_next], если таковая происходила, а в переменной NotLimited2 — времени неограниченной передачи после t_next.

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

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

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

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

8.2.2. Поддержка X_recv_set

Для упрощения поддержки X_recv_set достаточно ограничить размер массива X_recv_set тремя элементами (N=3). В этом случае процедура Update X_recv_set() будет иметь вид:

      Update X_recv_set():
          Добавить X_recv к X_recv_set;
          Удалить из X_recv_set значения с возрастом более 2 периодов кругового обхода;
          Сохранить только N последних значений.

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

8.3. Передача пакетов раньше номинального времени

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

Пусть t_gran задает гранулярность таймера планирования в операционной системе, а t_ipi — интервал между передачей пакетов (как указано в параграфе 4.6). Если операционная система не обеспечивает нужной гранулярности таймеров или по иным причинам не может поддерживать короткие интервалы t_ipi, отправитель TFRC будет ограничен возможностью передачи не более 1 пакета за каждые t_gran секунд или ему должна быть разрешена передача множества пакетов сразу в форме коротких пиков. В дополнение к разрешению отправителю накапливать кредиты на передачу пакетов за прошлые неиспользованные периоды, полезным может оказаться разрешение отправителю передавать пакет раньше запланированного времени, как описано ниже в этом параграфе.

Параметр t_delta может использоваться для того, чтобы разрешить передачу пакетов раньше номинального времени. Рассмотрим приложение, которое переходит в режим бездействия и запрашивает следующую передачу в момент t_i = t_(i-1) + t_ipi, где t_(i-1) показывает время передачи предыдущего пакета. Когда приложение снова активизируется, оно проверяет значение текущего времени t_now. Если t_now > t_i — t_delta, пакет передается. Когда рассчитывается номинальное время передачи следующего пакета t_i, может оказаться, что t_now > t_i — t_delta. В таких случаях пакет передается незамедлительно.

Для того, чтобы раньше номинального времени передавалось не более одного пакета и пакеты никогда не передавались ранее, чем за период кругового обхода до номинального времени передачи, параметр t_delta следует выбирать, как показано ниже:

t_delta = min(t_ipi, t_gran, rtt)/2;

(гранулярность планирования t_gran в некоторых старых системах Unix составляет 10 мсек.).

В качестве примера рассмотрим поток TFRC с допустимой скоростью передачи X = 10 пакетов за период кругового обхода (PPR), временем кругового обхода 100 мсек, гранулярностью планирования операционной системы t_gran = 10 мсек и возможностью аккумулирования неиспользованных кредитов на передачу в течение периода кругового обхода. В этом случае t_ipi будет иметь значение 1 мсек. Отправителю TFRC будет разрешено передавать пакеты за 0,5 мсек до номинального времени и сохранять неиспользованные кредиты на передачу в течение 100 мсек. Гранулярность планирования в 10 мсек не будет оказывать существенного влияния на работу соединения.

В качестве другого примера рассмотрим поток TFRC с гранулярностью планирования хуже периода кругового обхода — пусть время кругового обхода составляет 0,1 мсек, а гранулярность планирования в операционной системе — 1 мсек и обеспечивается возможность накопления кредитов на передачу в течение периода кругового обхода. Отправителю TFRC будет дозволено сохранять неиспользованные кредиты на передачу в течение 0,1 мсек. Если гранулярность планирования «не оказывает» влияния на отклики отправителя на получение пакетов обратной связи, отправитель TFRC сможет передать RTT пакетов (в соответствии с разрешенной скоростью) за каждый период RTT в ответ на принятый пакет обратной связи. В этом случае грубая гранулярность планирования не позволит существенно снизить скорость передачи, но передача может носить пиковый характер с передачей данных в течение периода кругового обхода в ответ на каждый пакет обратной связи.

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

8.4. Расчет среднего интервала без потерь

Расчет среднего интервала без потерь в параграфе 5.4 включает умножение на весовые коэффициенты w_0 — w_(n-1), которые для n=8 имеют значения:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.

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

1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.

8.5. Опциональный механизм History Discounting

Необязательный механизм дисконтирования истории, описанный в параграфе 5.5, служит для расчета усредненной частоты потерь. Механизм дисконтирования вводится в действие лишь в тех случаях, когда наблюдаются необычно долгие интервалы передачи без потерь. Для более эффективной работы значения коэффициента DF_i могут быть ограничены степенями числа 2.

9. Отличия от RFC 3448

9.1. Обзор изменений

В этом разделе рассматриваются отличия от RFC 3448. На верхнем уровне основным отличием является добавление механизмов обработки случаев ограниченной передачи данных отправителем. Данный документ также явно разрешает отправителю TFRC накапливать до RTT неиспользованных кредитов на передачу, обеспечивающих возможность пиковой передачи пакетов при получении от приложения данных после периода ограниченной передачи. В RFC 3448 этот вопрос в явном виде не рассматривался.

В данном документе, в отличие от RFC 3448, принимаются высокие начальные значения скорости передачи TCP из RFC 3390. данный документ также отличается от RFC 3448 в части разрешения RFC 4342 использовать грубые временные метки в пакетах данных взамен более тонкой гранулярности таких меток.

Другие отличия включают процедуру замедленного старта, отклик на отбрасывание первого пакета данных и т. п. В данном документе исправлены также отмеченные ошибки RFC 3448.

Данный раздел не является нормативным; нормативные материалы приведены выше.

9.2. Изменения в отдельных параграфах

Параграф 4.1, оценка среднего размера сегмента. Приведен вариант алгоритма, который может использоваться для оценки среднего размера сегмента.

Параграф 4.2, значение начальной скорости передачи. В RFC 3448 начальная скорость передачи имеет значение 2 пакета за время кругового обхода. В настоящем документе начальная скорость передачи может достигать 4 пакетов за период кругового обхода в соответствии с RFC 3390. Начальная скорость была изменена в терминах размера сегмента s, а не в терминах MSS.

В параграфе 4.2 данного документа сказано, что tld¹⁶ во время замедленного старта может инициализироваться значениями 0 или -1. В параграфе 4.2 также даны разъяснения по поводу того, что измерения RTT могут осуществляться не только по пакетам обратной связи, но и иными способами (например, из обмена SYN-пакетами).

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

Большое начальное значение скорости приема (параграф 4.2) используется недолго, если получатель отправляет пакет обратной связи после получения первого пакета и отправитель в ответ на этот пакет снижает дозволенную скорость передачи до значения не более 2 пакетов за период RTT, которое является удвоенной скоростью приема. Благодаря изменению обработки данных о скорости приема на стороне отправителя, последний не снижает дозволенную скорость приема до удвоенного значения скорости приема в ответ на первый пакет обратной связи.

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

Параграф 4.4, отклик на период бездействия. В соответствии с параграфом 5.1 документа [RFC4342] в данном документе указано, что при снижении скорости после периода бездействия, покрывающего время с момента запуска таймера обратной связи, дозволенная скорость передачи не снижается до значений меньше начальной скорости передачи (в параграфе 4.4 для переменной recover_rate устанавливается значение начальной скорости передачи).

Параграф 4.4, исправление ошибки [RFC3448Err]. В RFC 3448 содержится противоречивый текст о снижении отправителем скорости передачи вдвое по истечении двух периодов кругового обхода без получения пакетов обратной связи или по истечении 4 периодов кругового обхода. В данном документе указано, что снижение скорости вдвое происходит после 4 периодов кругового обхода без получения пакетов обратной связи [RFC3448Err].

Параграф 4.4, разъяснение процедуры замедленного старта. В параграфе 4.4 указано, что X_Bps не может использоваться, если при завершении отсчета таймера обратной связи p = 0, поскольку у отправителя еще нет значения X_Bps. В параграфе 4.4 также разъяснена ситуация, когда у отправителя еще нет результата определения RTT, но с момента запуска таймера обратной связи уже был передан пакет.

Параграф 4.6: кредиты за неиспользованную передачу. В параграфе 4.6 отмечено, что отправитель TFRC может накапливать до RTT кредитов за неиспользованные передачи. Параграф 4.6 был переписан для того, чтобы четко разделить требования спецификации и вопросы реализации механизма TFRC.

Параграф 5.4, разъяснение. Параграф 5.4 был переписан для прояснения расчета получателем среднего интервала между потерями в тех случаях, когда число таких интервалов еще не достигло n.

Параграф 5.5, корректировка. Параграф 5.5 был исправлен в части того, что интервал без потерь I_0 включает все переданные пакеты с учетом потерянных или маркированных пакетов (как определено в параграфе 5.3).

Параграф 5.5, исправление ошибки [RFC3448Err]. В параграфе 5.5 строка

for (i = 1 to n) { DF_i = 1; }

была заменена на

for (i = 0 to n) { DF_i = 1; }

[RFC3448Err].

Параграф 5.5, дисконтирование истории. Значение параметра THRESHOLD, определяющее нижнюю границу параметра дисконтирования истории DF, было изменено с 0,5 до 0,25 для обеспечения возможности дисконтирования при большой продолжительности интервала без потерь.

Раздел 6, множество пакетов обратной связи. В разделе 6 расширено обсуждение процедур обработки ситуаций, когда получатель шлет множество пакетов обратной связи за период кругового обхода.

Параграф 6.3, инициализация таймера обратной связи. В параграфе 6.3 описана инициализация таймера обратной связи на стороне получателя в тех случаях, когда в первом принятом пакете нет оценки периода кругового обхода.

Параграф 6.3, грубые временные метки. Параграф 6.3 был изменен с включением в качестве опции грубых временных меток от отправителя, инкрементируемых один раз за каждую четверть периода кругового обхода, вместо более прецизионных меток. Такое поведение соответствует RFC 4342.

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

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

Раздел 7, серверные варианты. В разделе 7 рассматриваются варианты реализации механизма TFRC на серверах с учетом RFC 4342.

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

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

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

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

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

10.1. Вопросы безопасности для TFRC в DCCP

TFRC в настоящее время используется механизмом контроля насыщения CCID 3¹⁷ [RFC4342] протокола DCCP¹⁸ [RFC4340]. Раздел «Вопросы безопасности»¹⁹ в RFC 4340 [RFC4340] (раздел 18) включает обсуждение некоторых аспектов безопасности DCCP, в том числе проверку корректности порядковых номеров для защиты от перехвата соединений. В разделе 18 RFC 4340 также рассматриваются механизмы DCCP, способные ограничить влияние потенциальных атак на службы (DoS).

В RFC 4342 дана спецификация использования TFRC в CCID 3. RFC 4342 включает расширенное обсуждение механизмов, которые отправитель может использовать для проверки информации, переданной получателем. При использовании ECN с CCID 3 получатель возвращает отправителю информацию ECN Nonce, позволяющую последнему проверить достоверность переданных получателем данных. Для случаев когда ECN не используется в разделе 9 RFC 4342 рассматривается возможность использования отправителем различных методов, которые позволяют предотвратить проблемы, связанные с ошибочными сообщениями получателя о перегрузках в сети. Однако, как отмечено в RFC 4342, эти методы не являются столь же стойкими к ошибкам и неразрушающими, как ECN Nonce.

11. Благодарности

Авторы благодарят за отклики и обсуждении основанного на уравнении пропускной способности механизма контроля насыщения многих людей, включая членов исследовательской группы Reliable Multicast, рабочей группы Reliable Multicast Transport и исследовательской группы End-to-End. Благодарим также Dado Colussi, Gorry Fairhurst, Ladan Gharai, Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian McDonald, Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit Renker, Arjuna Sathiaseelan, Vladica Stanisic, Randall Stewart, Eduardo Urzaiz, Shushan Wen и Wendy Lee (lhh@zsu.edu.cn) за отклики на ранние версии этого документа и Mark Allman за многочисленные отклики по использованию [RFC3448] для создания работоспособной реализации.

Приложение A. Параметры

В этом документе используется целый ряд параметров. Предполагается, что временные переменные (например, t_now, tld) выражаются в секундах, а разрешение таймеров не хуже 1 миллисекунды.

data-limited interval

Интервал, в течение которого отправитель ограничивает передачу данных (т. е., передает их со скоростью меньше дозволенной) в течение интервала времени (параграф 4.3).

DF

Коэффициент дисконтирования для интервалов между потерями (параграф 5.5).

initial_rate

Дозволенная начальная скорость передачи.

last_counter

Наибольшее полученное значение размера окна (параграф 6.3).

n

Число интервалов без потерь.

NDUPACK

Число пакетов для принятия решения о потере (константа) (параграф 5.1).

nofeedback timer

Таймер на стороне отправителя (раздел 4).

p

Оцененная вероятность (частота) потерь.

p_prev

Предыдущее значение p (параграф 6.1).

q

Константа фильтрации для RTT (параграф 4.3).

q2

Константа фильтрации для долговременной оценки RTT (параграф 4.6).

R

Оценка времени кругового обхода для пути.

R_m

Конкретная оценка времени кругового обхода для пути (параграф 4.3, 6).

R_sample

Измеренное значение RTT (параграф 4.3).

R_sqmean

Долговременная оценка квадратного корня из RTT (параграф 4.6).

recover_rate

Дозволенная скорость для восстановления передачи после периода бездействия (параграф 4.4).

recv_limit

Предел скорости передачи, рассчитанный по X_recv_set (параграф 4.3).

s

Номинальный размер пакета в байтах.

S

Порядковый номер.

t_delay

Сообщенное получателем время между приемом последнего пакета и генерацией пакета обратной связи (параграф 3.2.2).

t_delta

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

t_gran

Гранулярность таймера планирования операционной системы (константа) (параграф 8.3).

t_ipi

Межпакетный интервал при передаче (параграф 4.6).

t_mbi

Максимальное значение RTO для TCP (константа) (параграф 4.3).

t_recvdata

Временная метка последнего принятого пакета (параграф 3.2.2).

timer_limit

Предел скорости передачи в результате завершения отсчета таймера обратной связи (параграф 4.4).

tld

Время последнего удвоения (параграф 4.2).

t_now

Текущее время (параграф 4.3).

t_RTO

Estimated RTO of TCP (параграф 4.3).

X

Допустимая скорость передачи, ограничиваемая по скорости приема.

X_Bps

Рассчитанная скорость передачи в байт/сек (параграф 3.1).

X_pps

Рассчитанная скорость передачи в пакет/сек (параграф 3.1).

X_inst

Разрешенная мгновенная скорость передачи (параграф 4.6).

X_recv

Оцененная получателем скорость приема (параграф 3.2.2).

X_recv_set

Небольшой набор недавних значений X_recv (параграф 4.3).

X_target

Результирующая скорость передачи после первого факта потерь (параграф 6.3.1).

W_init

Начальное окно TCP (константа) (параграф 4.2).

Приложение B. Начальное значение таймера обратной связи

Почему в качестве начального значения таймера обратной связи TFRC используется значение 2 секунды вместо 3 секунд, рекомендуемых в качестве начального значения таймера повтора передачи TCP в соответствии с [RFC2988]? Нет каких-либо существенных причин, по которым таймер обратной связи TFRC должен иметь начальное значение, совпадающее с начальным значением таймера повтора TCP. Таймер повторной передачи в TCP используется не только для снижения скорости в ответ на насыщение, но и для повтора передачи пакетов, которые предполагаются потерянными в сети. Таймер обратной связи TFRC, напротив, используется только для снижения дозволенной скорости передачи и не служит триггером для передачи новых пакетов. В результате не возникает какой-либо опасности для сети в результате того, что начальное значение таймера обратной связи TFRC меньше рекомендуемого значения таймера повторной передачи TCP.

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

Приложение C. Отклик на период ограниченной передачи

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

В частности [RFC2861] предлагает экспериментальный механизм проверки корректности окна насыщения (CWV²⁰) для TCP. Далее мы будем использовать термин «стандартный TCP» для механизмов контроля насыщения, описанных в [RFC2581] и [RFC2581bis]. [RFC2861] задает иной отклик на периоды бездействия или ограниченной передачи, нежели принято в стандартном TCP. При использовании CWV отправитель TCP снижает вдвое размер окна насыщения после каждого RTO в течение периода бездействия, вплоть до начального размера окна. Аналогично при использовании CWV отправитель TCP уменьшает вдвое окно насыщения после каждого RTO в периоды ограниченной передачи.

В этом документе уже задан отклик TFRC на периоды бездействия, похожий на поведение TCP с CWV. Однако этот документ не задает отклик TFRC на периоды ограниченной передачи данных по аналогии с CWV. Добавление такого механизма в TFRC будет требовать изменения одной строки в псевдокоде п. 4) параграфа 4.3. В частности, отклик отправителя на пакет обратной связи:

    If (если весь интервал, закрываемый пакетом обратной связи, характеризуется 
            ограниченной передаче данных) {
          If (пакет обратной связи говорит о новом факте потерь или росте частоты
                       потерь p) {
              уменьшить вдвое элементы X_recv_set;
              X_recv = 0.85 * X_recv;
              Maximize X_recv_set();
              recv_limit = max(X_recv_set);
          } Else {
              Maximize X_recv_set();
              recv_limit = 2 * max (X_recv_set);
          }
    }

будет заменен на:

      If (если весь интервал, закрываемый пакетом обратной связи, характеризуется 
            ограниченной передаче данных) {
          Старые элементы X_recv_set умножаются на 0,85;
          If (пакет обратной связи говорит о новом факте потерь или росте частоты
                       потерь p) {
              Новое значение X_recv умножается на 0,85.
          }
          Maximize X_recv_set();
          recv_limit = 2 * max (X_recv_set);
      }

В частности, если скорость приема из предыдущего периода ограниченной передачи сохранена в X_recv_set, приведенное выше изменение п. 4) будет приводить к умножению этой скорости на 0,85 всякий раз при получении пакета обратной связи и выполнении приведенного выше псевдокода. В результате после 4 последовательных периодов кругового обхода скорость приема из предыдущего периода ограниченной передачи будет умножаться на 0,85⁴ = 0,52. Таким образом, изменение одной строки в п. 4) параграфа 4.3 будет приводить к снижению дозволенной скорости вдвое за каждые 4 периода кругового обхода, в течение которых отправитель ограничивал передачу данных. По самой природе X_recv_set этот механизм никогда не будет снижать дозволенную скорость передачи ниже удвоенного последнего значения скорости приема.

Отметим, что для сохранения похожего на CWV стиля откликов на ограничение передачи данных сохраняется значение

recv_limit = 2 * max (X_recv_set);

взамен

recv_limit = max (X_recv_set);

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

C.1. Долгое бездействие или ограниченный объем данных

Таблица 1: Отклики на долгое бездействие и ограничение передачи данных

Протокол	Долгие периоды бездействия	Долгие периоды ограниченной передачи
Стандартный TCP	Начальный размер окна	Окно увеличивается для каждого cwnd
TCP с CWV	Половина окна (не меньше cwnd)	Уменьшение окна наполовину
Стандартный TFRC	Снижение скорости вдвое (не менее 2 пакетов за RTT). В течение 1 RTT после передачи пакета скорость ограничена значением X_recv	Скорость передачи ограничена удвоенной скоростью приема
Обновленный TFRC	Снижение скорости вдвое (не ниже начальной)	Скорость ограничена удвоенным значением max (текущее значение X_recv, скорость приема до периода ограничения)

 Таблица 1 описывает отклики стандартного TCP [RFC2581], TCP с контролем насыщения CWV[RFC2861], стандартного TFRC [RFC3448] и обновленного TFRC (данный документ) на периоды длительного бездействия или ограниченной передачи. Длинным считается период, продолжительность которого не менее RTO.

Стандартный TCP после долгого бездействия.

Для стандартного TCP [RFC2581] указывает, что после периода бездействия не менее RTO TCP следует установить окно насыщения не более изначального размера окна (точнее говоря, RFC 2581 указывает, что отправителю TCP следует установить для cwnd значение изначального размера окна, если отправитель не передавал данных в течение интервала, превышающего тайм-аут повтора).

Стандартный TCP после длительного ограничения передачи.

Стандартный TCP [RFC2581] не снижает размер окна насыщения после периода ограниченной передачи данных, в течение которого окно насыщения не использовалось полностью. Стандартный TCP в [RFC2581] использует значения FlightSize (объем остающихся в сети данных) только для установки порога замедленного старта по истечении тайм-аута повтора передачи. Стандартный TCP не ограничен синхронизацией подтверждений в течение периода ограниченной передачи.

Слабый отклик стандартного TCP на периоды ограниченной передачи существенно отличается от строго отклика на периоды бездействия.

TCP с CWV после долгого бездействия.

В качестве экспериментального варианта [RFC2861] предлагает более сдержанный отклик на период бездействия, нежели принято в стандартном TCP, где в период бездействия отправитель TCP вдвое снижает значение cwnd после каждого периода RTO (вплоть до начального значения cwnd).

TCP с CWV после длительного ограничения передачи.

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

Отклик TCP с CWV на период бездействия похож на отклик в периоды ограниченной передачи данных. TCP с CWV вносит меньшие по сравнению со стандартным TCP ограничений в отклики на период бездействия и большие ограничения в отклики на периоды ограниченной передачи данных.

Стандартный TFRC после долгого бездействия.

Для стандартного TFRC в [RFC3448] указано, что дозволенная скорость передачи снижается вдвое после каждых RTO секунд периода бездействия. Дозволенная скорость передачи не снижается до значений меньше 2 пакетов за период RTT после периода бездействия. Первый пакет обратной связи после периода бездействия сообщает о скорости приема в пакетах за период кругового обхода — эта скорость используется для ограничения скорости передачи. Стандартный TFRC эффективно выполняет процедуру замедленного старта, начиная с этого значения дозволенной скорости.

Стандартный TFRC после длительного ограничения передачи.

[RFC3448] не делает различий между периодами бездействия и периодами ограниченной передачи. По этой причине дозволенная скорость передачи ограничивается значением, не превышающим удвоенную скорость приема в течение и после периода ограниченной передачи. Это очень жесткое ограничение, более жесткое, нежели в стандартном TCP и TCP с CWV.

Обновленный TFRC после долгого бездействия.

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

Обновленный TFRC после длительного ограничения передачи.

Для обновленного TFRC в настоящем документе внесены различия между периодами бездействия и периодами ограниченной передачи. Как указано в параграфе 4.3, в периоды ограниченной передачи обновленный TFRC помнит скорость приема до начала ограничений и не снижает дозволенную скорость ниже удвоенного значения сохраненной в памяти скорости приема. Это похоже на отклик стандартного TCP, но достаточно сильно отличается от весьма ограниченного отклика стандартного TFRC на периоды ограниченной передачи. Однако отклик обновленного TFRC не столь консервативен, как отклик TCP с CWV, где окно насыщения постепенно уменьшается до реального размера окна в период ограниченной передачи.

Отметим, что для современных реализаций TCP окно насыщения в общем случае не увеличивается в период ограниченной передачи (когда текущее окно насыщения не используется полностью) [MAF05] (параграф 5.7). В обновленном TFRC подобного механизма нет.

Восстановление после периодов бездействия или ограниченной передачи.

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

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

C.2. Короткое бездействие или ограниченный объем данных

Таблица 2 показывает отклики стандартного TCP [RFC2581], TCP с CWV [RFC2861], стандартного TFRC [RFC3448] и обновленного TFRC (данный документ) на короткие периоды бездействия или ограниченной передачи. Коротким считается период, продолжительность которого меньше RTT.

Таблица 2: Отклики на короткое бездействие и ограничение передачи данных

Протокол	Короткие периоды бездействия	Короткие периоды ограниченной передачи
Стандартный TCP	Пик размером до cwnd	Пик размером до cwnd
TCP с CWV	Пик размером до cwnd	Пик размером до cwnd
Стандартный TFRC	?	?
Обновленный TFRC	Пик размером до RTT неиспользованных кредитов на передачу	Пик размером до RTT неиспользованных кредитов на передачу

 Таблица 2 показывает, что отклики обновленного TFRC на короткие периоды бездействия или ограниченной передачи подобны откликам стандартного TCP и TCP с CWV. Для коротких периодов бездействия или ограниченной передачи TCP ограничивается только размером неиспользуемого окна насыщения, а обновленных TFRC — только число неиспользованных кредитов на передачу (до RTT). Для стандартного TFRC [RFC3448] не задает в явном виде поведения в части неиспользованных кредитов на передачу.

C.3. Среднее бездействие или ограниченный объем данных

Таблица 3 показывает отклики стандартного TCP [RFC2581], TCP с CWV [RFC2861], стандартного TFRC [RFC3448] и обновленного TFRC (данный документ) на периоды бездействия или ограниченной передачи средней продолжительности. Средними считаются периоды продолжительностью более RTT, но меньше RTO.

Таблица 3: Отклики на среднее по продолжительности бездействие и ограничение передачи данных

Протокол	Средние периоды бездействия	Средние периоды ограниченной передачи
Стандартный TCP	Пик размером до cwnd	Пик размером до cwnd
TCP с CWV	Пик размером до cwnd	Пик размером до cwnd
Стандартный TFRC	?	Ограничено X_recv
Обновленный TFRC	Пик размером до RTT неиспользованных кредитов на передачу	Пик размером до RTT неиспользованных кредитов на передачу

 Таблица 3 показывает, что отклики обновленного TFRC на периоды бездействия или ограниченной передачи средней продолжительности подобны откликам стандартного TCP и TCP с CWV. Для средних по продолжительности периодов бездействия или ограниченной передачи TCP ограничивается только размером неиспользуемого окна насыщения. В таких же ситуациях обновленный TFRC ограничивается только числом неиспользованных кредитов на передачу (до RTT). Для периодов ограниченной передачи средней продолжительности стандартный TFRC будет ограничен значением X_recv из последнего пакета обратной связи. Обновленный TFRC, напротив, не ограничивается скоростью приема в течение периода ограниченной передачи, которая покрывает весь подтвержденный пакетом обратной связи период кругового обхода. Для стандартного TFRC [RFC3448] не задает явно поведение в части неиспользованных кредитов на передачу.

C.4. Потери в период ограниченной передачи данных

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

Таблица 4: Отклики на потери в период ограниченной передачи данных

Протокол	Отклик на потери
Стандартный TCP	Установить для ssthresh и cwnd значение FlightSize/2
TCP с CWV	Установить для ssthresh и cwnd значение FlightSize/2
Стандартный TFRC	Рассчитать X_Bps и передавать не более 2*X_Bps
Обновленный TFRC	Рассчитать X_Bps и передавать не более recv_limit. Изменить X_recv_set

В TCP [RFC2581] отклик на потери в период ограниченной передачи данных не отличается от откликов на потери в любом другом состоянии TCP. Этот отклик состоит в установке окна насыщения в размере половины FlightSize, где FlightSize определяет размер переданных, но еще не подтвержденных данных. Таким образом, после потери в период ограниченной передачи отправитель TCP должен вдвое снизить скорость передачи, как это происходит при обычных условиях в ответ на потерю.

В стандартном TFRC отклик на потери в период ограниченной передачи совпадает с откликом на потери в любом другом состоянии TFRC. Скорость передачи ограничивается значением X_Bps из уравнения пропускной способности, а также удвоенным последним значением скорости приема X_recv. В результате после потери в период ограниченной передачи может передавать данные со скоростью до 2*X_recv, даже в тех случаях, когда X_Bps из уравнения пропускной способности разрешает большую скорость.

В обновленном TFRC использование скорости приема X_recv в периоды ограниченной передачи для отклика на потери в такие периоды изменено; скорость передачи ограничена значением recv_limit и отправитель может запоминать значения скорости приема X_recv непосредственно перед началом периода ограниченной передачи. Это позволяет отправителю увеличивать скорость передачи в период ограничений более, чем вдвое, вплоть до скорости приема перед началом ограничений (если это дозволяет значение X_Bps, полученное из уравнения пропускной способности). Такое поведение похоже на принятую в стандартном TCP практику отказа от снижения размера окна в период ограниченной передачи данных (при отсутствии потерь).

Как и в стандартном TFRC отправитель в обновленном TFRC передает данных меньше, нежели позволяет значение X_Bps из уравнения пропускной способности. После потери отправитель по-прежнему может не хотеть передавать данных больше, чем позволяет новое значение X_Bps, которое учитывает факт потери. В обновленный TFRC добавлен механизм постепенного ограничения скорости передачи после потерь в период ограниченной передачи. В отличие от отклика TCP в форме установки для размера окна насыщения cwnd значения в половину FlightSize, дополнительные механизмы в обновленном TFRC используют принятую в TFRC практику медленного изменения откликов как для увеличения, так и для снижения допустимой скорости передачи.

Это делается в обновленном TFRC (п. 4) параграфа 4.3) путем уменьшения элемента X_recv_set после потери в период ограниченной передачи и позволяет отправителю передать до max(X_recv_set) данных, вместо 2*max(X_recv_set), в период кругового обхода, следующий непосредственно за получением информации о потере. Таким образом, возможность передачи более, чем 2*X_recv (последнее полученное значение) в интервале ограниченной передачи достигается за счет введения дополнительного механизма снижения дозволенной скорости после потерь в период ограниченной передачи.

Для иллюстрации отклика TFRC на потери в период ограниченной передачи данных рассмотрим несколько примеров.

Таблица 5: Потеря после периода ограниченной передачи

Этап 1: Нет ограничения передачи.
        Передается 100 пакетов за период кругового обхода (RTT).
Этап 2: Ограниченная передачи, 10 пакетов за RTT.
Этап 3: Нет ограничения передачи.
        Передается 100 пакетов за RTT, как позволяет X_Bps.
        Потеря пакета в первом RTT этапа 3.
        Обновление X_Bps.

Отклик обновленного TFRC: незначительное снижение дозволенной скорости передачи в зависимости от числа пакетов с момента последней потери.

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

В примере 1, где пакет теряется в первый RTT этапа 3, это будет отражаться измененным значением X_Bps и дальнейшие потери пакетов будут приводить к дополнительному снижению X_Bps. В частности, следуя стандартному для TFRC уравнению пропускной способности [FHPW00] (параграф A.2), дозволенная скорость передачи TFRC будет снижена вдвое после пяти периодов кругового обхода подряд с потерями пакетов.

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

Таблица 6: Потеря при незначительном ограничении передачи

Этап 1: Нет ограничения передачи. 100 пакетов за RTT.
Этап 2: Ограниченная передачи, 99 пакетов за RTT.
        Пакет теряется на этапе 2.

Отклик обновленного TFRC: незначительное снижение дозволенной скорости передачи (до 85 пакетов за RTT или чуть меньше) в зависимости от числа пакетов с момента последней потери.

Рассмотрим соединение обновленного TFRC, где отправитель передает 100 пакетов за RTT и начинает ограничивать передачу 99 пакетами по причине нехватки данных от приложения (т. е., за каждый период интервала ограниченной передачи отправитель может передать еще один пакет). Если в период ограниченной передачи теряется пакет, дозволенная скорость передачи снижается до min(X_Bps, recv_limit), где оба значения X_Bps и recv_limit незначительно отличаются от дозволенной скорости передачи.

Таблица 7: Потеря одного пакета

Этап 1: Нет ограничения передачи. 100 пакетов за RTT.
Этап 2: Ограниченная передачи, 10 пакетов за RTT.
Этап 3: Нет передачи в течение 2 периодов RTT.
Этап 4: Передается 1 пакет, который приходит с маркером ECN.

Отклик обновленного TFRC: снижение дозволенной скорости передачи до 50 пакетов за RTT. Для каждой потери пакета в период ограниченной передачи сохраненное значение X_recv до начала ограничения передачи уменьшается вдвое.

Пример 3, потеря 1 пакета в период ограниченной передачи. В этом примере рассматривается потеря единственного пакета в период ограниченной передачи после того, как отправитель не передавал пакетов в течение 2 RTT.

Рассмотрим соединение обновленного TFRC, где отправитель передавал 100 пакетов за RTT и начал ограничивать передачу на уровне 10 пакетов за RTT, а потом не передавал пакетов в течение 2 периодов RTT, после чего передал один пакет, который был принят с маркером ECN. В этом случае обновленный TFRC для каждого факта потери в период ограниченной передачи будет снижать вдвое сохраненное значение скорости перед началом периода ограниченной передачи X_recv.

Таблица 8: Потери после увеличения скорости передачи

Этап 1: Нет ограничения передачи. 100 пакетов за RTT.
Этап 2: Ограниченная передачи, 1 пакет за RTT.
Этап 2: Ограниченная передачи, 20 пакетов за RTT.
        Теряется несколько пакетов в каждом RTT этапа 3.
        В течение этапа 3 отправитель желает передавать 20 пакетов за RTT.

Отклик обновленного TFRC: при каждой потере пакетов в течение периода ограниченной передачи сохраненное значение скорости приема до начала ограничения X_recv уменьшается вдвое, а последнее полученное значение X_recv умножается на 0,85.

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

Рассмотрим соединение обновленного TFRC, где отправитель передавал 100 пакетов за RTT, затем ограничил передачу до 1 пакета за RTT и снова увеличил до 20 пакетов. После этого неоднократно возникали потери пакетов.

В этом случае обновленный TFRC при каждом факте потери данных в период ограниченной передачи будет снижать вдвое сохраненное значение скорости приема до ограничения X_recv, а последнее значение X_recv будет умножаться на 0,85.

C.5. Другие варианты

Другим путем оценки обновленного TFRC является сравнение поведения TCP, стандартного TFRC и обновленного TFRC для соединений с чередованием периодов занятости и бездействия, периодов бездействия и ограниченной передачи, а также чередования бездействия и ограниченной передачи в процессе замедленного старта.

C.6. Оценка отклика TFRC на периоды бездействия

В этом параграфе проводится оценка отклика обновленного TFRC на периоды бездействия и ограниченной передачи.

Одним из недостатков стандартного TFRC является то, что жесткий отклик на периоды бездействия или ограниченной передачи может вызывать у приложения желание дополнить поток данных ненужной информацией для предотвращения простоев. Поэтому в обновленном TFRC используется менее жесткий отклик на периоды бездействия или ограниченной передачи. Ведутся работы (например, Faster Restart [KFS07]), которые могут также снизить желание приложений заполнять паузы пустыми данными за счет ускорения процедуры восстановления после периода бездействия. Будут полезны дальнейшие исследования для более детального понимания взаимодействия между механизмами контроля насыщения TCP или TFRC и приложениями, стремящимися заполнить паузы пустыми данными в периоды бездействия или ограниченной передачи.

TCP с контролем окна насыщения (CWV), описанный в параграфе C.1, является экспериментальным стандартом, задающим для отправителя TCP медленное снижение размера окна насыщения в период бездействия или ограниченной передачи [RFC2861]. Хотя отклики TFRC и обновленного TFRC на периоды бездействия похожи на отклики TCP с CWV, отклик обновленного TFRC на периоды ограниченной передачи менее консервативны, нежели аналогичные отклики TCP с CWV (а отклики стандартного TFRC на периоды ограниченной передачи были более консервативны по сравнению с откликами CWV). В будущих работах этот документ может пересматриваться и в отклик обновленного TFRC на периоды ограниченной передачи может включать медленное снижение допустимой скорости передачи; в Приложении C приводится один из возможных механизмов такого снижения. Такие модификации станут более вероятными, если механизм контроля окна насыщения CWV получит в IETF статус Proposed Standard²¹ для TCP.

Литература

Нормативные документы

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

[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, «TCP Friendly Rate Control (TFRC): Protocol Specification», RFC 3448, January 2003.

Дополнительная литература

[BRS99] Balakrishnan, H., Rahul, H., and Seshan, S., «An Integrated Congestion Management Architecture for Internet Hosts,»²³ Proc. ACM SIGCOMM, Cambridge, MA, September 1999.

[CCID-4] Floyd, S., and E. Kohler, «Profile for DCCP Congestion Control ID 4: the Small-Packet Variant of TFRC Congestion Control», Work in Progress, February 2008.

[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, «Equation-Based Congestion Control for Unicast Applications»²⁴, August 2000, Proc SIGCOMM 2000.

[FHPW00a] S. Floyd, M. Handley, J. Padhye, and J. Widmer, «Equation-Based Congestion Control for Unicast Applications: the Extended Version»²⁵, ICSI tech report TR-00-03, March 2000.

[FF99] Floyd, S., and K. Fall, Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking²⁶, August 1999.

[KFS07] E. Kohler, S. Floyd, and A. Sathiaseelan, «Faster Restart for TCP Friendly Rate Control (TFRC)», Work in Progress, November 2007.

[MAF05] A. Medina, M. Allman, and S. Floyd, «Measuring the Evolution of Transport Protocols in the Internet», ACM Computer Communications Review²⁷, April 2005.

[PFTK98] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., «Modeling TCP Throughput: A Simple Model and its Empirical Validation»²⁸, Proc ACM SIGCOMM 1998.

[RFC2140] Touch, J., «TCP Control Block Interdependence», RFC 2140, April 1997.

[RFC2581] Allman, M., Paxson, V., and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2581bis] Allman, M., Paxson, V., and W. Stevens, «TCP Congestion Control», Work in Progress, April 2008.

[RFC2861] Handley, M., Padhye, J., and S. Floyd, «TCP Congestion Window Validation», RFC 2861, June 2000.

[RFC2988] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3390] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 3390, October 2002.

[RFC3448Err] RFC 3448 Errata, <http://www.rfc-editor.org/errata_search.php?rfc=3448>.

[RFC3540] Spring, N., Wetherall, D., and D. Ely, «Robust Explicit Congestion Notification (ECN) Signaling with Nonces», RFC 3540, June 2003.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, March 2006.

[RFC4342] Floyd, S., Kohler, E., and J. Padhye, «Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)», RFC 4342, March 2006.

[RFC4828] Floyd, S. and E. Kohler, «TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant», RFC 4828, April 2007.

[W00] Widmer, J., «Equation-Based Congestion Control», Diploma Thesis, University of Mannheim, February 2000, <http://www.icir.org/tfrc/>.

Адреса авторов

Sally Floyd

ICSI

1947 Center St, Suite 600

Berkeley, CA 94708

EMail: floyd@icir.org

Mark Handley,

Department of Computer Science

University College London

Gower Street

London WC1E 6BT

UK

EMail: M.Handley@cs.ucl.ac.uk

Jitendra Padhye

Microsoft Research

EMail: padhye@microsoft.com

Joerg Widmer

DoCoMo Euro-Labs

Landsberger Strasse 312

80687 Munich

Germany

EMail: widmer@acm.org

---

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

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

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

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

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

Update X_recv_set():

добавить X_recv к X_recv_set;

Удалить из X_recv_set значения, не относящиеся к двум последним периодам RTT.

Network Working Group                                           D. Black
Request for Comments: 5282                                           EMC
Updates: 4306                                                  D. McGrew
Category: Standards Track                                    August 2008

Использование алгоритмов аутентифицированного шифрования с элементом Encrypted в протоколе IKEv2

Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

PDF

Статус документа

Этот документ представляет проект стандартного протокола для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Настоящий документ может распространяться без ограничений.

Аннотация

Алгоритм аутентифицированного шифрования объединяет в одну операцию шифрование и защиту целостности. Такие алгоритмы называют также комбинированными. В этом документе описано использование алгоритмов аутентифицированного шифрования с элементами данных Encrypted протокола IKEv2¹.

Описано также применение двух конкретных алгоритмов аутентифицированного шифрования с элементами IKEv2 Encrypted. Это алгоритм AES² в режимах AES GCM³ и AES CCM⁴. Для использования других алгоритмов аутентифицированного шифрования с элементами IKEv2 Encrypted могут быть разработаны отдельные документы.

1. Введение

Алгоритм аутентифицированного шифрования объединяет функции шифрования и защиты целостности в одну операцию над открытым текстом (plaintext) для создания шифрованного текста с контролем целостности [RFC5116]. Для проверки целостности может использоваться значение ICV⁵, логически отделенное от зашифрованных данных, или код для проверки целостности может включаться в зашифрованные данные, которые создаются алгоритмом. Алгоритмы аутентифицированного шифрования называют также комбинированным режимом работы блочного шифра (combined mode of operation of a block cipher) или алгоритмами комбинированного режима.

Алгоритм AEAD⁶ обеспечивает защиту целостности для дополнительных данных, связанных с открытым текстом и остающихся не зашифрованными. В этом документе описано использование алгоритма AEAD с элементами данных Encrypted в протоколе IKEv2⁷. Описано также использование двух конкретных алгоритмов AEAD с элементами данных IKEv2 Encrypted — AES GCM [GCM] и AES CCM [CCM].

Версия 1 протокола обмена ключами в Internet (IKEv1) [RFC2409] основана на протоколе ISAKMP⁸ [RFC2408]. Бит E (Encryption — шифрование) в заголовке ISAKMP говорит о том, что все элементы данных после заголовка зашифрованы, но любая проверка целостности этих элементов обеспечивается отдельным элементом Hash или Signature (см. параграфы 3.1, 3.11 и 3.12 в [RFC2408]). Такое отделение шифрования от защиты целостности препятствует использованию аутентифицированного шифрования в IKEv1, ограничивая использование комбинированного режима AES в IPsec протоколом ESP⁹ [RFC2406]. Текущей версией ESP является версия 3 — ESPv3 [RFC4303].

Версия 2 протокола обмена ключами (IKEv2) [RFC4306] использует элементы Encrypted, устроенные на основе ESP. Элемент данных IKEv2 Encrypted связывает шифрование и защиту целостности ток, что становится возможным использование алгоритмов AEAD.

1.1. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

Символы и переменные для обозначения входных и выходных данных в операциях шифрования и расшифровки (K, N, P, A, C) определены в [RFC5116]. Символы и переменные SK_*, обозначающие конкретные ключи IKEv2, определены в [RFC4306].

2. Структура документа

Этот документ основан на RFC, описывающих использование AES GCM [RFC4106] и AES CCM [RFC4309] с протоколом ESP, поэтому вводный материал и спецификации режимов из этих документов не повторяются здесь. Структура этого документа следует структуре упомянутых и многие параграфы соответствуют параграфам предшественников, а существенные отличия, которые следует принимать во внимание разработчикам, отмечены явно. Существенные части этого документа заимствованы из двух упомянутых RFC.

Этот документ основан на терминологии, обозначениях и интерфейсах аутентифицированного шифрования, описанных в [RFC5116]. Важным отличием от [RFC4106] и [RFC4309] является то, что в этих двух документах процедуры шифрования и защиты целостности разделяются, а [RFC5116] задает единый шифрованный выход (ciphertext — C), включающий защиту целостности. Более общий подход включает алгоритмы аутентифицированного шифрования, которые выдают один расширенный шифрованный выход со встроенной защитой целостности вместо раздельного шифрования и защиты целостности.

Для AES GCM и AES CCM шифрованный (C) вывод [RFC5116] аутентифицированного шифрования содержит зашифрованные данные [RFC4106] или [RFC4309], объединенные (конкатенация) со значением кода проверки целостности (ICV¹⁰) [RFC4106] или [RFC4309]. Этот документ не меняет алгоритмов аутентифицированного шифрования AES GCM и AES CCM, описанных в [RFC4106] и [RFC4309].

3. Элементы данных IKEv2 Encrypted

Этот раздел основан на [RFC5116] и параграфе 3.14 [RFC4306].

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                     Initialization Vector                     !
! (размер, заданный алгоритмом аутентифицированного шифрования) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        Ciphertext                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Элемент IKEv2 Encrypted с аутентифицированным шифрованием.

Для использования алгоритмов аутентифицированного шифрования с элементами данных IKEv2 Encrypted этот раздел обновляет текст параграфа 3.14 в [RFC4306], меняя рисунок 21 и следующий за ним текст (до конца параграфа) содержимым этого раздела. Кроме того, содержимое параграфа 3.14 в [RFC4306] обновлено также в плане разрешения использовать один алгоритм аутентифицированного шифрования вместо раздельных алгоритмов блочного шифрования и защиты целостности. Параграфы 3.1 и 3.2 этого документа относятся к алгоритмам AES GCM и AES CCM, не меняя, следовательно, документа [RFC4306]. Вносимые этим документом обновления [RFC4306] не оказывают влияния в тех случаях, когда аутентифицированное шифрование не предлагается и не используется.

Структура данных элемента IKEv2 Encrypted применяется для всех алгоритмов аутентифицированного шифрования и эта же структура применяется в ESP. При использовании алгоритма аутентифицированного шифрования элемент IKEv2 Encrypted включает поля заголовка, за которым следует вектор инициализации (IV¹¹) и поле шифрованных данных (C¹²), включающее контроль целостности (см. рисунок 1).

Поле Next Payload, флаг C и поле Payload Length не меняются по сравнению с [RFC4306].

Содержимое поля IV определяется алгоритмом аутентифицированного шифрования (см. параграф 3.1 и 4 для алгоритмов AES GCM и AES CCM).

Поле Ciphertext представляет собой выход алгоритма аутентифицированного шифрования (см. параграф 2.1 [RFC5116]) для приведенных ниже входных данных.

• Секретный ключ (K) — ключ шифрования, получаемый из ключа SK_ei или SK_er (который подходит), как описано в [RFC4306]. Получение ключа шифрования из SK_ei или SK_er для алгоритмов AES GCM и AES CCM описано ниже в параграфе 7.1.

• Одноразовое значение nonce (N), указываемое алгоритмом аутентифицированного шифрования (для AES GCM и AES CCM см. раздел 4 ниже). При расшифровке элемента Encrypted принимающая сторона создает значение nonce на основе вектора инициализации IV в Encrypted с использованием правил для конкретного алгоритма аутентифицированного шифрования (см. параграфы 3.1 и 4 для алгоритмов AES GCM и AES CCM).

• Открытые (нешифрованные) данные (P¹³) представляют собой конкатенацию шифруемых элементов данных IKE с заполнением Padding (если оно используется) и полем Pad Length, как показано ниже на рисунке 2. Структура открытых данных на рисунке 2 применяется для всех алгоритмов шифрования, используемых с элементом IKEv2 Encrypted и не меняется по сравнению с [RFC4306].

• Связанные данные (A¹⁴), описанные ниже в разделе 5.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 IKE Payloads для шифрования                   ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!               !             Padding (0-255 октетов)           !
+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
!                                               !  Pad Length   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. IKEv2 Encrypted Payload Plaintext (P)

Элементы данных (поле IKE Payloads) соответствуют [RFC4306].

Поле Padding может содержать любое значение, выбранное отправителем.

Поле Pad Length указывает число октетов в поле Padding. К размеру поля Padding не предъявляется требований по выравниванию, получатели должны воспринимать заполнение размером от 0 до 255 октетов.

Шифрованный выход алгоритма аутентифицированного шифрования, как определено в [RFC5116], включает в себя данные, которые позволяют проверить целостность и подлинность шифрованной информации и связанных с ней данных. В результате не требуется использовать отдельное поле контроля целостности (ICV¹⁵) в структуре данных IKEv2 Encrypted.

3.1. Вектор инициализации AES GCM и AES CCM (IV)

Этот параграф основан на параграфах 3.1 из [RFC4106] и 3.1 из [RFC4309]. Требования к векторам инициализации для AES GCM и AES CCM одинаковы и совпадают с требованиями для протокола ESP.

Вектор инициализации (IV) должен иметь 8 октетов. Значение IV должно выбираться шифрующей стороной (encryptor) так, чтобы то или иное значение IV использовалось только один раз для данного ключа. Шифрующий может генерировать IV любым способом, обеспечивающим уникальность значений. Базовые модели генерации IV включают счетчик, инкрементируемый по каждому пакеты и применение линейных регистров сдвига с обратной связью (LFSR¹⁶).

3.2. Конструкции Ciphertext (C) для AES GCM и AES CCM

Этот параграф основан на разделе 6 из [RFC4106] и параграфе 3.1 из [RFC4309] с обобщением, соответствующим интерфейсам, описанным в [RFC5116]. Конструкции для алгоритмов AES GCM и AES CCM различаются, но в каждом случае они совпадают с конструкциями для ESP.

Для AES GCM и AES CCM поле Ciphertext содержит выход алгоритма аутентифицированного шифрования (отметим, что это поле включает данные контроля целостности).

Значение AES GCM ICV включает только тег аутентификации AES GCM. Реализации должны поддерживать полноразмерные 16-октетные значения ICV, можно также поддерживать размер 8 или 12 октетов, но недопустимо поддерживать другие размеры ICV.

AES CCM использует шифрованное значение ICV. Реализации должны поддерживать ICV размером 8 и 16 октетов. Возможна также поддержка 12-октетных ICV, но недопустима поддержка других размеров ICV.

4. Формат Nonce (N) для AES GCM и AES CCM

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

Принятый по умолчанию формат nonce использует частично неявные значения nonce (см. параграф 3.2.1 [RFC5116]) следующим образом:

• неявная часть nonce является «затравкой», которая представляет собой часть ключевого материала IKEv2 (Keying Material), известного шифрующей и дешифрующей стороне (см. параграф 7.1), значение затравки не включается в элемент данных IKEv2 Encrypted;

• явной частью nonce служит вектор инициализации IV, включаемый в элемент IKEv2 Encrypted.

При использовании этого принятого по умолчанию формата nonce шифрующая и дешифрующая сторона создают одноразовое значение nonce путем конкатенации затравки salt с вектором инициализации IV в указанном порядке.

Для использования AES GCM с IKEv2 Encrypted этот принятый по умолчанию формат nonce должен использоваться и должны применяться 12-октетные значения nonce. Отметим, что этот формат соответствует заданному в разделе 4 [RFC4106], что обеспечивает совместимость между применением AES GCM в IKEv2 и ESP. Все требования раздела 4 [RFC4106] применимы к использованию AES GCM с IKEv2 Encrypted.

Для использования AES CCM с IKEv2 Encrypted этот принятый по умолчанию формат nonce должен использоваться и должны применяться 11-октетные значения nonce. Отметим, что этот формат соответствует заданному в разделе 4 [RFC4309], что обеспечивает совместимость между применением AES CCM в IKEv2 и ESP. Все требования раздела 4 [RFC4309] применимы к использованию AES CCM с IKEv2 Encrypted.

5. Связанные данные IKEv2 (A)

Этот раздел основан на разделе 5 [RFC4106] и разделе 5 [RFC4309], оба из которых называют связанные данные AAD¹⁷. Описанная в этом разделе конструкция связанных данных применима для всех алгоритмов аутентифицированного шифрования, но отличается от конструкции, применяемой с ESP, поскольку IKEv2 требует другого покрытия данных в части защиты целостности.

5.1. Конструкция Associated Data (A)

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 IKE Payloads для шифрования                   ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!               !             Padding (0-255 октетов)           !
+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
!                                               !  Pad Length   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Связанные данные (A) элемента IKEv2 Encrypted для аутентифицированного шифрования.

Связанные данные (A) должны включать часть содержимого сообщения IKEv2, начиная с первого октета фиксированного заголовка IKE и заканчивая последним октетом Payload Header для элементе Encrypted (т. е., четвертым октетом элемента Encrypted), как показано на рисунке 3. Это включает все элементы данных между фиксированным заголовком IKE и элементом Encrypted.

Поля Initialization Vector и Ciphertext, показанные выше на рисунке 1, недопустимо включать в связанные данные.

5.2. Охват данных для контроля целостности

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

1. Связанные данные (A) охватывают часть сообщения IKEv2, начиная с первого октета фиксированного заголовка IKE и заканчивая последним октетом Payload Header элемента Encrypted (четвертый октет Encrypted). Сюда включаются все элементы данных между фиксированным заголовком IKE и элементом Encrypted, который всегда является последним элементом данных в сообщении IKEv2 [RFC4306].

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

3. Открытые данные (элементы данных IKE, Padding и Pad Length) охватываются проверкой целостности алгоритма аутентифицированного шифрования.

6. Расширение элементов Encrypted для AES GCM и AES CCM

Расширение, описанное в разделе 7 работы [RFC4106] и разделе 6 работы [RFC4309], применимо к использованию комбинированных режимов AES GCM и AES CCM с элементами данных IKEv2 Encrypted. См. раздел 7 в [RFC4106] и раздел 6 в [RFC4309].

7. Соглашения IKEv2 для AES GCM и AES CCM

В этом разделе описаны соглашения, используемые при генерации ключевого материала и значений «затравок» (salt) для алгоритмов AES GCM и AES CCM с протоколом IKEv2 [RFC4306]. Указаны также идентификаторы и атрибуты, требуемые для использования AES GCM и AES CCM с элементами данных IKEv2 Encrypted.

7.1. Ключевой материал и «затравки»

Этот параграф основан на параграфе 8.1 в [RFC4106] и 7.1 в [RFC4309]. Значения Keying Material и Salt для алгоритмов AES GCM и AES CCM различаются, но имеют структуру, совпадающую со структурой этих полей в ESP.

IKEv2 использует псевдослучайную функцию (PRF¹⁸) для создания ключевого материала. PRF применяется в режиме итераций для создания ключевого материала произвольного размера, из которого выделяется материал для конкретных целей без учета выходных границ PRF (см. параграф 2.14 в [RFC4306]).

В этом параграфе показано, как процесс создания ключей, описанный в параграфе 2.14 документа [RFC4306], используется при выработке ключевого материала для AES GCM и AES CCM. Когда алгоритм AES GCM или AES CCM используется с элементами данных IKEv2 Encrypted, ключи защиты целостности SK_ai и SK_ar не применяются и каждый из этих ключей должен трактоваться, как значение нулевого размера. Размер ключей шифрования SK_ei и SK_er включает дополнительные байты «затравки» (salt). Размер и формат ключей шифрования SK_ei и SK_er должен соответствовать приведенным ниже требованиям.

• Для AES GCM каждый ключ шифрования имеет размер и формат материала «KEYMAT requested», указанного в параграфе 8.1 [RFC4106] для размера ключа AES. Например, если ключ AES имеет размер 128 битов, каждый ключ шифрования будет иметь размер 20 октетов, включающих 16-октетный ключ шифрования AES, за которым следует 4 октета затравки.

• Для AES CCM каждый ключ шифрования имеет размер и формат материала «KEYMAT requested», указанного в параграфе 7.1 [RFC4309] для размера ключа AES. Например, если ключ AES имеет размер 128 битов, каждый ключ шифрования будет иметь размер 19 октетов, включающих 16-октетный ключ шифрования AES, за которым следует 3 октета затравки.

7.2. Идентификаторы преобразований IKEv2

Этот параграф относится только к использованию алгоритмов AES GCM и AES CCM с элементами данных IKEv2 Encrypted. Здесь используются идентификаторы, применяемые для согласования алгоритмов AES GCM и AES CCM в ESP.

Ниже перечислены идентификаторы, выделенные ранее агентством IANA, которые служат для согласования использования в протоколе IKEv2 (т. е., с элементами данных IKEv2 Encrypted) алгоритмов AES GCM и AES CCM в качестве преобразований ENCR:

14 для AES CCM с 8-октетным ICV;

15 для AES CCM с 12-октетным ICV;

16 для AES CCM с 16-октетным ICV;

18 для AES GCM с 8-октетным ICV;

19 для AES GCM с 12-октетным ICV;

20 для AES GCM с 16-октетным ICV.

С IKEv2 следует использовать 16-октетные значения ICV, поскольку больший размер ICV обеспечивает более высокий уровень защиты обмена ключами IKEv2 и связанной с этим обменом функциональности.

В общем случае использовать 12-октетные значения (преобразования 15 и 19) не рекомендуется с целью снижения числа возможных вариантов размера ICV. Если нужен размер ICV больше 8 октетов, следует применять 16-октетные ICV.

7.3. Размер ключа

Этот параграф базируется на параграфе 8.4 в [RFC4106] и параграфе 7.4 в [RFC4309]. Требования к размеру ключа (Key Length) одинаковы для алгоритмов AES GCM и AES CCM и идентичны требованиям для протокола ESP.

Поскольку алгоритм AES поддерживает три размера ключей, атрибут Key Length должен указываться при использовании любого из идентификаторов преобразования для AES GCM или AES CCM, перечисленных в параграфе 7.2. Атрибут Key Length должен иметь значение 128, 192 или 256. Использовать размер ключа 192 не рекомендуется. Если нужен размер ключа AES больше 128 битов, следует применять 256-битовый ключ AES. Это снижает число вариантов размера ключа AES.

8. Выбор алгоритма IKEv2

Этот раздел относится к использованию любых алгоритмов аутентифицированного шифрования с элементами IKEv2 Encrypted и не основан на каких-либо предшествующих документах.

IKEv2 (параграф 3.3.3 в [RFC4306]) указывает, что алгоритмы шифрования и защиты целостности требуются для IKE SA¹⁹ (защищенная связь). Этот документ служит обновлением для [RFC4306], указывающим, что при выборе алгоритма аутентифицированного шифрования для любой связи SA (IKE или ESP) недопустимо выбирать для этой SA также механизм защиты целостности. Другое обновление [RFC4306] указывает, что в случаях, когда в предложении указаны только алгоритмы аутентифицированного шифрования, в такое предложение недопустимо включать какие либо преобразования для защиты целостности.

9. Тестовые векторы

В разделе 9 [RFC4106] и разделе 8 [RFC4309] приведены ссылки, указывающие тестовые векторы для AES GCM и AES CCM.

10. Алгоритмы RFC 5116 AEAD_*

Этот параграф добавляет новые алгоритмы в схему AEAD_*, определенную в [RFC5116], позволяя применять AES GCM и AES CCM с IKEv2. Алгоритмы AEAD_* не имеют каких-либо атрибутов или параметров, идентификатор каждого алгоритма AEAD_*, определенный в данном документе, полностью задает размер ключа AES и размер ICV (например, AEAD_AES_128_GCM использует 128-битовый ключ AES и 16-октетное значение ICV).

AEAD_* охватывает алгоритмы аутентифицированного шифрования AES GCM и AES CCM, используемые с IKEv2, и это требует задания 8 дополнительных алгоритмов AEAD_* в дополнение к 4 указанным в [RFC5116]:

• 4 алгоритма AEAD_* задаются для использования 8- и 12-октетных значений ICV с алгоритмом AES GCM и алгоритмами AEAD_*, указанными в [RFC5116].

• Версия AES CCM, применяемая с IPsec (см. [RFC4309]), использует 11-октетные значения nonce вместо 12-октетных в версии AES CCM, указанной в [RFC5116]. 6 алгоритмов AEAD_* указаны для этой версии AES CCM с короткими значениями nonce.

Этот документ рекомендует не применять 192-битовые ключи AES и, следовательно, не включает алгоритмов AEAD_* с такими ключами.

10.1. Алгоритмы AES GCM с 8- и 12-октетными ICV

Следующие 4 алгоритма AEAD_* идентичны алгоритмам AEAD_* из [RFC5116], за исключением использования 8-октетных значений ICV вместо 16-октетных.

10.1.1. AEAD_AES_128_GCM_8

Этот алгоритм идентичен AEAD_AES_128_GCM (параграф 5.1 в [RFC5116]), за исключением тега размера (t) со значением 8 и тега аутентификации размером 8 октетов (64 бита).

Шифротекст AEAD_AES_128_GCM_8 в точности на 8 октетов превышает по размеру нешифрованные данные.

10.1.2. AEAD_AES_256_GCM_8

Этот алгоритм идентичен AEAD_AES_256_GCM (параграф 5.2 в [RFC5116]), за исключением тега размера (t) со значением 8 и тега аутентификации размером 8 октетов (64 бита).

Шифротекст AEAD_AES_256_GCM_8 в точности на 8 октетов превышает по размеру нешифрованные данные.

10.1.3. AEAD_AES_128_GCM_12

Этот алгоритм идентичен AEAD_AES_128_GCM (параграф 5.1 в [RFC5116]), за исключением тега размера (t) со значением 12 и тега аутентификации размером 12 октетов (96²⁰ битов).

Шифротекст AEAD_AES_128_GCM_12 в точности на 12 октетов превышает по размеру нешифрованные данные.

10.1.4. AEAD_AES_256_GCM_12

Этот алгоритм идентичен AEAD_AES_256_GCM (параграф 5.2 в [RFC5116], за исключением тега размера (t) со значением 12 и тега аутентификации размером 12 октетов (96²¹ битов).

Шифротекст AEAD_AES_256_GCM_12 в точности на 12 октетов превышает по размеру нешифрованные данные.

10.2. Алгоритмы AES CCM с 11-октетным Nonce

Следующие 4 алгоритма AEAD реализуют AES CCM с 11-октетным значением nonce, как указано в [RFC4309].

10.2.1. AEAD_AES_128_CCM_SHORT

Алгоритм аутентифицированного шифрования AEAD_AES_128_CCM_SHORT идентичен алгоритму AEAD_AES_128_CCM (см. параграф 5.3 в [RFC5116]), за исключением использования значений nonce на один октет короче. AEAD_AES_128_CCM_SHORT работает в соответствии с [CCM]. Алгоритм использует AES-128 в качестве блочного шифра, обеспечивая для его работы ключ, nonce, связанные данные и открытые данные для шифрования. Форматирование и функция генерации значения счетчика описаны в Приложении A к [CCM], там же указаны значения параметров:

размер nonce — n = 12;

размер тега — t = 16;

q = 3.

Используется тег проверки подлинности размером 16 октетов (128 битов). Шифротекст AEAD_AES_128_CCM_SHORT состоит из шифрованного выхода операции шифрования CCM, объединенного (конкатенация) с выходом тега аутентификации операции шифрования CCM. Тестовые примеры представлены в [CCM]. Размеры входных и выходных данных представлены ниже.

K_LEN — 16 октетов;

P_MAX — 2²⁴ — 1 октетов;

A_MAX — 2⁶⁴ — 1 октетов;

N_MIN и N_MAX — по 11 октетов каждое;

C_MAX — 2²⁴ + 15 октетов.

Шифротекст AEAD_AES_128_CCM_SHORT в точности на 16 октетов больше соответствующего открытого текста.

10.2.2. AEAD_AES_256_CCM_SHORT

Этот алгоритм идентичен AEAD_AES_128_CCM_SHORT, но имеет пару отличий, показанных ниже:

K_LEN — 32 октета вместо 16;

AES-256 CCM вместо AES-128 CCM.

Шифротекст AEAD_AES_256_CCM_SHORT в точности на 16 октетов больше соответствующего открытого текста.

10.2.3. AEAD_AES_128_CCM_SHORT_8

Этот алгоритм идентичен AEAD_AES_128_CCM_SHORT, отличаясь лишь размером тега проверки подлинности — 8 октетов (64 бита).

Шифротекст AEAD_AES_128_CCM_SHORT_8 в точности на 8 октетов больше соответствующего открытого текста.

10.2.4. AEAD_AES_256_CCM_SHORT_8

Этот алгоритм идентичен AEAD_AES_256_CCM_SHORT, отличаясь лишь размером тега проверки подлинности — 8 октетов (64 бита).

Шифротекст AEAD_AES_256_CCM_SHORT_8 в точности на 8 октетов больше соответствующего открытого текста.

10.2.5. AEAD_AES_128_CCM_SHORT_12

Этот алгоритм идентичен AEAD_AES_128_CCM_SHORT, отличаясь лишь размером тега проверки подлинности — 12 октетов (96²² битов).

Шифротекст AEAD_AES_128_CCM_SHORT_12 в точности на 12 октетов больше соответствующего открытого текста.

10.2.6. AEAD_AES_256_CCM_SHORT_12

Этот алгоритм идентичен AEAD_AES_256_CCM_SHORT, отличаясь лишь размером тега проверки подлинности — 12 октетов (96²³ битов).

Шифротекст AEAD_AES_256_CCM_SHORT_12 в точности на 12 октетов больше соответствующего открытого текста.

10.3. Алгоритмы AEAD_* и IKEv2

В таблице перечислены алгоритмы AEAD_* AES CCM и AES GCM, которые могут быть согласованы для IKEv2, с указанием идентификаторов преобразования (IKEv2 Encryption (ENCR) Transform Identifier) и размеров ключей (Key Length Attribute), которые применяются при согласовании каждого алгоритма.

Алгоритм AEAD	Идентификатор ENCR	Размер ключа
AEAD_AES_128_GCM	20	128
AEAD_AES_256_GCM	20	256
AEAD_AES_128_GCM_8	18	128
AEAD_AES_256_GCM_8	18	256
AEAD_AES_128_GCM_12	19	128
AEAD_AES_256_GCM_12	19	256
AEAD_AES_128_CCM_SHORT	16	128
AEAD_AES_256_CCM_SHORT	16	256
AEAD_AES_128_CCM_SHORT_8	14	128
AEAD_AES_256_CCM_SHORT_8	14	256
AEAD_AES_128_CCM_SHORT_12	15	128
AEAD_AES_256_CCM_SHORT_12	15	256

Каждый из перечисленных алгоритмов AEAD_* идентичен алгоритму, обозначаемому комбинацией IKEv2 ENCR Identifier и Key Length Attribute, показанной в той же строке таблицы.

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

Вопросы безопасности, связанные с аутентифицированным шифрованием, рассмотрены в [RFC5116] (см. весь документ, а не только раздел «Вопросы безопасности», поскольку некоторые важные аспекты безопасности рассматриваются за пределами этого раздела).

Вопросы безопасности, связанные с использованием AES GCM и AES CCM с протоколом ESP, применимы и использования этих алгоритмов с IKEv2 Encrypted, как описано в разделе 10 [RFC4106] и разделе 9 [RFC4309]. Применение AES GCM и AES CCM с протоколом IKEv2 не создает дополнительных проблем безопасности по сравнению с известными для случая работы AES GCM и AES CCM с протоколом ESP.

Вопросы безопасности IKEv2 рассмотрены в разделе 5 [RFC4306].

12. Взаимодействие с IANA

Идентификаторы преобразований (Encryption Transform), указанные в параграфе 7.2 были выделены IANA для использования с протоколом ESP. Данный документ расширяет их применение на IKEv2 для элементов данных Encrypted. Для такого расширения не требуется каких-либо действий IANA.

Агентство IANA добавило перечисленные в таблице значения в реестр Authenticated Encryption with Associated Data (AEAD) Parameters.

Алгоритм AEAD	Параграф	Идентификатор
AEAD_AES_128_GCM_8	10.1.1	5
AEAD_AES_256_GCM_8	10.1.2	6
AEAD_AES_128_GCM_12	10.1.3	7
AEAD_AES_256_GCM_12	10.1.4	8
AEAD_AES_128_CCM_SHORT	10.1.1	9
AEAD_AES_256_CCM_SHORT	10.1.2	10
AEAD_AES_128_CCM_SHORT_8	10.1.3	11
AEAD_AES_256_CCM_SHORT_8	10.1.4	12
AEAD_AES_128_CCM_SHORT_12	10.1.5	13
AEAD_AES_256_CCM_SHORT_12	10.1.6	14

Регистрация агентством IANA алгоритма AEAD не означает одобрения этого алгоритма или его защищенности.

13. Благодарности

Благодарности за AES GCM и AES CCM приведены в разделе [RFC4106] и разделе 12 [RFC4309].

Благодарим Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent и Alfred Hoenes за внимательное рецензирование этого документа.

Документ подготовлен с использованием шаблона 2-Word-v2.0.template.dot, автором которого является Joe Touch.

14. Литература

14.1. Нормативные документы

[CCM] Dworkin, M., «NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality», U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf>²⁴, updated July 2007.

[GCM] Dworkin, M., «NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.», U.S. National Institute of Standards and Technology, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf>²⁵, November 2007.

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

[RFC4106] Viega, J. and D. McGrew, «The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)», RFC 4106, June 2005.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4306] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC4309] Housley, R., «Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)», RFC 4309, December 2005.

[RFC5116] McGrew, D., «An Interface and Algorithms for Authenticated Encryption», RFC 5116, January 2008.

14.2. Дополнительная литература

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

Адреса авторов

David L. Black

EMC Corporation

176 South Street

Hopkinton, MA 10748

Phone: +1 (508) 293-7953

EMail: black_david@emc.com

David A. McGrew

Cisco Systems, Inc.

510 McCarthy Blvd.

Milpitas, CA 95035

Phone: +1 (408) 525-8651

EMail: mcgrew@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

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

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

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

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

---

1Internet Key Exchange version 2 — протокол обмена ключами в Internet версии 2.