AAA

RFC 1123 — Требования к хостам Internet — Прикладные и служебные протоколы

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

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

Аннотация

Этот документ является одним из двух RFC, посвященных определению и обсуждению требований к программам хостов Internet. Этот документ посвящен прикладным протоколам и протоколам поддержки, а другой документ RFC 1122 — коммуникационным протоколам канального уровня, IP и транспортного уровня.

Оглавление

1. Введение

Этот документ является вторым из пары RFC, определяющих и обсуждающих требования к реализации хост-систем на базе стека протоколов Internet. Документ посвящен протоколам прикладного уровня. Первый документ — RFC 1122 Requirements for Internet Hosts — Communications Layers" [INTRO:1] — посвящен коммуникационным протоколам — канальный уровень, уровень IP (сетевой) и транспортный уровень. С этой парой также тесно связан документ RFC 1009 — Requirements for Internet Gateways [INTRO:2].

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

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

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

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

В документе обсуждается и разъясняется множество требований и рекомендаций. Простой список требований может быть опасен по ряду причин:

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

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

Вводная часть документа начинается с краткого обзора архитектуры Internet применительно к хостам, приведены также некоторые рекомендации по выбору программ для хостов. Кроме того, во введении приведены некоторые рекомендации по работе с остальной частью документа и рассмотрена используемая терминология. Глава 2 описывает общие требования ко всем прикладным протоколам, главы 3 — 5 описывают требования к протоколам трех основных приложений — Telnet, копирования файлов и электронной почты. Глава 6 посвящена служебным приложениям — DNS, инициализация и управление. В главе 7 приведены ссылки на другие источники информации.

1.1. Архитектура Internet

Краткое описание архитектуры Internet с точки зрения хостов приведено в параграфе 1.1 работы [INTRO:1]. Там же можно найти ссылки на другие публикации по архитектуре Internet.

1.2. Общие вопросы

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

1.2.1. Постоянное развитие Internet

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

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

1.2.2. Принцип устойчивости

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

Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки — раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета. Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу. В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты. Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!

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

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

1.2.3. Протоколирование ошибок

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

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

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

  1. всегда считать аномальные события и делать содержимое счетчиков доступным с помощью средств управления сетью (см. параграф 6.3);
  2. поддерживать возможность выбора протоколируемых событий (например, записывать все ошибки, связанные с хостом X).

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

1.2.4. Конфигурационные параметры

Идеальной реализацией хоста будет та, на которой настройка стека протоколов Internet будет полностью автоматизирована (selfconfiguring). Это позволит реализовать весь стек в ПЗУ или встроить в микросхемы оборудования — такое решение упростит организацию бездисковых станций, снимет значительную часть нагрузки с сетевых администраторов и упростит разработку систем. Однако этот идеал недостижим и на практике к нему не удается даже серьезно приблизиться.

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

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

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

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

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

1.3. Работа с документом

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

В общем случае все главы документа организованы в форме следующих параграфов:

  1. Введение

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

  3. Частные вопросы — рассматривается устройство протокола и вопросы реализации, не включенные в предыдущий раздел.

  4. Интерфейсы — обсуждаются услуги, предоставляемые вышележащему протоколу.

  5. Заключение — резюмируются требования данной главы.

Во многих темах документа встречаются параграфы, помеченные как "Обсуждение" или "Реализация". Этот материал предназначен для разъяснения требований, рассмотренных ранее в документе. Такие параграфы также включают некоторые предложения по вариантам будущих разработок. Материалы о реализации содержат предложения, которые могут быть интересны для разработчиков.

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

1.3.2. Требования

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

Требуется, должен (MUST) — Этот глагол (или причастие от него) используется для обозначения абсолютной необходимости. Следует, рекомендуется (SHOULD) — Этот глагол (или причастие рекомендуемый) служит для обозначения тех случаев, когда могут существовать дополнительные факторы, позволяющие игнорировать данное требование; в таких случаях рекомендуется принимать взвешенное решение с учетом всех факторов. Можно (MAY) — Этот глагол и прилагательное необязательный означает, что вопрос реализации требования отдается на откуп разработчику.

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

Реализация считается несовместимой со стандартами, если в ней не выполнены обязательные требования (MUST). Реализация, в которой выполнены все требования MUST и SHOULD, считается безусловно совместимой (unconditionally compliant); если же выполняются все требования MUST, но проигнорирована часть требований SHOULD. Реализация считается условно совместимой (conditionally compliant).

1.3.3. Терминология

Ряд используемых в документе технических терминов определен в данном параграфе.

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

Этот документ включает результаты работы и комментарии большой группы специалистов по протоколам Internet, включая представителей университетов и исследовательских лабораторий, компаний-производителей и государственных агентств. Подготовка документа велась в рабочей группе IETF Host Requirements.

Редактор выражает особую благодарность за неустанную работу людям, принявшим участие в долгих конференциях и написавшим 3 мегабайта почтовых сообщений за 18 месяцев подготовки этого документа: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), James Van Bokkelen (FTP Software).

Кроме того, выражается благодарность всем, кто внес большой вклад в подготовку документа: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), Mike StJohns (DCA). Перечисленные ниже люди внесли значительный вклад в подготовку отдельных тем: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), Rayan Zachariassen (Toronto).

Благодарим также всех, кто так или иначе способствовал появлению этого документа.

2. Общие вопросы

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

2.1. Имена хостов и числовые адреса

Синтаксис имен хостов Internet описан в RFC 952 [DNS:4]. Однако, одно из требований к именам изменено настоящим документом — в качестве первого символа имени может использоваться буква латиницы или цифра. Программы хостов должны следовать более либеральному требованию настоящего документа.

Программы хостов должны поддерживать имена длиной до 63 символов и рекомендуется поддерживать имена размером до 255 символов.

Рекомендуется обеспечивать возможность идентификации хостов с помощью (1) доменного имени хоста или (2) IP-адреса в десятичном формате с разделением точками (#.#.#.#). Для хостов рекомендуется проверять синтаксически введенный IP-адрес до обращения к DNS.

2.2. Использование службы доменных имен

Доменные имена хостов должны транслироваться в IP-адреса в соответствии с требованиями параграфа 6.1.

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

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

2.3. Приложения на многодомных хостах

Если удаленный хост является многодомным, трансляция имени будет возвращать список адресов IP. Как сказано в параграфе 6.1.3.4, этот список должен быть упорядочен по уменьшению приоритета адресов. Для реализаций прикладных протоколов рекомендуется быть готовым к попыткам использования нескольких адресов из полученного списка для достижения успеха. Более специфические требования для протокола SMTP рассмотрены в параграфе 5.3.4.

Когда локальный хост является многодомным, приложениям на основе запросов/откликов UDP рекомендуется передавать отклик с IP-адресом отправителя, который совпадает с адресом получателя в дейтаграмме запроса UDP. Термин «указанный адрес получателя» (specific destination address) определен в параграфе 3.2.1.3 документа RFC 1122 [INTRO:1].

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

2.4. Тип обслуживания

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

2.5. Требования общего плана

ФункцияПараграфТребования
Пользовательские интерфейсы:
Имена хостов могут начинаться с цифры2.1Обязательно
Поддержка имен размером до 63 символов2.1Обязательно
Поддержка имен размером до 255 символов2.1Рекомендуется
Поддержка IP-адресов в десятичном формате2.1Рекомендуется
Выполнение сначала проверки синтаксиса для IP-адресов2.1Рекомендуется
Преобразование доменных имен в соответствии с параграфом 6.22.2Обязательно
Устойчивость к некритичным ошибкам DNS2.2Обязательно
Повторение с разумным интервалом2.2Обязательно
Допустимость продолжительного отсутствия сервиса2.2Обязательно
Предположение о доступности записей WKS2.2Не рекомендуется
Попытки использования. различных. адресов для многодомного удаленного хоста2.3Рекомендуется
Адрес отправителя отклика UDP соответствует. адресу получателя запроса2.3Рекомендуется
Использование одного адреса IP для связанных соединений TCP2.3Рекомендуется
Задание приемлемых значений TOS2.4Обязательно
Возможность выбора TOS2.4Обязательно
Неиспользуемые биты (младшие 2 бита) равны 02.4Обязательно

3. Удаленный доступ по протоколу TELNET

3.1. Введение

Telnet представляет собой стандартный протокол Internet для удаленного доступа в систему. Протокол обеспечивает правила кодирования для «связывания» клавиатуры и монитора на клиентском компьютере с командным интерпретатором удаленного сервера. Часть протокола Telnet включена также в другие протоколы прикладного уровня (например, FTP и SMTP).

Telnet использует одно соединение TCP и его нормальный поток данных (режим виртуального сетевого терминала — Network Virtual Terminal или NVT) представляет 7-битовые символы ASCII с escape-последовательностями, служащими для управления. Протокол Telnet обеспечивает возможность согласования множества дополнительных режимов и функций.

Основная спецификация Telnet содержится в RFC 854 [TELNET:1], а опции определены во множестве других RFC; перечисленных в разделе 7.

3.2. Общие вопросы

3.2.1. Согласование опций: RFC 854, стр. 2-3

Каждая реализация Telnet должна включать опцию согласования параметров с дополнительными механизмами (option negotiation and subnegotiation machinery) [TELNET:2].

Хост должен аккуратно выполнять требования RFC 854, чтобы избежать возникновения петель при согласовании опций. Хост должен отказываться (т. е., давать отклик WONT/DONT на запросы DO/WILL) от использования неподдерживаемых им опций. Рекомендуется сохранять возможность согласования опций (даже при отказе от всех запросов) в течение всего срока существования соединения Telnet.

Если согласовать опции не удалось, реализация Telnet должна перейти в используемый по умолчанию режим NVT.

3.2.2. Функция Telnet Go-Ahead: RFC 854, стр. 5, RFC 858

На хосте, который никогда не передает команду Telnet Go Ahead (GA — идите прочь), сервер Telnet должен попытаться согласовать опцию подавления этой команды — Suppress Go Ahead (т. е., передать "WILL Suppress Go Ahead"). Клиент и сервер Telnet должен всегда принимать согласование опции Suppress Go Ahead (подавление команды «идите прочь»).

При использовании режима полнодуплексного терминала, для которого GA не имеет смысла, реализация клиента Telnet может игнорировать команды GA.

3.2.3. Функции управления: RFC 854, стр. 7-8

Список команд Telnet был расширен для включения команды EOR (End-of-Record — конец записи) с кодом 239 [TELNET:9]. Клиент и сервер Telnet могут поддерживать функции управления EOR, EC, EL, Break и должны поддерживать функции AO, AYT, DM, IP, NOP, SB, SE.

Хост должен быть способен принимать и игнорировать любые функции управления Telnet, которые он не поддерживает.

3.2.4. Сигнал Telnet "Synch": RFC 854, стр. 8-10

При получении срочных (urgent) данных TCP клиент или сервер Telnet должен отвергать (discard) все данные, за исключением команд Telnet, пока не будет получен октет DM (завершение срочных данных).

При передаче Telnet IP (Interrupt Process) клиенту Telnet рекомендуется сопровождать такое прерывание последовательностью Telnet "Synch" (т. е. передавать как срочные данные TCP последовательность IAC IP IAC DM). Указатель срочности TCP должен указывать на октет DM.

При получении команд Telnet IP сервер Telnet может передать последовательность Telnet "Synch" клиенту для отсечения выходного потока. Выбор решения связан с реакцией операционной системы сервера на локальное прерывание процесса пользователем.

При получении команды Telnet AO сервер Telnet должен передать пользователю последовательность Telnet "Synch" для отсечения выходного потока.

Клиенту Telnet рекомендуется поддерживать возможность отсечения вывода при передаче Telnet IP (см. также 3.4.5).

3.2.5. Принтер и клавиатура в режиме NVT: RFC 854, стр. 11

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

3.2.6. Структура команд Telnet: RFC 854, стр. 13

Поскольку опции могут появляться в любой части потока данных, escape-символ Telnet (известный: как IAC, со значением 255), передаваемый как данные, должен дублироваться.

3.2.7. Опция Telnet Binary: RFC 856

При успешном согласовании опции Binary, разрешается использование 8-битовых символов. Однако, в потоке данных по-прежнему должны просматриваться символы IAC, должны выполняться все встроенные команды Telnet, а символы IAC в качестве данных должны дублироваться. Обработка других символов (например, замена CR на CR NUL или CR LF) недопустима. В частности, для бинарного режима не действует соглашение end-of-line (конец строки), обсуждаемое в параграфе 3.3.1.

3.2.8. Опция типа терминала Telnet: RFC 1091

Опция Terminal-Type должна использовать названия типов терминалов, официально определенные в документе «Assigned Numbers» [INTRO:5], когда такие имена существуют для используемых терминалов. Однако приниматься должны любые значения опции Terminal-Type.

3.3. Частные вопросы

3.3.1. Соглашение Telnet о завершении строки (End-of-Line)

Протокол Telnet определяет последовательность символов CR LF в качестве сигнала завершения строки (end-of-line). Для терминального ввода это соответствует завершению команды или нажатию клавиши завершения строки на пользовательском терминале (на терминалах ASCII это клавиша CR, которая может также называться Return или Enter).

Когда сервер Telnet принимает сигнал завершения строки CR LF как ввод с удаленного терминала, эффект должен быть таким же, как от нажатия клавиши завершения строки на локальном терминале. На хостах, использующих ASCII, в частности, получение сервером Telnet последовательности CR LF должно сопровождаться таким же эффектом, как нажатие клавиши CR на локальном терминале. Таким образом, последовательности CR LF и CR NUL должны иметь одинаковый эффект на серверных хостах ASCII при получении ввода от соединений Telnet.

Клиент Telnet должен обеспечивать возможность передачи любой из последовательностей CR LF, CR NUL и LF. Клиентам Telnet на хостах ASCII рекомендуется обеспечивать пользователю возможность выбора последовательности CR LF или CR NUL при нажатии клавиши завершения строки (по умолчанию следует использовать последовательность CR LF). Последовательность завершения строки Telnet CR LF должна использоваться для передачи данных Telnet, которые не относятся к типу «терминал-хост» (например, при передаче вывода от сервера Telnet или встраивании других прикладных протоколов в Telnet).

3.3.2. Терминалы ввода данных (Data Entry Terminals)

3.3.3. Поддержка опций

Каждая реализация Telnet должна поддерживать опции Binary [TELNET:3] и Suppress Go Ahead [TELNET:5]; рекомендуется также поддерживать опции Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] и Extended Options List [TELNET:8]. Для клиентов и серверов Telnet рекомендуется поддерживать опцию Window Size [TELNET:12], если локальная ОС обеспечивает соответствующие возможности.

3.3.4. Инициирование согласования опций

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

Клиентам Telnet рекомендуется предоставлять пользователю возможность разрешить или запретить инициативу клиента по согласованию опций.

3.3.5. Опция Telnet Linemode

3.4. Пользовательский интерфейс TELNET

3.4.1. Прозрачность набора символов

Для реализаций клиентов Telnet рекомендуется обеспечивать возможность приема и передачи любых 7-битовых символов ASCII. Рекомендуется по возможности обходить все интерпретации специальных символов операционной системой пользовательского хоста, чтобы такие символы могли удобно приниматься и передаваться через соединение.

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

Для двоичных соединений клиент Telnet может обеспечивать escape-механизм для введения произвольных 8-битовых символов, если операционная система хоста не позволяет вводить такие символы непосредственно с клавиатуры.

3.4.2. Команды Telnet

Клиент Telnet должен предоставлять пользователю возможность ввода управляющих функций Telnet IP, AO и AYT, рекомендуется также обеспечивать возможность ввода EC, EL и Break.

3.4.3. Ошибки соединений TCP

Клиенту Telnet рекомендуется сообщать пользователю о любых ошибках TCP, о которых сообщает транспортный уровень (см параграф "TCP/Application Layer Interface" в работе [INTRO:1]).

3.4.4. Использование нестандартных портов

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

3.4.5. Отсечение вывода

Для клиентов Telnet рекомендуется предоставлять пользователю возможность задавать режим отсечения вывода при передаче IP (см. 3.2.4).

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

3.5. Требования к TELNET

ФункцияПараграфТребования
Согласование опций3.2.1Обязательно
Предотвращение петель при согласовании3.2.1Обязательно
Отказ от неподдерживаемых опций3.2.1Обязательно
Возможность согласования в течение всего сеанса3.2.1Рекомендуется
Использование по умолчанию режима NVT3.2.1Обязательно
Передача официальных названий в опции Term-Type3.2.8Обязательно
Восприятие любых имен в опции Term-Type3.2.8Обязательно
Поддержка опций Binary, Supress-GA3.3.3Обязательно
Опции Echo, Status, EOL, Ext-Opt-List3.3.3Рекомендуется
Реализация опции Window-Size при наличии поддержки в ОС3.3.3Рекомендуется
Сервер инициирует согласование режима3.3.4Рекомендуется
Пользователь может разрешить и запретить согласование единиц3.3.4Рекомендуется
Go-Ahead
Сервер, не поддерживающий GA, согласует опцию Supress-GA3.2.2Обязательно
Клиент или сервер принимает опцию Supress-GA3.2.2Обязательно
Клиент Telnet игнорирует GA3.2.2Возможно
Функции управления
Поддержка SE NOP DM IP AO AYT SB3.2.3Обязательно
Поддержка EOR EC EL Break3.2.3Возможно
Игнорирование неподдерживаемых функций управления3.2.3Обязательно
Клиент и сервер отбрасывают срочные данные вплоть до DM3.2.4Обязательно
Клиент передает «Synch» после IP, AO, AYT3.2.4Рекомендуется
Сервер отвечает Synch на IP3.2.4Возможно
Сервер отвечает Synch на AO3.2.4Обязательно
Клиент может отсекать вывод при передаче IP3.2.4Возможно
Кодировка символов
Использование старшего бита в режиме NVT3.2.5Не рекомендуется
Использование старшего бита для контроля четности3.2.5Недопустимо
Согласование. двоичного режима при передаче старшего бита приложениям3.2.5Рекомендуется
Дублирование IAC в потоке данных в любом режиме3.2.6Обязательно
Дублирование IAC в потоке данных при бинарном режиме3.2.7Обязательно
Следовать командам Telnet в бинарном режиме3.2.7Обязательно
Завершение строки CR NUL в бинарном режиме3.2.7Недопустимо
Завершение строки
EOL на сервере совпадает с локальным символом завершения строки3.3.1Обязательно
Сервер ASCII принимает CR LF и CR NUL как EOL3.3.1Обязательно
Клиент может передавать CR LF, CR NUL или LF3.3.1Обязательно
Клиент ASCII может выбирать между CR LF и CR NUL3.3.1Рекомендуется
Клиент по умолчанию использует CR LF3.3.1Рекомендуется
Неинтерактивное использование CR LF для EOL3.3.1Обязательно
Пользовательский интерфейс Telnet
Ввод-вывод 7-битовых символов3.4.1Рекомендуется
Обход интерпретации символов локальной ОС3.4.1Рекомендуется
Escape-символ3.4.1Обязательно
Возможность пользовательского выбора3.4.1Рекомендуется
Escape для ввода 8-битовых символов3.4.1Возможно
Возможность ввода IP, AO, AYT3.4.2Обязательно
Возможность ввода EC, EL, Break3.4.2Рекомендуется
Передача пользователю сообщений об ошибках TCP3.4.3Рекомендуется
Возможность выбора нестандартного порта3.4.4Рекомендуется
Управление отсечением вывода при передаче IP3.4.5Рекомендуется
Возможность вручную восстановить режим вывода3.4.5Рекомендуется

4. Передача файлов

4.1. Протокол передачи файлов — FTP

4.1.1. Введение

Протокол передачи файлов FTP является основным средством обмена файлами в сети Internet. Текущая спецификация протокола содержится в RFC 959 [FTP:1].

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

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

4.1.2. Общие вопросы

4.1.2.1. Тип LOCAL: RFC 959, 3.1.1.4

Программы FTP должны поддерживать тип I (IMAGE или бинарный тип), а также тип L 8 (LOCAL — локальный с логическим размером байта 8). Машины, память которых организована в слова размерности m и значение m не кратно 8, также могут поддерживать тип L m.

4.1.2.2. Управление форматом Telnet: RFC 959, 3.1.1.5.2

Хостам, не делающим различий между TYPE N и TYPE T, рекомендуется реализовать тип T идентично типу N.

4.1.2.3. Структура страницы: RFC 959, 3.1.2.3 и Appendix I

Реализация структуры страницы в общем случае не рекомендуется. Однако, если хосту не нужна реализация FTP для доступа к файлам random access или (произвольный доступ) holey, он должен определенный формат структуры страницы вместо определения нового частного (private) формата FTP.

4.1.2.4. Преобразования структуры данных: RFC 959, 3.1.2

Преобразования FTP структуры между record-structure и file-structure рекомендуется делать обратимыми, чтобы расширить возможности использования файла на хосте получателе.

4.1.2.5. Data Connection Management: RFC 959, 3.3

FTP-клиентам, которые используют потоковый режим (STREAM), рекомендуется посылать команду PORT для выделения нестандартного (non-default) порта для передачи данных по каждой из команд.

4.1.2.6. Команда PASV: RFC 959, 4.1.2

Сервер FTP должен поддерживать команду PASV.

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

4.1.2.7. Команды LIST и NLST: RFC 959, 4.1.3

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

Для данных, возвращаемых командами LIST и NLST, рекомендуется использовать подразумеваемый тип TYPE AN, если не задан в качестве текущего тип EBCDIC; если в качестве подразумеваемого задан тип TYPE EN, рекомендуется использовать этот тип.

4.1.2.8. Команда SITE: RFC 959, 4.1.3

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

4.1.2.9. Команда STOU: RFC 959, 4.1.3

Команда STOU позволяет сохранять файлы с уникальными именами. При получении команды STOU сервер FTP должен возвратить актуальное имя файла в сообщении "125 Transfer Starting" или "150 Opening Data Connection", предшествующем передаче (код 250, указанный в RFC 959, некорректен для таких случаев). Точный формат сообщения показан ниже:

125 FILE: pppp
150 FILE: pppp

pppp представляет уникальное им файла (pathname), который будет записан.

4.1.2.10. Код завершения строки Telnet: RFC 959, стр. 34

Недопустимо делать какие-либо предположения о соответствии между границами READ в управляющем соединении и последовательностями завершения строки Telnet EOL (CR LF).

4.1.2.11. Отклики FTP: RFC 959, 4.2, стр. 35

Сервер FTP должен передавать только корректно форматированные отклики в управляющее соединение. Отметим, что RFC 959 (в отличие от ранних спецификаций FTP) не содержит мер предосторожности для нестандартных откликов.

Серверам рекомендуется использовать коды откликов, определенные в RFC 959, всякий раз, когда это возможно. Однако сервер может использовать при необходимости иные коды откликов в соответствии с общими правилами (см. параграф 4.2). При выборе между кодами 4xx и 5xx серверам не рекомендуется посылать коды 4xx (временный сбой), когда есть какая-то реальная возможность восстановления сервиса FTP в течение нескольких часов.

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

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

Клиентам FTP не рекомендуется специально интерпретировать код отклика 421 (Service not available, closing control connection — сервис недоступен, управляющее соединение закрывается), но следует детектировать закрытие сервером управляющего соединения.

4.1.2.12. Соединения: RFC 959, 5.2

Слова "and the port used" во втором абзаце параграфа 5.2 RFC 959 являются (исторической) ошибкой и не должны приниматься во внимание.

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

Для клиентов FTP недопустимо передавать какие-либо коды управления Telnet, за исключением SYNCH и IP в управляющие соединения FTP. В частности, недопустимо для клиента согласовывать опции Telnet для управляющего соединения. Однако, сервер FTP должен быть способен воспринимать согласование опций Telnet и отказывать в таком согласовании (например, передавая DONT/WONT).

4.1.2.13. Минимальна реализация: RFC 959, 5.1

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

Типы: ASCII Non-print, IMAGE, LOCAL 8
Режимы: Stream
Структуры: File, Record *
Команды:
   USER, PASS, ACCT,
   PORT, PASV,
   TYPE, MODE, STRU,
   RETR, STOR, APPE,
   RNFR, RNTO, DELE,
   CWD,  CDUP, RMD, MKD, PWD,
   LIST, NLST,
   SYST, STAT,
   HELP, NOOP, QUIT.


* - Структуры Record требуются для тех хостов,
    чьи файловые системы поддерживают структуры записей.

4.1.3. Частные вопросы

4.1.3.1. Нестандартные команды (Command Verbs)

FTP позволяет использовать «экспериментальные» команды, имена которых начинаются с "X". При последующем включении команд в стандартные спецификации, они по-прежнему могут начинаться с "X". Ниже представлен список «экспериментальных» команд:

RFC-959   "Экспериментальные"
  MKD           XMKD
  RMD           XRMD
  PWD           XPWD
  CDUP          XCUP
  CWD           XCWD

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

4.1.3.2. Время бездействия

Для серверных процессов FTP рекомендуется задавать время бездействия, по истечении которого процесс будет прерываться в случае отсутствия активности (нет команд или передачи данных). Значение тайм-аута следует делать настраиваемым и по умолчанию время бездействия должно составлять 5 минут.

A client FTP process ("User-PI" in RFC 959) will need timeouts on responses only if it is invoked from a program.

4.1.3.3. Одновременное управление и передача данных

4.1.3.4. Механизм FTP Restart

В описании отклика 110 на стр. 40-41 RFC 959 допущена ошибка, исправленная здесь. Сообщение restart reply, передаваемое через управляющее соединение от принимающего FTP клиенту FTP, имеет формат:

110 MARK ssss = rrrr

где:

Кодирование зависит от используемой ОС и сетевой реализации и всегда генерируется и интерпретируется одной и той же системой (отправителем или получателем).

Когда FTP, реализующий рестарт, получает Restart Marker в потоке данных, рекомендуется форсировать запись данных до этой точки на стабильную среду для кодирования соответствующей позиции rrrr. Для FTP, передающего Restart Markers, не допускается предположение о возврате откликов 110 синхронно с данными (т. е., следует дождаться отклика 110 перед продолжением передачи данных).

Для сообщений об ошибках при рестарте передачи определяются два новых кода:

4.1.4. Пользовательский интерфейс FTP

В этом разделе рассматривается пользовательский интерфейс FTP.

4.1.4.1. Спецификация Pathname

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

4.1.4.2. Команда QUOTE

Клиент FTP должен поддерживать команду QUOTE, которая будет передавать серверу произвольные символьные строки и выводить на консоль полученные на них отклики.

Чтобы команда QUOTE была полезна, клиентам FTP рекомендуется передавать серверу команды управления как ввод от пользователя, а не сохранять их для передачи серверу после того, как начнется передача данных.

4.1.4.3. Передача откликов пользователю

Для FTP-клиентов рекомендуется выводить для пользователя полный текст всех полученных сообщений об ошибках. Рекомендуется также поддерживать режим verbose, в котором выводятся полностью все переданные команды и полный текст откликов с кодом результата. Такая возможность позволяет упростить поиск проблем.

4.1.4.4. Поддержка синхронизации

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

4.1.5. Требования к FTP

ФункцияПараграфТребования
Если не делается различий, реализовать TYPE T, как TYPE N4.1.2.2Рекомендуется
Обратимое преобразование файлов/записей4.1.2.4Рекомендуется
Клиент FTP передает команду PORT для потокового режима4.1.2.5Рекомендуется
Реализация сервером FTP команды PASV4.1.2.6Обязательно
PASV для каждой передачи отдельно4.1.2.6Обязательно
Возможность использования отклика NLST в командах RETR4.1.2.7Обязательно
Подразумеваемый тип для команд LIST и NLST4.1.2.7Рекомендуется
Команда SITE для нестандартных функций4.1.2.8Рекомендуется
Команда STOU возвращает указанное им файла (pathname)4.1.2.9Обязательно
Использование границ TCP READ на управляющем соединении4.1.2.10Недопустимо
Сервер передает отклики только в корректном формате4.1.2.11Обязательно
Сервер использует только стандартные отклики4.1.2.11Рекомендуется
Новые отклики в соответствии с требованиями параграфа 4.24.1.2.11Возможно
Клиент использует только старшую цифру отклика4.1.2.11Рекомендуется
Клиент может работать с многострочными откликами4.1.2.11Обязательно
Специальная обработка клиентом откликов с кодом 4214.1.2.11Не рекомендуется
Порт данных по умолчанию использует тот же IP-адрес, что и порт управления4.1.2.12Обязательно
Клиент FTP передает команды Telnet (за исключением Synch, IP)4.1.2.12Недопустимо
Клиент FTP согласует опции Telnet4.1.2.12Недопустимо
Сервер FTP обслуживает опции Telnet4.1.2.12Обязательно
Поддержка «экспериментальных» команд4.1.3.1Рекомендуется
Тайм-аут по бездействию для серверов4.1.3.2Рекомендуется
Настраиваемое значение тайм-аута4.1.3.2Рекомендуется
Restart Marker как контрольная точка для приемной стороны4.1.3.4Рекомендуется
Отправитель предполагает синхронный характер откликов 1104.1.3.4Недопустимо
Поддержка типов (TYPE):
ASCII — Non-Print (AN)4.1.3.13Обязательно
ASCII — Telnet (AT) — то же, что AN4.1.3.2Рекомендуется
ASCII — Carriage Control (AC)959 3.1.1.5.2Возможно
EBCDIC — (люба форма)959 3.1.1.2Возможно
IMAGE4.1.2.1Обязательно
LOCAL 84.1.2.1Обязательно
LOCAL m4.1.2.1Возможно
Поддержка режимов (MODE):
Stream (поток)4.1.2.13Обязательно
Block (блок)959 3.4.2Возможно
Поддержка структур (STRUCTURE):
File (файл)4.1.2.13Обязательно
Record (запись)4.1.2.13Обязательно
Page (страница)4.1.2.3Не рекомендуется
Поддержка команд:
USER4.1.2.13Обязательно
PASS4.1.2.13Обязательно
ACCT4.1.2.13Обязательно
CWD4.1.2.13Обязательно
CDUP4.1.2.13Обязательно
SMNT959 5.3.1Возможно
REIN959 5.3.1Возможно
QUIT4.1.2.13Обязательно
PORT4.1.2.13Обязательно
PASV4.1.2.6Обязательно
TYPE4.1.2.13Обязательно
STRU4.1.2.13Обязательно
MODE4.1.2.13Обязательно
RETR4.1.2.13Обязательно
STOR4.1.2.13Обязательно
STOU959 5.3.1Рекомендуется
APPE4.1.2.13Обязательно
ALLO959 5.3.1Возможно
REST959 5.3.1Возможно
RNFR4.1.2.13Обязательно
RNTO4.1.2.13Обязательно
ABOR959 5.3.1Возможно
DELE4.1.2.13Обязательно
RMD4.1.2.13Обязательно
MKD4.1.2.13Обязательно
PWD4.1.2.13Обязательно
LIST4.1.2.13Обязательно
NLST4.1.2.13Обязательно
SITE4.1.2.8Возможно
STAT4.1.2.13Обязательно
SYST4.1.2.13Обязательно
HELP4.1.2.13Обязательно
NOOP4.1.2.13Обязательно
Пользовательский интерфейс:
Произвольные имена файлов (pathname)4.1.4.1Обязательно
Реализация команды QUOTE4.1.4.2Обязательно
Непосредственна передача команд управления4.1.4.2Рекомендуется
Вывод сообщений об ошибках на консоль пользователя4.1.4.3Рекомендуется
Режим Verbose4.1.4.3Рекомендуется
Поддержка синхронизации с сервером4.1.4.4Рекомендуется

4.2. Тривиальный протокол передачи файлов TFTP

4.2.1. Введение

Простой протокол передачи файлов (Trivial File Transfer Protocol — TFTP) определен в RFC 783 [TFTP:1].

TFTP своими средствами обеспечивает надежную доставку на базе транспортного протокола UDP, используя простую систему подтверждений stop-and-wait (остановиться и подождать). Поскольку TFTP работает только с одним окном размером 512 октетов, этот протокол может эффективно работать только на путях с небольшим значением произведения задержка*полоса. Интерфейс TFTP очень прост и не обеспечивает контроля доступа и безопасности.

Основным применением TFTP является стартовая загрузка (bootstrapping) хостов через локальную сеть, поскольку этот протокол достаточно прост и может быть легко реализован в EPROM [BOOT:1, BOOT:2]. Производителям оборудования просто требуется поддерживать TFTP для загрузки устройств.

4.2.2. Общие вопросы

Спецификация TFTP [TFTP:1] написана в открытом стиле и не определяет полностью многие части протокола.

4.2.2.1. Режимы передачи: RFC 783, стр. 3

Рекомендуется не поддерживать режим передачи mail.

4.2.2.2. Заголовок UDP: RFC 783, стр. 17

Поле Length (длина) заголовка UDP определено некорректно (включает размер заголовка UDP — 8 октетов).

4.2.3. Частные вопросы

4.2.3.1. Sorcerer's Apprentice Syndrome

В спецификации протокола содержится серьезна ошибка — Sorcerer-синдром (Sorcerer's Apprentice Syndrome), которая хоть и не приводит к некорректной передаче (файл всегда передается корректно, если передача завершена), но может привести к избыточным повторам и тайм-аутам.

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

4.2.3.2. Алгоритм определения тайм-аута

Реализация TFTP должна использовать адаптивный тайм-аут.

4.2.3.3. Расширения

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

4.2.3.4. Контроль доступа

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

4.2.3.5. Широковещательные запросы

Запрос TFTP, отправленный по широковещательному адресу, рекомендуется отбрасывать без уведомления.

4.2.4. Требования к TFTP

ФункцияПараграфТребования
Преодоление синдрома Sorcerer4.2.3.1Обязательно
Режимы передачи:
netasciiRFC 783Обязательно
octet (октет)RFC 783Обязательно
mail (почта)4.2.2.1Не рекомендуется
extensions (Расширения)4.2.3.3Возможно
Использование адаптивного тайм-аута4.2.3.2Обязательно
Настраиваемое управление доступом4.2.3.4Рекомендуется
Игнорирование широковещательных запросов4.2.3.5Рекомендуется

5. Электронная почта — SMTP и RFC 822

5.1. Введение

В стеке протоколов TCP/IP электронная почта в формате RFC 822 [SMTP:2] передается с помощью протокола SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты), определенного в RFC 821 [SMTP:1].

Хотя протокол SMTP остается неизменным уже в течение многих лет, сообщество Internet внесло некоторые изменения в способы использования SMTP. В частности, переход к системе доменных имен (Domain Name System или DNS) потребовал изменения формата почтовых адресов и маршрутизации электронной почты. В этом разделе предполагается наличие у читателя базовых познаний в части DNS (см. параграф 6.1).

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

5.2. Общие вопросы

Этот раздел тесно связан с RFC 821 и RFC 822. Спецификация SMTP в RFC 821 описана четко и однозначно, а также содержит множество примеров, поэтому реализация не должна вызывать затруднений. В данном разделе просто рассмотрены некоторое важные аспекты RFC 821 и внесен ряд поправок.

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

5.2.1. Модель SMTP: RFC 821, раздел 2

5.2.2. Канонизация имен: RFC 821, 3.1

Имена доменов, которые Sender-SMTP передает в командах MAIL и RCPT должны быть «канонизированы» (т. е., должны быть полностью заданными именами (principal name или domain literal), а не кличками (nickname) или сокращениями. Канонизированное им идентифицирует непосредственно хост или им MX и не может быть CNAME (псевдоним имени).

5.2.3. Команды VRFY и EXPN: RFC 821, 3.3

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

Для команды VRFY здесь определяется новый код отклика:

252 Cannot VRFY user — невозможно проверить пользователя (например, отсутствует локальна информация), но будет предпринята попытка доставить почту этому пользователю.

5.2.4. Команды SEND, SOML, SAML: RFC 821, 3.4

SMTP может реализовать команды для передачи сообщений на пользовательский терминал: SEND, SOML, SAML.

5.2.5. Команда HELO: RFC 821, 3.5

Отправитель SMTP должен обеспечивать корректность параметра <domain> в команде HELO (полное доменное им хоста) для клиентского хоста. В результате этого получателю SMTP не нужно будет выполнять преобразования MX для этого имени, чтобы проверить корректность параметра HELO.

Получатель HELO может проверить, что параметр HELO реально соответствует IP-адресу отправителя. Однако получатель не имеет права отказываться от восприятия сообщения даже при отрицательном результате проверки отправителя команды HELO.

5.2.6. Трансляция почты: RFC 821, 3.6

Различают три типа пересылки почты (возможно, с промежуточным сохранением):

  1. Проста программа пересылки (mail exchanger) рассылает сообщения с использованием частной (private) информации о получателях (см. RFC 821, 3.2).

  2. Транслятор SMTP (mail relay) пересылает сообщения в среде SMTP с использованием явно заданного отправителем маршрута (explicit source route), как определено в параграфе 3.6 RFC 821. Функции SMTP relay используют форму "@...:" для задания маршрута в соответствии с RFC 822 (см. 5.2.19 ниже).

  3. Почтовый шлюз (mail gateway) передает сообщения между различными средами. Правила работы почтовых шлюзов рассмотрены в параграфе 5.3.7.

Хостам Internet, пересылающим почту, но не являющимся шлюзами в другие почтовые среды (т. е., относящимся к типу (1) или (2)) не рекомендуется менять пол заголовков в сообщениях, хотя можно добавлять строку Received: в соответствии с требованиями параграфа 5.2.8.

Отправителям SMTP не рекомендуется передавать команду RCPT TO:, содержащую явный маршрут, с использованием адреса в формате "@...:". Таким образом, функции трансляции почты, определенные в параграфе 3.6 RFC 821, не рекомендуется использовать.

Получатель SMTP должен воспринимать синтаксис явного задания маршрута в конверте, но он может реализовать функции трансляции (relay) в соответствии с параграфом 3.6 RFC 821. Если функция трансляции не реализована, получателю рекомендуется попробовать доставить сообщение напрямую хосту, указанному в адресе справа от знака @.

5.2.7. Команда RCPT: RFC 821, 4.1.1

Хост, поддерживающий SMTP-получатель, должен обеспечивать почтовый ящик Postmaster. Получатель SMTP может проверять параметры RCPT при доставке; однако, отклики RCPT недопустимо задерживать сверх разумного времени (см. 5.3.2).

Следовательно, отклик "250 OK" для RCPT не обязательно говорит о корректности указанного адреса получателя. Информация об ошибках, обнаруженных после восприятия сообщения, будет передаваться в виде почтовых сообщений в соответствующий адрес (см. 5.3.3).

5.2.8. Команда DATA: RFC 821, 4.1.1

Каждый получатель SMTP (не только тот, который принимает сообщения для трансляции или окончательной доставки — "accepts a message for relaying or for final delivery" [SMTP:1]) должен вставлять строку Received: в начале сообщения. В этой строке, которая названа "time stamp line" (строка с временной меткой) в RFC 821 указывается:

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

Когда получатель SMTP выполняет окончательную доставку (final delivery) сообщения, он должен передать адрес MAIL FROM из конверта SMTP, связанного с данным сообщением, для использования в тех случаях, когда позднее требуется передать отправителю информацию об ошибках (см. 5.3.3). Это аналогично требованию к шлюзам при передаче почты из Internet в иную почтовую среду (см. 5.3.7).

5.2.9. Синтаксис команд: RFC 821, 4.1.2

Синтаксис команды MAIL FROM: в RFC 821 не рассматривает случай пустой строки пути — "MAIL FROM: <>" (см. стр. 15 в RFC 821). Пустые пути возврата должны поддерживаться.

5.2.10. Отклики SMTP: RFC 821, 4.2

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

Отправитель SMTP должен определять свои действия только на основе кода отклика, но не его текста (за исключением откликов 251 и 551 replies); любой текст (или отсутствие такового) должен восприниматься нормально. Пробелы после кода отклика рассматриваются как часть текста. Отправителю SMTP рекомендуется проверять только первую цифру в коде отклика (см. Appendix E в RFC 821).

5.2.11. Прозрачность: RFC 821, 4.5.2

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

5.2.12. Использование WKS при обработке MX: RFC 974, стр. 5

RFC 974 [SMTP:3] рекомендует запрашивать у DNS записи WKS (Well-Known Service — хорошо известный сервис), чтобы убедиться в поддержке SMTP каждым предложенным получателем. Однако опыт показывает, что поддержка WKS реализована не везде, поэтому WKS при обработке MX использовать не рекомендуется.

Далее приведены комментарии к RFC 822, организованные по разделам документа.

5.2.13. Спецификация сообщений: RFC 822, глава 4

Синтаксис строки Return-path не предусматривает возможности пустого пути возврата, которая используется для предотвращения петель при уведомлениях об ошибках (см. 5.3.3). Полный синтаксис имеет вид:

return = "Return-path"  ":" route-addr
       / "Return-path"  ":" "<" ">"

Набор добавленных в последнее время полей заголовков включает поле Content-Type, определенное в RFC 1049 [SMTP:7]. Это поле позволяет программам для чтения почты идентифицировать тип структурированного тела сообщения и определить процесс для его корректного отображения [SMTP:7]. Пользовательский агент может поддерживать это поле.

5.2.14. Спецификации даты и времени: RFC 822, глава 5

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

date = 1*2DIGIT month 2*4DIGIT

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

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

Военные временные зоны в RFC 822 указаны некорректно — счет от UT ведется в обратном направлении. В результате военные временные зоны в заголовках RFC 822 не несут полезной информации.

Наконец, отметим, что в определении "zone" при рассмотрении синтаксиса в приложении D допущена опечатка; корректное определение приведено в главе 3 RFC 822.

5.2.15. Изменение синтаксиса: RFC 822, 6.1

Синтаксическое определение почтового ящика (mailbox) в RFC 822 недавно было заменено:

mailbox =  addr-spec            ; simple address
        / [phrase] route-addr   ; name & addr-spec

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

From: <craig@nnsc.nsf.net>

5.2.16. Локальный путь: RFC 822, 6.2

Базовая спецификация адреса почтового ящика имеет форму: "local-part@domain". Вместо local-part (локальная часть адреса) иногда используют термин left-hand side (левая часть адреса).

Хост, который пересылает сообщение, но не является его получателем, имеет дело с правой частью адреса — доменом (domain). При пересылке сообщений недопустимо менять что-либо в локальной части адреса.

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

Хотя задание маршрута отправителем (source route) не рекомендуется использовать для почты Internet (см. 5.2.6), существуют почтовые среды, в которых механизмы работы шлюзов основаны на таких маршрутах. Обычно маршруты для таких сред встраивают в локальную часть адреса при передаче почты через Internet. Когда почта приходит на нужный почтовый шлюз Internet, этот шлюз интерпретирует локальную часть адреса и строит адрес или маршрут для инородной почтовой среды. Например, хост Internet может отправить почту по адресу a!b!c!user@gateway-domain. Сложна локальна часть a!b!c!user будет прозрачно передаваться через Internet, но указанный шлюз разберет эту часть и преобразует ее в корректный адрес другой почтовой среды.

Вложенные маршруты source route иногда помещаются в локальную часть адреса с использованием знака "%" в качестве правого (right-binding) оператора маршрутизации. Например, в адресе:

user%domain%relay3%relay2@relay1

знак % показывает, что почта маршрутизируется из relay1 через relay2 и relay3 для передачи пользователю user в домене domain. Такую нотацию часто называют "%-hack". Предполагается, что % имеет меньший приоритет, нежели другие операторы маршрутизации (например, "!"), спрятанные в локальной части адреса. Например, "a!b%c" будет интерпретироваться как "(a!b)%c".

Только хосту-получателю (в нашем случае, relay1) дозволено анализировать локальную часть "user%domain%relay3%relay2".

5.2.17. Доменные имена: RFC 822, 6.2.3

Почтовая программа (mailer) должна воспринимать и разбирать доменные литералы Internet, контекст которых ("dtext" в RFC 822) содержит адрес хоста в десятичном формате с разделением точками (dotted-decimal). Это соответствует требованиям параграфа 2.1 для случая электронной почты.

Программа SMTP должна доменные литералы для любого из своих адресов IP.

5.2.18. Общие ошибки при форматировании адресов: RFC 822, 6.1

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

5.2.19. Явное задание маршрута: RFC 822, 6.2.7

Программам хостов Internet не рекомендуется создавать заголовки RFC 822, содержащие адреса с явным маршрутом (explicit source route), но они должны воспринимать такие заголовки в целях совместимости.

5.3. Частные вопросы

5.3.1. Стратегия очередей SMTP

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

Люба стратеги работы с очередями должна включать:

5.3.1.1. Стратеги передачи

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

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

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

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

Когда одно сообщение доставляется нескольким пользователям на одном хосте, рекомендуется передавать только одну копию. Т. е., отправителю SMTP рекомендуется использовать последовательность команд: RCPT, RCPT,... RCPT, DATA вместо последовательности: RCPT, DATA, RCPT, DATA,... RCPT, DATA. Реализация этого эффективного варианта настоятельно рекомендуется.

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

Использование различных адресов на многодомных хостах рассматривается ниже.

5.3.1.2. Стратеги приема

На приемной стороне SMTP рекомендуется сохранять постоянное прослушивание порта SMTP. Это требуется для поддержки множества входящих TCP-соединений для SMTP. Можно ввести некоторые ограничения.

5.3.2. Тайм-ауты SMTP

Существует два подхода при выборе времени ожидания для отправителей SMTP: (a) раздельно ограничивать время для каждой команды SMTP или (b) ограничивать время диалога SMTP в целом для каждого почтового сообщения. Рекомендуется использовать для отправителей SMTP вариант (a) — покомандные тайм-ауты. Рекомендуется также обеспечивать простой способ изменения времени ожидания, предпочтительно без перекомпиляции кода SMTP.

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

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

5.3.3. Надежное получение почты

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

Если после восприятия сообщения возникают проблемы с его доставкой, получатель SMTP должен сформулировать и передать уведомление об этом. Такие уведомления должны передаваться с использованием пустого ("<>") пути возврата в конверте (см. параграф 3.6 в RFC 821). В качестве получателя такого уведомления рекомендуется указывать адрес из пути возврата в конверте или строки Return-Path:. Если этот адрес пуст ("<>"), для получателя SMTP недопустима передача уведомления о возникших проблемах. Если адрес содержит заданный явно маршрут, рекомендуется разобрать его до конечной точки.

Во избежание дублирования сообщений в результате тайм-аутов получатель SMTP должен искать способ минимизации времени, требуемого для отклика на финальную точку, завершающую передачу сообщения. Обсуждение этой проблемы приведено в RFC 1047 [SMTP:4].

5.3.4. Надежна доставка почты

Для передачи сообщения отправитель SMTP определяет IP-адрес хоста-получателя по адресу получателя в конверте (преобразуется в адрес IP часть адреса получателя справа от знака @). При таком отображении или преобразовании могут возникать некритичные ошибки (soft error), в результате которых отправитель SMTP будет перестраивать почтовую очередь для последующей доставки сообщений, связанных с неудачной попыткой (см. 5.3.1.1).

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

Для ранжирования адресов в списке можно использовать следующую информацию:

  1. Множество записей MX — значение записи можно использовать в качестве ключа сортировки. При существовании множества получателей с одинаковым значением и отсутствии других критериев (например, предпочтительный адрес) установки очередности отправителю SMTP рекомендуется использовать случайный выбор для распределения нагрузки между почтовыми серверами, обслуживающими указанную организацию (отметим, что в работе [DNS:3] предложен усовершенствованный вариант этой процедуры).

  2. Многодомный хост — хост-получатель (возможно определенный по записи MX с высшим приоритетом) может быть многодомным и в этом случае программа преобразования доменных имен будет возвращать список адресов IP. Упорядочивание адресов в списке (по уровню приоритета) является прерогативой программы-резольвера (см. параграф 6.1.3.4) и отправитель SMTP должен пытаться применять адреса в предложенном порядке.

5.3.5. Поддержка доменных имен

Реализации SMTP должны использовать механизм, определенный в параграфе 6.1 для преобразования доменных имен в IP-адреса и обратно. Это означает, что хост Internet SMTP должен включать поддержку Internet DNS.

В частности, отправитель SMTP должен поддерживать схему записей MX [SMTP:3]. Дополнительную информацию о преобразованиях доменных имен для SMTP можно найти в параграфе 7.4 работы [DNS:2].

5.3.6. Списки рассылок и псевдонимы

Использующим SMTP хостам рекомендуется поддерживать обе (списки — list и псевдонимы — alias) формы расширения адресов для организации групповой доставки. Когда сообщение доставляется или пересылается по каждому из адресов списка, адрес возврата в конверте (MAIL FROM:) должен заменяться на адрес администратора списка, но заголовок письма (в частности, поле From:) должен сохраняться неизменным.

5.3.7. Почтовый шлюз

Передача почты между различными почтовыми средами, использующими разные форматы и протоколы, является сложной задачей, для которой еще нет должного уровня стандартизации (см. примеры в [SMTP:5a], [SMTP:5b]). Однако здесь приведены некоторые общие требования для почтовых шлюзов, обеспечивающих пересылку между Internet и другими почтовыми средами.

5.3.8. Максимальный размер сообщения

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

5.4. Требования к SMTP

ФункцияПараграфТребования
Получатель SMTP:
Реализация VRFY5.2.3Обязательно
Реализация EXPN5.2.3Рекомендуется
Возможность настройки EXPN, VRFY5.2.3Возможно
Реализация SEND, SOML, SAML5.2.4Возможно
Проверка параметра HELO5.2.5Возможно
Отбрасывание сообщений с некорректным HELO5.2.5Недопустимо
Допустимость явного синтаксиса source-route в среде5.2.6Обязательно
Поддержка postmaster5.2.7Обязательно
Обработка RCPT при получении (кроме списков)5.2.7Возможно
Значительна задержка откликов RCPT5.2.7Недопустимо
Добавление строки Received:5.2.8Обязательно
Строка Received: включает доменные литералы5.2.8Рекомендуется
Изменение предыдущей строки Received:5.2.8Недопустимо
Передача информации о пути возврата (Rerurn-Path)5.2.8Обязательно
Поддержка пустых обратных путей5.2.9Обязательно
Передача только официальных кодов отклика5.2.10Рекомендуется
Передача текста из RFC 8225.2.10Рекомендуется
Удаление *.* для прозрачности5.2.11Обязательно
Восприятие и распознавание своих доменных имен5.2.17Обязательно
Генерация сообщений об ошибках для сообщений об ошибках5.3.1Недопустимо
Сохранение состояния прослушивания для порта SMTP5.3.1.2Рекомендуется
Ограничение числа одновременно принимаемых сообщений5.3.1.2Возможно
Ожидание не менее 5 мин. перед следующей командой отправителя5.3.2Рекомендуется
Предотвращение сбоев при доставке после сообщений «250 OK»5.3.3Недопустимо
Передача уведомлений об ошибках после получения5.3.3Обязательно
Передача с использованием пустого пути возврата5.3.3Обязательно
Передача по пути возврата конверта5.3.3Рекомендуется
Передача по пустому адресу5.3.3Недопустимо
Вырезание заданного явно source-route5.3.3Рекомендуется
Минимизация задержки восприятия (RFC 1047)5.3.3Обязательно
Отправитель SMTP:
Канонизированные доменные имена в MAIL, RCPT5.2.2Обязательно
Реализация SEND, SOML, SAML5.2.4Возможно
Передача корректного основного имени в HELO5.2.5Обязательно
Передача явного маршрута в RCPT TO:5.2.6Не рекомендуется
Использование для определения действия только кода отклика5.2.10Обязательно
Использование только старшей цифры кода отклика5.2.10Рекомендуется
Добавление *.* для прозрачности5.2.11Обязательно
Повторение передачи после некритичных ошибок5.3.1.1Обязательно
Задержка перед повтором5.3.1.1Обязательно
Настраиваемые параметры повторной передачи5.3.1.1Обязательно
Одна попытка для каждого хоста-получателя в очереди доставки5.3.1.1Рекомендуется
Множество RCPT для одной команды DATA5.3.1.1Рекомендуется
Поддержка одновременных транзакций5.3.1.1Возможно
Ограничение числа5.3.1.1Рекомендуется
Тайм-аут для всех операций5.3.1Обязательно
Тайм-аут для каждой команды независимо5.3.2Рекомендуется
Проста настройка времени ожидания5.3.2Рекомендуется
Рекомендуемые значения5.3.2Рекомендуется
Пробовать альтернативные адреса по порядку5.3.4Обязательно
Конфигурационные ограничения для числа адресов5.3.4Возможно
Пробовать по крайней мере два адреса5.3.4Рекомендуется
Распределение нагрузки при равных значениях MX5.3.4Рекомендуется
Использование DNS5.3.5Обязательно
Поддержка записей MX5.3.5Обязательно
Использование WKS при обработке MX5.2.12Не рекомендуется
Пересылка почты:
Изменение существующих полей заголовка5.2.6Не рекомендуется
Реализация функций трансляции (RFC 821, параграф 3.6)5.2.6Возможно
Если нет, доставка в домен RHS5.2.6Рекомендуется
Интерпретация локальной части адреса (local-part)5.2.16Недопустимо
Списки рассылок и псевдонимы:
Поддержка тех и других5.3.6Рекомендуется
Отчеты для локального администратора об ошибках в списке рассылки5.3.6Обязательно
Почтовые шлюзы:
Встраивание чужого почтового маршрута в локальную часть5.2.16Возможно
Переписывание при необходимости полей заголовка5.3.7Возможно
Вставка строки Received: в начало5.3.7Обязательно
Изменение существующих строк Received:5.3.7Недопустимо
Полное восприятие RFC 822 со стороны Internet5.3.7Рекомендуется
Работа на явном маршруте RFC 8225.3.7Возможно
Передача в сторону Internet только корректных RFC 8225.3.7Обязательно
Доставка сообщений об ошибках по адресу в конверте5.3.7Рекомендуется
Установка пути возврата в конверте из пути возврата ошибки5.3.7Рекомендуется
Пользовательский агент — RFC 822:
Пользователь может вводить адрес <route>5.2.6Не рекомендуется
Поддержка пол Content Type (RFC 1049)5.2.13Возможно
Использование 4-значного года5.2.14Рекомендуется
Генерация временных зон в форме чисел5.2.14Рекомендуется
Восприятие всех временных зон5.2.14Обязательно
Использование нечисловых временных зон RFC 8225.2.14Обязательно
Опускание фразы перед route-addr5.2.15Возможно
Восприятие и разборка доменных имен dot.dec.5.2.17Обязательно
Восприятие всех форматов адреса RFC 8225.2.18Обязательно
Генерация адресов в некорректных форматах (RFC 822)5.2.18Недопустимо
Полные доменные имена в заголовке5.2.18Обязательно
Создание явного маршрута в заголовке5.2.19Не рекомендуется
Восприятие явного маршрута в заголовке5.2.19Обязательно
Прием/передача сообщений не менее 64 кбайт.5.3.8Обязательно

6. Служебные протоколы

6.1. Трансляция доменных имен

6.1.1. Введение

Каждый хост должен реализовать программу resolver для DNS и механизм использования этой программы для преобразования имен хостов в адреса IP и обратно [DNS:1, DNS:2].

В дополнение к DNS хост может поддерживать механизм преобразования имен на основе поиска в локальной таблице имен хостов Internet (см. параграф 6.1.3.8).

6.1.2. Общие вопросы

Разработчики должны внимательно ознакомиться с документами [DNS:1] и [DNS:2], содержащими описания теории, протоколов и реализации системы доменных имен с учетом реального опыта.

6.1.2.1. Записи RR с TTL=0: RFC 1035, 3.2.1

Серверы имен и резольверы DNS должны корректно обрабатывать RR с нулевым значением TTL, возвращая клиенту запись RR, но не кэшируя ее.

6.1.2.2. Значения QCLASS: RFC 1035, 3.2.5

Запросы с QCLASS=* не рекомендуется использовать, если запрашивающая сторона не просматривает данные из нескольких классов. В частности, если запрашивающая сторона интересуется только типами данных Internet, необходимо использовать QCLASS=IN.

6.1.2.3. Неиспользуемые пол: RFC 1035, 4.1.1

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

6.1.2.4. Сжатие: RFC 1035, 4.1.4

Серверы имен должны использовать в откликах сжатие данных.

6.1.2.5. Запрет на использование конфигурационных сведений: RFC 1035, 6.1.2

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

6.1.3. Частные вопросы

6.1.3.1. Реализация программы преобразования

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

При разработке программ-резольвером могут выбраны различные модели — полнофункциональный резольвер (full-service resolver) или тупиковый (stub) резольвер.

6.1.3.2. Транспортные протоколы

Программы преобразования и рекурсивные серверы DNS должны поддерживать протокол UDP (рекомендуется также поддержка TCP) для передачи запросов (не для переноса зон). Отметим также, что при передаче запроса, не относящегося к передаче зоны, сначала должен использоваться протокол UDP. Если раздел Answer (ответ) в отклике отсечен и запрашивающая программа поддерживает TCP, рекомендуется повторить запрос с использованием TCP.

Серверы DNS должны обслуживать запросы UDP; рекомендуется обслуживать также TCP-запросы. Сервер имен может ограничить ресурсы для обслуживания запросов TCP, но не рекомендуется отказываться от обработки таких запросов лишь потому, что они могли быть обслужены по протоколу UDP.

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

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

Сервер DNS должен иметь достаточно внутренних ресурсов для продолжения обработки запросов UDP во время ожидания отклика или при переносе зоны через открытое соединение TCP [DNS:2].

Сервер может поддерживать запросы UDP, для доставки которых используются групповые или широковещательные адреса IP. Однако для запросов с групповым адресом недопустимо устанавливать бит RD (Recursion Desired — желательна рекурсия) и запросы в групповых или широковещательных пакетах с установленным битом RD должны игнорироваться сервером имен. Хостам, передающим запросы DNS с использованием широковещательного или группового адреса рекомендуется передавать их таким способом только в редких случаях — поместив в кэш IP-адрес(а) из отклика, хост в дальнейшем может передавать нормальные запросы по этому адресу.

6.1.3.3. Эффективное использование ресурсов

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

  1. Резольвер должен обеспечивать управление повторной передачей для того, чтобы не расходовать излишней полосы каналов связи; кроме того, должно ограничиваться количество ресурсов, потребляемых для отклика на один запрос (конкретные рекомендации можно найти на страницах 43-44 работы [DNS:2]).

  2. После того, как запрос был передан несколько раз без отклика, программа должна прекратить попытки и сообщить приложению о некритичной ошибке.

  3. Всем серверам DNS и резольверам рекомендуется кэшировать временные неполадки с периодом ожидания в несколько минут.

    • Обсуждение
    • Это будет предотвращать избыточный трафик DNS от приложений, которые немедленно повторяют запрос при получении информации о некритичной ошибке в нарушение требований параграфа 2.2 настоящего документа.
  4. Всем серверам DNS и резольверам рекомендуется кэшировать негативные отклики, которые говорят, что заданное им не существует (в соответствии с требованиями [DNS:2]).

  5. При повторении серверами DNS и резольверами запросов UDP рекомендуется использовать экспоненциальный алгоритмизменения периода повторов, для которого рекомендуется задавать верхнюю и нижнюю границу.

    • Реализация
    • Рекомендуется использовать измеренные значения RTT и вариаций (если возможно) для расчета начального периода повтора запросов. Если такая информация недоступна, рекомендуется использовать по умолчанию период повтора не менее 5 секунд. Реализации могут ограничивать интервал повторной передачи, но эта граница должна превышать удвоенное значение максимального времени жизни сегмента в Internet с учетом задержки при обработке на сервере имен.
  6. Когда сервер или резольвер получает ответ Source Quench для переданного запроса, рекомендуется приложить усилия для снижения частоты запросов к этому серверу в ближайшем будущем; Сервер может игнорировать отклики Source Quench, получаемые в результате передачи дейтаграмм-откликов.

    • Реализация
    • Рекомендуется для снижения частоты запросов к серверу попытаться использовать другой сервер, если таковые имеются. Другим вариантом является увеличение периода повторов для запросов к серверу.

6.1.3.4. Многодомные хосты

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

6.1.3.5. Возможности расширения

Программы DNS должны поддерживать все хорошо известные, не зависящие от классов форматы [DNS:2]; рекомендуется при разработке программ минимизировать возможные издержки при введении новых типов well-known и локальных экспериментах с нестандартными типами.

6.1.3.6. Состояние типов RR

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

6.1.3.7. Устойчивость

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

6.1.3.8. Локальный список хостов

6.1.4. Пользовательский интерфейс DNS

6.1.4.1. Администрирование DNS

Этот документ посвящен вопросам архитектуры и реализации программ для хостов и не связан с администрированием и поддержкой. Однако вопросы администрирования весьма важны в DNS, поскольку ошибки в отдельных сегментах большой распределенной базы данных могут повлиять на работу множества сайтов. Вопросы администрирования подробно рассматриваются в [DNS:6] и [DNS:7].

6.1.4.2. Интерфейс DNS — пользователь

Хост должен обеспечивать интерфейс с DNS для всех прикладных программ на хосте. Этот интерфейс обычно направляет все запросы системному процессу для выполнения функций преобразования имен [DNS:1, 6.1:2].

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

6.1.4.3. Возможности сокращений

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

6.1.5. Требования к DNS

ФункцияПараграфТребования
Общие вопросы:
Преобразование имени в адрес6.1.1Обязательно
Преобразование адреса в им6.1.1Обязательно
Поддержка преобразований с использованием таблицы хостов6.1.1Возможно
Корректна обработка RR c TTL=06.1.2.1Обязательно
Необязательность использования QCLASS=*6.1.2.2Рекомендуется
Использование QCLASS=IN для Internet6.1.2.2Обязательно
Нулевые значения неиспользуемых полей6.1.2.3Обязательно
Использование сжатия в откликах6.1.2.4Обязательно
Включение конфигурационной информации в отклики6.1.2.5Недопустимо
Поддержка всех хорошо известных, независимых от класса типов6.1.2.5Обязательно
Легко расширяемый список типов6.1.2.5Рекомендуется
Загрузка всех типов RR (кроме MD и MF)6.1.2.6Обязательно
Загрузка типа MD или MF6.1.2.6Недопустимо
Работоспособность при недоступности корневого сервера и т. п.6.1.2.7Обязательно
Программа преобразования (resolver):
Поддержка множества одновременных запросов6.1.3.1Рекомендуется
Полнофункциональный резольвер:6.1.3.1Возможно
локальное кэширование6.1.3.1Обязательно
старение данных в локальном кэше6.1.3.1Обязательно
настройка конфигурации при старте6.1.3.1Рекомендуется
Заглушка,6.1.3.1Возможно
использование резервных серверов имен (рекурсия)6.1.3.1Обязательно
локальное кэширование6.1.3.1Возможно
старение данных в локальном кэше6.1.3.1Обязательно
Поддержка многодомных удаленных хостов:
Сортировка адресов в порядке предпочтения6.1.3.4Рекомендуется
Транспортные протоколы:
Поддержка запросов UDP6.1.3.2Обязательно
Поддержка запросов TCP6.1.3.2Рекомендуется
Передача запросов сначала с помощью UDP6.1.3.2Обязательно
Использование TCP, если UDP-запросы отвергнуты6.1.3.2Рекомендуется
Сервер имен ограничивает ресурсы для запросов по TCP6.1.3.2Возможно
«Наказание» для неоправданных запросов TCP6.1.3.2Не рекомендуется
Использование «усеченных» данных, как нормальных6.1.3.2Недопустимо
Частное соглашение на использование только TCP6.1.3.2Возможно
Использование TCP для переноса зон6.1.3.2Обязательно
Использование TCP не блокирует запросов UDP6.1.3.2Обязательно
Поддержка групповых и широковещательных запросов6.1.3.2Возможно
Бит RD в запросе установлен6.1.3.2Недопустимо
Бит RD игнорируется сервером для групповых и широковещательных запросов6.1.3.2Обязательно
Редкая передача только для получения адресов серверов имен6.1.3.2Рекомендуется
Использование ресурсов:
Управление передачей в соответствии с [DNS:2]6.1.3.3Обязательно
Конечные границы для запроса6.1.3.3Обязательно
Сообщение о некритичной ошибке после нескольких неудач6.1.3.3Обязательно
Кэширование временных отказов6.1.3.3Рекомендуется
Кэширование негативных откликов6.1.3.3Рекомендуется
Повторы с экспоненциальным периодом6.1.3.3Рекомендуется
Верхняя и нижняя граница6.1.3.3Рекомендуется
Клиент обрабатывает Source Quench6.1.3.3Рекомендуется
Сервер игнорирует Source Quench6.1.3.3Возможно
Пользовательский интерфейс:
Все программы имеют доступ к интерфейсу DNS6.1.4.2Обязательно
Возможность запросить всю информацию для данного имени6.1.4.2Обязательно
Возврат полной информации или сообщения об ошибке6.1.4.2Обязательно
Специальные интерфейсы6.1.4.2Возможно
Трансляция им <-> адрес6.1.4.2Обязательно
Возможности сокращений:6.1.4.3Возможно
Соглашение для полных имен6.1.4.3Обязательно
Однократное преобразование6.1.4.3Обязательно
Преобразование в приемлемом контексте6.1.4.3Обязательно
Список поиска:6.1.4.3Возможно
Администратор может запретить6.1.4.3Рекомендуется
Предотвращение излишних корневых запросов6.1.4.3Обязательно
Оба метода6.1.4.3Рекомендуется

6.2. Инициализация хоста

6.2.1. Введение

В этом разделе описана инициализация программ хоста через подключенную сеть или (в более общем случае) через Internet. Такие операции требуются для бездисковых станций, но могут использоваться и для хостов с дисками. Для бездисковых хостов процесс инициализации называется загрузкой из сети (network booting) и управляется программой загрузки (bootstrap), хранящейся в ПЗУ (boot ROM).

При инициализации бездисковых хостов через сеть выделяют две фазы:

  1. Настройка уровня IP.

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

  2. Загрузка системного кода для хоста.

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

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

6.2.2. Требования

6.2.2.1. Динамическая настройка конфигурации

Для динамической настройки поддерживается целый ряд протоколов и служб.

Для динамической настройки хостов предлагается использовать протокол BOOTP с расширением BOOTP Vendor Information Extensions, определенным в RFC 1084 [BOOT:3]. RFC 1084 некоторые важные особенности такого расширения, не зависящие от реализации. В частности, это расширение позволяет протоколу BOOTP обеспечивать информацию о маске сети; рекомендуется передавать маски сетей в соответствии с этим документом.

6.2.2.2. Фаза загрузки

На этапе загрузки предлагается использовать протокол TFTP [BOOT:1] на основе адреса IP, полученного по BOOTP. Не рекомендуется использовать TFTP с широковещательным адресом, по причинам, рассмотренным выше (см. 4.2.3.4).

6.3 Удаленное управление

6.3.1. Введение

Сообщество Internet внесло значительный вклад в разработку протоколов сетевого управления [MGT:1, MGT:6] — в результате этого были разработаны протоколы SNMP (Simple Network Management Protocol — простой протокол сетевого управления) [MGT:4] и CMOT (Common Management Information Protocol over TCP — протокол передачи управляющей информации через TCP) [MGT:5].

Для управления с помощью протоколов SNMP или CMOT хост должен поддерживать соответствующий агент управления. В состав хостов Internet рекомендуется включать агент для протокола SNMP или CMOT.

Оба протокола SNMP и CMOT работают на основе MIB (Management Information Base — база информации для управления), определяющих набор объектов и значений для управления устройствами. Читая и меняя значения параметров, удаленное приложение может запрашивать и изменять состояние управляемой системы.

Стандарт MIB [MGT:3] был разработан для использования в обоих протоколах управления на основе типов данных, определенных SMI (Structure of Management Information — структура управляющей информации) [MGT:2]. Дополнительные переменные MIB могут включаться в ветви enterprises и experimental пространства имен MIB [MGT:2].

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

6.3.2. Общие вопросы

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

Управляемый хост должен реализовать следующие группы определений объектов MIB: System, Interfaces, Address Translation, IP, ICMP, TCP, UDP.

Ниже перечислены конкретные интерпретации, применимые к хостам:

Текущая спецификация MIB не включает тип обслуживания TOS в записи ipRouteEntry, но в будущих реализациях этот параметр будет включен.

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

6.3.3. Требования к функциям управления

ФункцияПараграфТребования
Поддержка агента SNMP или CMOT6.3.1Рекомендуется
Реализация указанных объектов в стандартной базе MIB6.3.1Рекомендуется

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

В этом разделе перечислены основные и дополнительные источники информации по рассмотренным в документе вопросам.

  1. [INTRO:1] "Requirements for Internet Hosts — Communication Layers," IETF Host Requirements Working Group, R. Braden, Ed., RFC 1122, October 1989
  2. [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.
  3. [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, RFC 1011, May 1987.
  4. [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC 980, March 1986.
  5. [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC 1010, May 1987.
  6. [TELNET:1] "Telnet Protocol Specification," J. Postel and J. Reynolds, RFC 854, May 1983.
  7. [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, RFC 855, May 1983.
  8. [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, RFC 856, May 1983.
  9. [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC 857, May 1983.
  10. [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. Reynolds, RFC 858, May 1983.
  11. [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC 859, May 1983.
  12. [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, RFC 860, May 1983.
  13. [TELNET:8] "Telnet Extended Options List," J. Postel and J. Reynolds, RFC 861, May 1983.
  14. [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC 885, December 1983.
  15. [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC 1091, February 1989.
  16. [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC 1073, October 1988.
  17. [TELNET:12] "Telnet Linemode Option," D. Borman, RFC 1116, August 1989.
  18. [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC 1079, December 1988.
  19. [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC 1080, November 1988.
  20. [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of Defense, May 1984.
  21. [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC 734, October 1977.
  22. [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC 736, October 1977.
  23. [TELNET:18] "Data Entry Terminal Option," J. Day, RFC 732, June 1977.
  24. [TELNET:19] "TELNET Data Entry Terminal option — DODIIS Implementation," A. Yasuda and T. Thompson, RFC 1043, February 1988.
  25. [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC 959, October 1985.
  26. [FTP:2] "Document File Format Standards," J. Postel, RFC 678, December 1974.
  27. [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of Defense, May 1984.
  28. [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC 783, June 1981.
  29. [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC 821, August 1982.
  30. [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," D. Crocker, RFC 822, August 1982.
  31. [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC 974, January 1986.
  32. [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC 1047, February 1988.
  33. [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC 987, June 1986.
  34. [SMTP:5b] "Addendum to RFC 987," S. Kille, RFC 1026, September 1987.
  35. [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. Department of Defense, May 1984.
  36. [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, RFC 1049, March 1988.
  37. [DNS:1] "Domain Names — Concepts and Facilities," P. Mockapetris, RFC 1034, November 1987.
  38. [DNS:2] "Domain Names — Implementation and Specification," RFC 1035, P. Mockapetris, November 1987.
  39. [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC 974, January 1986.
  40. [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, RFC 952, M. Stahl, E. Feinler, October 1985.
  41. [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, RFC 953, October 1985.
  42. [DNS:6] "Domain Administrators Guide," M. Stahl, RFC 1032, November 1987.
  43. [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC 1033, November 1987
  44. [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet Protocol Handbook, NIC 50007, SRI Network Information Center, August 1989.
  45. [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC 906, June 1984.
  46. [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC 951, September 1985.
  47. [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC 1084 44, December 1988.
  48. [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. Mann, J. Mogul, and M. Theimer, RFC 903, June 1984
  49. [MGT:1] "IAB Recommendations for the Development of Internet Network Management Standards," V. Cerf, RFC 1052, April 1988.
  50. [MGT:2] "Structure and Identification of Management Information for TCP/IP-based internets," M. Rose and K. McCloghrie, RFC 1065, August 1988.
  51. [MGT:3] "Management Information Base for Network Management of TCP/IP-based internets," M. Rose and K. McCloghrie, RFC 1066, August 1988.
  52. [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, M. Schoffstall, and C. Davin, RFC 1098, April 1989.
  53. [MGT:5] "The Common Management Information Services and Protocol over TCP/IP," U. Warrier and L. Besaw, RFC 1095, April 1989.
  54. [MGT:6] "Report of the Second Ad Hoc Network Management Review Group," V. Cerf, RFC 1109, August 1989.

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

Существует множество вопросов безопасности, связанных с приложениями и служебными программами, но подробное рассмотрение этих вопросов выходит за пределы данного RFC. Связанные с безопасностью темы рассмотрены в параграфах, посвященных протоколу TFTP (4.2.1, 4.2.3.4, 4.2.3.5), командам SMTP VRFY и EXPN (5.2.3), а также командам SMTP HELO (5.2.5), и SMTP DATA (Section 5.2.8).

Адрес автора

Robert Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: ude.isi@nedarb

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

Николай Малых, moc.milib@hkylamn