|
|
|
|
|||
|
|
|||||
|
|
|||||
|
|
|||||
|
Network Working Group Request for Comments: 1123
|
Internet Engineering Task Force
R. Braden, Editor
October 1989
|
||||
|
|
|||||
|
Требования к хостам Internet Прикладные и служебные протоколы
|
|||||
|
|
|||||
|
Статус документа
|
|||||
|
|
|||||
|
В данном RFC содержатся официальные спецификации сообщества Internet. Документ содержит ссылки, исправления и дополнения к первичным стандартам протоколов, имеющим отношение к хостам. Документ можно распространять свободно.
Аннотация
Этот документ является одним из двух RFC, посвященных определению и обсуждению требований к программам хостов Internet. Этот документ посвящен прикладным протоколам и протоколам поддержки, а второй документ RFC-1122 - коммуникационным протоколам канального уровня, IP и транспортного уровня.
|
|||||
|
|
|||||
|
Статус документа .......................................................................................................................................................................................... 1
Аннотация ..................................................................................................................................................................................................... 1
|
|||||
|
|
|||||
|
|
|||||
|
|
||
|
|
||
|
|
||
|
3.4.2 Команды Telnet ....................................................................................................................................................................... 11
3.4.3 Ошибки соединений TCP ....................................................................................................................................................... 11
|
||
|
|
||
|
|
||||
|
|
||||
|
|
||||
|
5.3.5 Поддержка доменных имен .................................................................................................................................................... 25
5.3.6 Списки рассылок и псевдонимы ............................................................................................................................................ 25
|
||||
|
|
||||
|
3
|
||||
|
|
||||
|
|
||
|
|
||
|
|
||
|
1. Введение
Этот документ является первым из пары RFC, определяющих и обсуждающих требования к реализации хост-систем на базе стека
протоколов Internet. Документ посвящен протоколам прикладного уровня. Второй документ - RFC-1122 Requirements for Internet
Hosts - Communications Layers" [INTRO: 1]1 - посвящен коммуникационным протоколам - канальный уровень, уровень IP (сетевой)
и транспортный уровень. С этой парой также тесно связан документ RFC-1009 - Requirements for Internet Gateways [INTRO:2]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 связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!
|
||
|
|
||
|
1 На сайте http://rfc.com.ru/ можно найти перевод этого документа на русский зык. Прим. перев.
2 Более современный вариант этого документа содержится в RFC-1812. Прим. перев.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
На
всех уровнях программ хостов Internet должны быть реализованы средства
адаптации. В качестве простого примера рассмотрим спецификацию протокола,
использующего численные значения для какого-либо пол в заголовке (например,
тип, номер порта или код ошибки) - при разработке следует предполагать,
что используемая нумерация неполна. Если спецификация протокола предполагает
четыре возможных кода ошибки, приложение должно уметь обрабатывать по
крайней мере пять типов ошибок (4 заданных и все остальные). Появление
не определенных в спецификации кодов должно протоколироваться (см. ниже),
но не должно нарушать работу системы.
Почти так же важен и другой аспект - программы на других хостах могут содержать определения, которые могут толкнуть хост на неразумные, но допустимые с точки зрения протокола действия. Естественным решением будет “поиск неразумных хостов” -
программы хоста должны быть готовы не просто переносить появление неразумных хостов, но и участвовать в процессе ограничения вредных воздействий, которые подобные хосты могут нанести сетевым объектам общего пользования.
1.2.3 Протоколирование ошибок
Сеть Internet включает огромное количество разнотипных хостов и шлюзов, в каждом из которых реализовано множество протоколов и уровней - некоторые из хостов и маршрутизаторов наверняка содержат ошибки в программах стека протоколов Internet. В результате сложности, разнотипности и использования распределенных функций диагностика Internet является весьма непростой задачей.
Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов. При записи таких событий важно включать максимум диагностической информации. Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки. Однако следует знать меру - средства протоколирования ошибок не должны отнимать слишком много ресурсов хоста и снижать эффективность его работы.
При записи информации об ошибках существует вероятность получения журнальных файлов огромного размера - таких ситуаций можно избежать, используя “циклический” журнал или включая запись только для диагностики определенных сбоев. Полезно также фильтровать и считать повторяющиеся последовательные сообщения. Представляется привлекательной приведенная ниже стратеги:
(1) всегда считать аномальные события и делать содержимое счетчиков доступным с помощью средств управления сетью (см. параграф 6.3);
(2) поддерживать возможность выбора протоколируемых событий (например, записывать все ошибки, связанные с хостом X). Отметим, что разные системы управления сетью могут придерживаться различных правил в части числа протоколируемых ошибок для каждого хоста. Некоторые системы исходят из принципа: “если это не имеет ко мне прямого отношения, не хочу об этом знать", тогда, как другие системы прилагают максимум усилий для обнаружения и устранения аномалий в поведении сетевых протоколов.
1.2.4 Конфигурационные параметры
Идеальной реализацией хоста будет та, на которой настройка стека протоколов Internet будет полностью автоматизирована (self-configuring). Это позволит реализовать весь стек в ПЗУ или встроить в микросхемы оборудования - такое решение упростит организацию бездисковых станций, снимет значительную часть нагрузки с сетевых администраторов и упростит разработку систем. Однако этот идеал недостижим и на практике к нему не удается даже серьезно приблизиться.
В этом документе вы будете часто встречать требования, параметры которых являются опциями настройки. Существует несколько причин появления таких требований. В некоторых случаях это обусловлено отсутствием согласи по вопросу выбора наилучшего значения и в будущем может потребоваться установка иного значения параметра. В других случаях значение параметра может зависеть от внешних факторов (например, скорость и топология соседних сетей) и алгоритмы автоматической настройки могут отсутствовать или не обеспечивать полной настройки параметров. Причиной использования таких параметров могут послужить и административные требования.
Наконец, часть конфигурационных опций может потребоваться для обеспечения взаимодействия с устаревшими или содержащими ошибки реализациями протоколов, распространяемыми без исходных текстов (к несчастью, такое встречается в 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 Терминология
Ряд используемых в документе технических терминов определен в данном параграфе.
Сегмент - Segment
Сегментом будем называть модуль3 (unit) данных, используемый для сквозной передачи по протоколу TCP. Сегмент состоит из заголовка TCP, за которым следуют данные. Сегменты передаются с использованием инкапсуляции в дейтаграммы IP.
Сообщение - Message
Этот термин используется некоторыми протоколами прикладного уровня (в частности, SMTP) для обозначения модулей данных приложений.
Дейтаграмма
Дейтаграмма [UDP] представляет собой модуль данных, используемый для передачи по протоколу UDP.
Multihomed
Хост называют многодомным (multihomed) если он имеет более одного адреса IP.
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]. Однако, одно из требований к именам изменено настоящим документом
- в качестве первого символа имени может использоваться буква латиницы или цифра4. Программы хостов должны следовать
более либеральному требованию настоящего документа.
Программы хостов должны поддерживать имена длиной до 63 символов и рекомендуется поддерживать имена размером до 255
символов.
Рекомендуется обеспечивать возможность идентификации хостов с помощью (1) доменного имени хоста или (2) IP-адреса в
десятичном формате с разделением точками (#.#.#.#). Для хостов рекомендуется проверять синтаксически введенный IP-адрес до
обращения к DNS.
|
||
|
|
||
|
3 Термином модуль будем обозначать неделимую при передаче на данном уровне совокупность данных. Прим. перев.
4 RFC-952 разрешает для первого символа только буквы английского алфавита. Прим. перев.
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Обсуждение
Последнее требование не означает проверку синтаксиса введенного адреса - этот вопрос должен решаться на уровне пользовательского интерфейса. Например, адреса IP должны указываться в квадратных скобках [ ] для почтовых программ SMTP (см. 5.2.17). Такое обозначение может быть сделано универсальным в масштабе хоста, что позволяет упростить синтаксическую проверку вводимых адресов.
Если адреса можно указывать без ограничителей такого типа, требуется выполнять их полную синтаксическую проверку, поскольку им хоста может начинаться с цифр и даже содержать только цифры (см. параграф 6.1.2.4). Однако корректное имя хоста никогда не может иметь вид корректного адреса IP в формате #.#.#.#, поскольку по крайней мере компонента (домен) верхнего уровня должна быть буквенной.
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 битов, из которых используются только три старших бита, а два оставшихся должны иметь нулевое значение. Обсуждение
По мере разработки алгоритмов поддержки TOS маршрутизаторами рекомендуемые значения типа обслуживания для
различных прикладных протоколов могут изменяться. Кроме того, очевидно, что для различных комбинаций пользователей и
путей Internet могут возникать потребности в использовании нестандартных значений TOS. Исход из этих соображений,
значения TOS должны быть настраиваемыми.
Рекомендуемые значения TOS для различных прикладных протоколов можно найти в документе "Assigned Numbers"
[INTRO:5].
2.5 Требования общего плана
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Функция Параграф Требования
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
реобразование доменных имен в соответствии с параграфом 6.2 2.2 Обязательно
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
3. Удаленный доступ по протоколу TELNET 3.1 Введение
Telnet представляет собой стандартный протокол Internet для удаленного доступа в систему. Протокол обеспечивает правила кодирования для “связывания” клавиатуры и монитора на клиентском компьютере с командным интерпретатором удаленного сервера. Часть протокола Telnet включена также в другие протоколы прикладного уровня (например, FTP и SMTP).
5 В исходном документе ошибочно указан размер 635. Прим. перев.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
|
||
|
|
||
|
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.
Обсуждение
Хотя поддержка более изощренных “терминалов” и опций стала нормой, люба реализация должна быть готова к поддержке режима 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.
Обсуждение
Полудуплексные (locked-keyboard) терминалы line-at-a-time (строка в один прием), для которых был разработан механизм Go-Ahead, сегодня уже практически не используются. Во многих операционных системах достаточно сложно реализовать передачу сигналов Go-Ahead, даже если эта ОС поддерживает полудуплексные терминалы. Эти трудности обычно связаны с тем, что программный код сервера Telnet не имеет доступа к информации о блокировке пользовательского процесса в ожидании данных от соединения Telnet (т. е. невозможно надежно определить момент передачи команды GA). Следовательно, большинство хостов с серверами Telnet не поддерживает команду GA.
Смысл приведенных в этом параграфе правил состоит в том, что следует разрешать другой стороне соединения Telnet блокировать использование команд GA.
Существует класс полудуплексных терминалов, до сих пор находящихся в эксплуатации (терминалы ввода данных - data entry terminals), которые работают в полноэкранном режиме. Однако поддержка таких терминалов при использовании ими протокола Telnet не требует сигналов Go Ahead (см. 3.3.2).
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, которые он не поддерживает.
Обсуждение
Отметим, что сервер Telnet должен поддерживать функцию Telnet IP (Interrupt Process - прерывание процесс), даже при наличии на хосте эквивалента этой функции (например, комбинация клавиш Control-C во многих системах). Функция Telnet IP может быть сильнее такой команды прерывания, поскольку использует срочные данные TCP.
Управляющая функция EOR может использоваться для задания границ потока. Важным применением этой функции является поддержка терминалов ввода данных (см; 3.3.2). Обратим внимание, что команда EOR не была определена в RFC-854, поэтому хост, не способный корректно игнорировать неизвестные команды Telnet, может “рухнуть” при получении EOR. Для защиты таких хостов была введена опция End-of-Record [TELNET:9], однако для корректно реализованных программ 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).
Обсуждение
Для клиента Telnet существует три способа отсечения выходного потока данных сервера:
(1) Передать команду AO после IP.
В результате хост сервера будет передавать сигнал "flush-buffered-output" (отбросить буферизованный вывод) своей операционной системе. Однако команда AO может не дать локального эффекта (т. е., не остановить терминальный вывод на стороне клиента Telnet), пока сервер Telnet получает и обрабатывает команду AO и передает обратно "Synch".
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
(2) Передать
DO TIMING-MARK [TELNET:7] после IP и локально отвергать весь вывод,
пока не будет получена последовательность WILL/WONT TIMING-MARK от сервера
Telnet.
Поскольку DO TIMING-MARK обрабатывается после уровня IP на сервере, отклик на эту команду должен находиться в корректном месте выходного потока данных. Однако, TIMING-MARK не будет посылать операционной системе сервера сигнал "flush buffered output". Необходимость такого сигнала определяется операционной системой сервера Telnet.
(3) Использовать оба способа.
Который из вариантов лучше, однозначно сказать нельзя, поскольку требуется адаптация к различным хостам с серверами Telnet, которые могут не соответствовать стандартам Telnet в различных вопросах. Наиболее безопасным решением будет поддержка выбираемой пользователем опции (1), (2) или (3).
3.2.5 Принтер и клавиатура в режиме NVT: RFC-854, стр. 11
В режиме NVT серверу Telnet не рекомендуется передавать символы с установленным старшим битом6 и недопустимо использовать этот бит для контроля четности. Реализациям, передающим старший бит пользователю, рекомендуется согласовывать опцию бинарного7 режима (см. 3.2.6).
Обсуждение
Разработчики должны помнить, что RFC-854 позволяет клиентам и серверам, ожидающим NVT ASCII, игнорировать символы с
установленным старшим битом. В общем случае предполагается использование бинарного режима для передачи расширенного
(за пределы 7 битов) набора символов программам Telnet.
Однако, существуют приложения, которым реально требуется 8-битовое расширение режима NVT, не определенное в
настоящее время, и такие приложения устанавливают старший бит на все или часть времени существования соединения Telnet.
Отметим, что бинарный режим не совпадает с 8-битовым расширением NVT, поскольку в бинарном режиме отключается
обработка символов завершения строки (end-of-line). Исходя из сказанного требования к использованию старшего бита,
включают глагол рекомендуется, а не требуется.
RFC-854 определяет минимальный набор свойств виртуального сетевого терминала (NVT); это не означает запрета на
поддержку дополнительных функций в реальных терминалах. Соединения Telnet полностью прозрачны для всех 7-битовых
символов ASCII, включая дополнительные коды управления ASCII.
Например, терминал может поддерживать полноэкранные команды, кодируемые как escape-последовательности ASCII;
реализация Telnet будет передавать такие последовательности как неинтерпретируемые данные. Таким образом, режим NVT не
следует трактовать как терминал с сильно ограниченными возможностями.
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.
Обсуждение
Опция Binary обычно согласуется для обоих направлений, чтобы перевести соединение Telnet из режима NVT в двоичный
режим.
Последовательность IAC EOR может использоваться для обозначения границ блоков данных в бинарном потоке Telnet.
3.2.8 Опция типа терминала Telnet: RFC-1091
Опция Terminal-Type должна использовать названия типов терминалов, официально определенные в документе “Assigned Numbers” [INTRO:5], когда такие имена существуют для используемых терминалов. Однако приниматься должны любые значения опции Terminal-Type.
Обсуждение
RFC-1091 [TELNET:10] содержит обновленное (по сравнению с RFC-930) определение опции Terminal-Type. Прежняя версия позволяла хосту сервера поддерживать множество типов терминалов для определения типа клиентского терминала на основе предположения, что каждый физический терминал имеет собственный (intrinsic) тип. Однако сегодня терминал в большинстве случаев является на самом деле программой эмуляции терминала на базе ПК, которая зачастую может поддерживать различные типы терминалов. Следовательно, RFC-1091 расширяет спецификацию, позволяя более общее согласование типа терминала между клиентом и сервером Telnet.
3.3 Частные вопросы
3.3.1 Соглашение Telnet о завершении строки (End-of-Line0
Протокол Telnet определяет последовательность символов CR LF в качестве сигнала завершения строки (end-of-line). Для терминального ввода это соответствует завершению команды или нажатию клавиши завершения строки на пользовательском терминале (на терминалах ASCII это клавиша CR, которая может также называться Return или Enter).
Когда сервер Telnet принимает сигнал завершения строки CR LF как ввод с удаленного терминала, эффект должен быть таким же, как от нажатия клавиши завершения строки на локальном терминале. На хостах, использующих ASCII, в частности, получение сервером Telnet последовательности CR LF должно сопровождаться таким же эффектом, как нажатие клавиши CR на локальном терминале. Таким образом, последовательности CR LF и CR NUL должны иметь одинаковый эффект на серверных хостах ASCII при получении ввода от соединений Telnet.
|
||
|
|
||
|
6 Коды ASCII > 127. Прим. перев.
7 Т. е. не текстового. Прим. перев.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Клиент Telnet должен обеспечивать возможность передачи любой из последовательностей CR LF, CR NUL и LF. Клиентам Telnet на хостах ASCII рекомендуется обеспечивать пользователю возможность выбора последовательности CR LF или CR NUT при нажатии клавиши завершения строки (по умолчанию следует использовать последовательность CR LF).
Последовательность завершения строки Telnet CR LF должна использоваться для передачи данных Telnet, которые не относятся к типу “терминал-хост” (например, при передаче вывода от сервера Telnet или встраивании других прикладных протоколов в Telnet).
Обсуждение
Для обеспечения интероперабельности между различными серверами и клиентами Telnet в протоколе Telnet определено
стандартное представление сигнала завершения строки. Поскольку ASCII не включает в явном виде символа завершения строки
(end-of-line), могут использоваться различные варианты, в зависимости от системы (например, CR, LF, CR LF). В качестве
стандартной протокол Telnet определяет последовательность CR LF.
К сожалению, спецификация протокола Telnet в RFC-854 [TELNET: 1] не указывает однозначно символов, которые должны
передаваться от клиента к серверу при нажатии клавиши завершения строки. В результате отсутствия однозначности постоянно
возникают проблемы с интероперабельностью, порождаемой различными недостаточно корректными реализациями клиентов и
серверов Telnet.
Хотя протокол Telnet основан на симметричной модели взаимодействия, в сеансах удаленного доступа роли пользовательского
терминала и серверного хоста различаются. Например, RFC-854 определяет CR, LF и CR LF как выходные последовательности
сервера, но не задает: какие символы должны передаваться со стороны клиента Telnet при нажатии на терминале клавиши
завершения строки.
При нажатии пользователем клавиши завершения строки некоторые реализации клиентов Telnet передают последовательность
CR LF, а другие - CR NUL (в результате различной интерпретации одного и того же предложения в тексте RFC-854). Эти
последовательности будут эквиваленты для корректно реализованных серверов на хостах ASCII, как было показано выше. Для
других серверов требуется выбор режима в клиентской реализации Telnet.
Существование клиентов Telnet, которые передают только CR NUL при нажатии клавиши CR, порождает дилемму для хостов,
не поддерживающих ASCII - трактовать CR NUL на входе как эквивалент CR LF, препятствуя возможности ввода только CR,
или полностью терять связь с сетью.
Предположим, что пользователь на хосте А применяет Telnet для доступа к серверу на хосте В, запуска на этом хосте (В)
другого клиента Telnet для работы с сервером на хосте С. Для комбинации клиент/сервер Telnet на хосте В желательно
обеспечить прозрачность (т. е. для хоста А такое подключение должно выглядеть, как прямое соединение с сервером С). В
частности, корректна реализация будет обеспечивать прозрачность для Telnet-последовательностей завершения строки (за
исключением преобразования CR LF в CR NUL и обратно).
Реализация
Чтобы разобраться с вопросами трактовки завершения строки в Telnet, нужно понять по крайней мере общую модель взаимодействия Telnet с локальной ОС. Серверный процесс Telnet обычно встроен в терминальный драйвер операционной системы как псевдотерминал. Последовательность завершения строки, принимаемая сервером Telnet должна давать такой же эффект, как нажатие клавиши завершения строки на локально подключенном терминале.
Операционные системы, поддерживающие интерактивные приложения character-at-a-time (например, текстовые редакторы), обычно поддерживают два внутренних режима для своих терминалов ввода-вывода - форматированный режим, при котором к потоку данных применяется соглашение о завершении строки и другие правила форматирования, и режим необработанного текста (raw), при котором приложение имеет прямой доступ к символу сразу после его ввода. Серверы Telnet должны быть реализованы таким образом, чтобы оба режима имели одинаковый эффект для локальных и удаленных терминалов. Для примера предположим, что последовательность CR LF или CR NUL принимается сервером Telnet на хосте ASCII. В режиме raw передается приложению символ CR, а в форматированном режиме используется локальное соглашение о символах завершения строки.
3.3.2 Терминалы ввода данных (Data Entry Terminals)
Обсуждение
В дополнение к строковым (line-oriented) и символьным (character-oriented) терминалам ASCII, для которых был разработан протокол Telnet, существует еще несколько семейств видео-терминалов, которые называют также "data entry terminals" (терминалы ввода данных) или DET. Семейство IBM 3270 является широко известным примером такого типа терминалов. Для поддержки базовых типов DET были разработаны два протокола Internet - SUPDUP [TELNET: 16, TELNET: 17] и опция DET [TELNET: 18, TELNET: 19]. Опция DET обслуживает терминалы ввода данных через соединения Telnet с использованием (суб)согласования. SUPDUP представляет собой самостоятельный терминальный протокол, который может быть введен из Telnet путем согласования. Хотя протокол SUPDUP и опцию DET можно успешно использовать в отдельных типах сред, не один из этих вариантов не обеспечивает универсальности.
Другим вариантом использования DET является реализация поддержки семейства терминалов IBM 3270 с помощью Telnet (это применимо к любым терминалам DET). Идея состоит в создании режима native DET, в котором оригинальные потоки ввода-вывода DET передаются как двоичные данные. Команда Telnet EOR используется в этом случае для обозначения границ логических записей (например, "экранов") в двоичном потоке.
Реализация
Для активизации и отключения режима native DET используются следующие правила:
• Сервер использует опцию Terminal-Type [TELNET: 10] для определения принадлежности клиента к DET.
• Обе стороны согласуют опцию EOR [TELNET:9] (это общепринято, но не обязательно).
• Обе стороны согласуют опцию Binary [TELNET: 3] для перехода в режим native DET.
• Когда одна из сторон выходит из бинарного режима, друга сторона также должна сделать это, вернувшись в режим NVT.
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], если локальная ОС обеспечивает соответствующие возможности.
Обсуждение
|
||
|
|
||
|
|
||||
|
|
||||
|
|
||||
|
Отметим, что опция End-of-Record (конец записи) означает лишь, возможность Telnet получать Telnet EOR без краха; следовательно, каждый модуль Telnet может попытаться согласовать опцию End-of-Record (см. 3.2.3).
3.3.4 Инициирование согласования опций
При использовании протокола Telnet в режиме клиент-сервер для сервера рекомендуется инициировать согласование режима взаимодействия с терминалом, который ожидает сервер.
Обсуждение
Протокол Telnet был определен как симметричный, но его реальное применение обычно бывает асимметричным. Удаленный вход в систему терпит крах, когда ни одна из сторон не инициирует согласование требуемых ей опций, которые не установлены по умолчанию. Обычно сервер определяет предпочтительный режим, поэтому сервер и должен инициировать согласование опций. Поскольку процесс согласования является симметричным, клиент также может быть инициатором.
Клиентам Telnet рекомендуется предоставлять пользователю возможность разрешить или запретить инициативу клиента по
согласованию опций.
Обсуждение
Пользователям иногда требуется подключение к прикладным службам (например, FTP или SMTP), которые используют протокол Telnet для управления своими потоками данных, но не поддерживают опции Telnet. Для этих целей может использоваться клиент Telnet, если инициатива по согласованию опций для этого клиента запрещена.
3.3.5 Опция Telnet Linemode
Обсуждение
Важную роль играет новая опция Telnet LINEMODE [TELNET:12], обеспечивающая возможность согласования между клиентом и сервером обработки терминальных символов на стороне клиента, а не сервером. Когда клиент подготовит всю строку текста, он будет передавать ее серверу (обычно) в одном сегменте TCP. Эта опция позволяет существенно снизить число пакетов в сеансах Telnet и значительно ускорить отклик в нагруженных сетях или при значительных задержках в сети. Опция LINEMODE позволяет динамически переключаться между локальной и удаленной обработкой символов. Например, соединение Telnet будет автоматически переходить в посимвольный режим при работе с полноэкранным редактором и возвращаться в строковый режим при завершении работы с редактором.
Предполагается, что после выпуска этого RFC хосты будут реализовать эту опцию для клиентских программ. Для корректной реализации опции на серверах последние должны обеспечивать возможность сказать локальной операционной системе, что не нужно обрабатывать символьный ввод, но следует запоминать текущее состояние терминала и уведомлять серверный процесс Telnet при изменении состояния. Это позволит обеспечить корректный вывод эхо-символов паролей и нормальную работу полноэкранных редакторов.
3.4 Пользовательский интерфейс TELNET
3.4.1 Прозрачность набора символов
Для реализаций клиентов Telnet рекомендуется обеспечивать возможность приема и передачи любых 7-битовых символов ASCII.
Рекомендуется по возможности обходить все интерпретации специальных символов операционной системой пользовательского
хоста, чтобы такие символы могли удобно приниматься и передаваться через соединение.
Какой-либо символ должен быть зарезервирован для перехода в командный режим (escape to command mode) с дублированием
этого символа, когда он встречается в потоке данных. Рекомендуется предоставлять пользователю возможность выбора такого
символа.
Для двоичных соединений клиент Telnet может обеспечивать escape-механизм для введения произвольных 8-битовых символов,
если операционная система хоста не позволяет вводить такие символы непосредственно с клавиатуры.
Реализация
Вопросы прозрачности менее актуальны для серверов, но разработчики должны быть аккуратны и в этом случае - маскировать биты четности (передаются старыми, нестандартными клиентами) до того, как они будут переданы программам, ожидающим только NVT ASCII, и корректно обслуживать программы, запрашивающие 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 от сервера, рекомендуется обеспечить пользователю возможность вручную восстанавливать нормальный вывод, когда сервер не передает ожидаемый сигнал.
|
||||
|
|
||||
|
11
|
||||
|
|
||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
3.5. Требования к TELNET
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Функция Параграф Требования
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
4. Передача файлов
4.1 Протокол передачи файлов - FTP
4.1.1 Введение
Протокол передачи файлов FTP является основным средством обмена файлами в сети Internet. Текущая спецификация протокола содержится в RFC-9598 [FTP:1].
FTP обеспечивает независимые одновременные соединения TCP для управления и передачи данных. Протокол FTP включает множество возможностей, из которых только часть относится к общеприменимым. Однако для каждой из возможностей FTP существует, по крайней мере, одна реализация. Минимальна реализация, оговоренная в RFC-959, оказалась слишком примитивной, поэтому здесь определяются некоторые дополнительные требования.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
8 В RFC-2228 (безопасность) и RFC-2640 (интернационализация) содержится ряд дополнений к этой спецификации. Прим. перев.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
|
||
|
|
||
|
Пользователи 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.
Обсуждение
Команда TYPE L 8 часто требуется для передачи двоичных данных между машинами, память которых организована (например) в 36-битовые слова, и машинами с байтовой (8 битов) организацией памяти. Для машин с байтовой организацией памяти типы L 8 и IMAGE эквивалентны.
TYPE L m иногда используется программами FTP при обмене между двумя машинами с m-битовыми словами для обеспечения корректной передачи данных в естественном формате с одной машины на другую. Однако, эта команда на таких машинах должна обеспечивать такой же эффект, как TYPE I.
4.1.2.2 Управление форматом Telnet: RFC-959, 3.1.1.5.2
Хостам, не делающим различий между TYPE N и TYPE T, рекомендуется реализовать тип T идентично типу N. Обсуждение
Такое решение должно упрощать интероперабельность с хостами, которые различают эти типы.
Многие хосты используют для текстовых файлов внутреннее представление в виде строк символов ASCII, используя встроенные символы форматирования ASCII (LF, BS, FF, ...) для управления форматом при печати. Для таких хостов не существует разницы между пригодными для печати файлами и остальными типами файлов. Однако, системы, которые используют структурированные в виде записей файлы, требуют для печати использования специальных форматов (например, ASA для управления кареткой). Для таких хостов протокол FTP позволяет выбирать типе - TYPE N или TYPE T.
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 рекомендуется делать обратимыми, чтобы расширить возможности использования файла на хосте получателе.
Обсуждение
RFC-959 требует обратимости преобразований структуры между record-structure и file-structure, но на практике вопросы эффективности и удобства зачастую препятствуют такой обратимости и требование остается невыполненным. Существует два различных подхода к передаче файлов - хост-получатель обрабатывает файлы или просто сохраняет их. Для варианта простого сохранения обратимость преобразований имеет важное значение. При обработке файлов получателем файл, создаваемый на приемной стороне, должен использовать формат, ожидаемый прикладной программой на этом хосте.
В качестве примера конфликта рассмотрим ориентированные на записи ОС, которые требуют, чтобы некоторые файлы данных использовали записи размером в точности 80 байтов. При сохранении файла на таком хосте сервер FTP должен обеспечивать возможность дополнения каждой строки или записи до требуемых 80 байтов; при последующем обращении к таким файлам исходное состояние не всегда можно восстановить (необратимое преобразование).
4.1.2.5 Data Connection Management: RFC-959, 3.3
FTP-клиентам, которые используют потоковый режим (STREAM), рекомендуется посылать команду PORT для выделения нестандартного (non-default) порта для передачи данных по каждой из команд.
Обсуждение
Это требование обусловлено наличием значительной задержки между закрытием соединения TCP для пары сокетов и возможностью организации повторного соединения для этой же пары. Использование нестандартных портов позволяет организовать множество потоков данных в одном сеансе FTP. Передачи команды PORT можно избежать при использовании других режимов (не потокового), оставляя открытым соединение для передачи данных.
4.1.2.6 Команда PASV: RFC-959, 4.1.2
Сервер FTP должен поддерживать команду PASV.
Если в одной сессии организуется множество передач файлов различным клиентам, новые команды PASV должны вводиться перед
каждой командой новой передачи для получения уникального номера порта.
Реализация
Формат отклика 227 на команду PASV не стандартизован должным образом. В частности, клиент FTP не может предполагать наличие круглых скобок, показанных на странице 40 в RFC-959 (и, фактически, опущенных на рисунке 3, стр. 43). Следовательно, клиент FTP, интерпретирующий отклик PASV, должен сканировать весь отклик для обнаружения первой цифры адреса хоста и номера порта.
Отметим, что h1,h2,h3,h4 задает IP-адрес серверного хоста, который передал отклик, а p1,p2 указывает нестандартный порт выделенный для передачи данных командой PASV.
4.1.2.7 Команды LIST и NLST: RFC-959, 4.1.3
Данные, возвращаемые командой NLST, должны содержать только простой список корректных (legal) параметров, которые сервер может непосредственно использовать как аргументы в последующих командах передачи данных для отдельных файлов.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Для данных, возвращаемых командами LIST и NLST, рекомендуется использовать подразумеваемый тип TYPE AN, если не задан в качестве текущего тип EBCDIC; если в качестве подразумеваемого задан тип TYPE EN, рекомендуется использовать этот тип. Обсуждение
Многие клиенты FTP поддерживают макрокоманды, для загрузки (get) или выгрузки (put) файлов, соответствующих шаблону, с использованием команды NLST для получения списка имен. Расширение multiple-put является локальным для клиента, а multiple-get требует взаимодействия с сервером.
Для команд LIST и NLST разработан подразумеваемый тип, обеспечивающий совместимость с существующими клиентами FTP и поддерживающий групповые команды get.
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).
Обсуждение
Таким образом, сервер или клиент FTP должен продолжать чтение символов из управляющего соединения, пока не будет получена полная последовательность Telnet EOL, прежде чем начинать обработку команд (или откликов). Одна операция READ может получать из управляющего соединения несколько команд FTP.
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 -
сервис недоступен, управляющее соединение закрывается), но следует детектировать закрытие сервером управляющего
соединения.
Обсуждение
Реализации серверов с некорректными откликами часто приводят к зависанию клиентских программ FTP. Отметим, что RFC-959 устраняет неоднозначности в правилах передачи откликов, присутствовавшие в ранних спецификациях FTP. Важно выбирать коды откликов FTP, которые позволяют отличать временные сбои от постоянных проблем, что позволяет успешно использовать клиентские демоны FTP. Работа таких программ зависит от кода отклика, на основе которого принимается решение о продолжении попыток. Использование кодов 5xx (постоянная проблема) для временных сбоев может приводить к некорректной работе демонов.
Говор о том, что отклики должны в точности соответствовать RFC-959, зачастую трактуют это соответствие как дословную передачу. Однако, разработчикам серверов FTP следует выбирать (по возможности) тексты откликов, специфические для используемой ОС.
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).
Обсуждение
Хотя в RFC сказано: "Server-and User-processes should follow the conventions for the Telnet protocol...[on the control connection]" (сервер и клиент должны следовать соглашениям для протокола Telnet...[для управляющего соединения]), это не имеет отношения к согласованию опций Telnet.
4.1.2.13 Минимальна реализация: RFC-959, 5.1
Перечисленные ниже команды и опции должны поддерживаться всеми клиентами и серверами FTP, за исключением случаев, когда файловая система или ОС не позволяют реализовать ту или иную возможность. Типы: ASCII Non-print, IMAGE, LOCAL 8
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Режимы: Stream Структуры: File, Record9 Команды:
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.
Обсуждение
Поощряется реализация более широкого набора команд и опций. Например, в протоколе заложены важные средства обеспечения устойчивости (например, Restart, ABOR, блоковый режим), которые будут интересны некоторым пользователям Internet, но реализованы далеко не всегда.
Хост: который не использует структуры записей в своей файловой системе, может по-прежнему воспринимать файлы с STRU R, записывая байтовый поток литерально.
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 рекомендуется распознавать обе формы этих команд, просто просматривая дополнительные записи в таблице команд.
Реализация
Клиент FTP может обращаться к серверу, поддерживающему только X-команды, с помощью переключателя режима или за счет автоматического использования следующей процедуры - если стандартна (RFC-959) любой из перечисленных выше команд была отвергнута с кодом 500 ил 502, следует попытаться использовать расширенную команду; все остальные отклики будут передаваться пользователю.
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.
Обсуждение
Без использования тайм-аута сервер FTP может неограниченно долго оставаться в состоянии ожидания при крахе клиента без разрыва управляющего соединения.
4.1.3.3 Одновременное управление и передача данных
Обсуждение
При разработке протокола FTP ставилась задача обеспечения возможности пользователю передать в любой момент в процессе передачи данных команду STAT, на которую сервер будет незамедлительно возвращать информацию о состоянии (например, размер переданной части файла). Подобно этому команда ABOR должна обеспечивать возможность прерывания передачи данных в любой момент.
К несчастью, некоторые ОС (в небольших машинах) затрудняют программирование одновременных операций. Отдельные разработчики идут по пути наименьшего сопротивления, не поддерживая в своих реализациях возможности управления в процессе передачи данных. Но даже в минимальной реализации серверы должны быть готовы к восприятию и отсрочке команд STAT и ABOR, получаемых во время передачи данных.
4.1.3.4 Механизм FTP Restart
В описании отклика 110 на стр. 40-41 RFC-959 допущена ошибка, исправленная здесь. Сообщение restart reply, передаваемое через управляющее соединение от принимающего FTP клиенту FTP, имеет формат:
110 MARK ssss = rrrr
где:
• ssss - текстовая строка, которая появляется в Restart Marker в потоке данных и кодирует позицию в файловой системе
отправителя;
• rrrr - кодирует соответствующую позицию в файловой системе получателя.
Кодирование зависит от используемой ОС и сетевой реализации и всегда генерируется и интерпретируется одной и той же системой (отправителем или получателем).
Когда FTP, реализующий рестарт, получает Restart Marker в потоке данных, рекомендуется форсировать запись данных до этой точки на стабильную среду для кодирования соответствующей позиции rrrr. Для FTP, передающего Restart Markers, не допускается
|
||
|
|
||
|
9 Структуры Record требуются для тех хостов, чьи файловые системы поддерживают структуры записей.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
предположение о возврате откликов 110 синхронно с данными (т. е., следует дождаться отклика 110 перед продолжением передачи
данных).
Для сообщений об ошибках при рестарте передачи определяются два новых кода:
554 Requested action not taken: invalid REST parameter.
Отклик 554 может быть результатом сервисной команды FTP, которой следует за командой REST. Отклик показывает, что существующий файл на сервере FTP невозможно репозиционировать в соответствии с командой REST.
555 Requested action not taken: type or stru mismatch.
Отклик 555 может быть результатом команды APPE или любой сервисной команды FTP, за которой следует команда REST. Этот код говорит о рассогласовании между текущими параметрами передачи (type и stru) и атрибутами существующего файла.
Обсуждение
Отметим, что механизм FTP Restart требует использования режима Block или Compressed для передачи данных, чтобы обеспечивалась возможность включения маркеров Restart Marker в поток данных. Частота передачи маркеров может быть достаточно низкой.
Restart Marker отмечает место в потоке данных, но получатель может выполнять некоторые преобразования данных при их сохранении в стабильной среде. В общем случае кодирование на приемной стороне должно включать любую информацию о состоянии, которая может потребоваться для возобновления передачи с любой точки потока данных FTP. Например, при передачах TYPE A некоторые принимающие хосты преобразуют последовательности CR LF в один символ LF при записи файла на диск. Если Restart Marker попадает между CR и LF, принимающая сторона должна указать в rrrr, что передача должна возобновляться в состоянии "CR has been seen and discarded" (получен и отброшен символ возврата каретки). Отметим, что Restart Marker требуется обозначать как строку печатных символов ASCII, независимо от типа данных. RFC-959 говорит, что информация о возобновлении (restart information) будет возвращаться пользователю. Это высказывание не следует понимать буквально. В общем случае клиенту FTP следует сохранять информацию о возобновлении (ssss,rrrr) на стабильной среде (например, дописывать ее в файл управления возобновлением передачи). Пустое поле управления рестартом следует создавать при начале передачи и автоматически удалять после ее успешного завершения. Предполагается, что им такого файла будет связано с именем передаваемого файла и удаленного хоста (по типу имен для резервных копий редактируемых файлов в текстовых редакторах). Возможны три варианта рестарта FTP.
(1)Передача от пользователя к серверу
Клиент FTP помещает маркеры Restart <ssss> в подходящие места потока данных. Когда сервер FTP получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего возвращает отклик "110 MARK ssss = rrrr" через управляющее соединение. Клиент FTP дописывает (append) пару (ssss,rrrr) в свой файл управления возобновлением передачи.
Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла, меняет позицию в своей файловой системе и состояние, используя значение ssss, после чего передает серверу команду "REST rrrr".
(2)Передача от сервера к пользователю
Сервер FTP помещает маркеры Restart <ssss> у подходящие места потока данных. Когда клиент FTP получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего дописывает пару (rrrr,ssss) в свой файл управления передачей.
Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла, меняет позицию в своей файловой системе и состояние, используя значение ssss, после чего передает серверу команду "REST ssss".
(3)Передача от сервера к серверу ("Third-Party")
(4)Передающий сервер помещает маркеры Restart <ssss> у подходящие места потока данных. Когда принимающий сервер получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего возвращает отклик "110 MARK ssss = rrrr" через управляющее соединение. Клиент FTP дописывает (append) пару (ssss,rrrr) в свой файл управления возобновлением передачи.
Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла и отправляет сообщение "REST ssss" передающему серверу FTP и "REST rrrr" - принимающему серверу FTP.
4.1.4 Пользовательский интерфейс FTP
В этом разделе рассматривается пользовательский интерфейс FTP.
4.1.4.1 Спецификация Pathname
Поскольку протокол FTP предназначен для гетерогенных систем, реализация клиента должна поддерживать имена удаленных файлов как произвольные символьные строки, форма и содержание которые не ограничены соглашениями локальной ОС.
Обсуждение
В частности, имена удаленных файлов могут иметь произвольную длину и содержать любые печатаемые символы ASCII, включая пробелы (0x20). RFC-959 позволяет включать в имена все 7-битовые символы ASCII, за исключением CR и LF.
4.1.4.2 Команда QUOTE
Клиент FTP должен поддерживать команду QUOTE, которая будет передавать серверу произвольные символьные строки и выводить на консоль полученные на них отклики.
Чтобы команда QUOTE была полезна, клиентам FTP рекомендуется передавать серверу команды управления как ввод от пользователя, а не сохранять их для передачи серверу после того, как начнется передача данных.
Обсуждение
Команда QUOTE обеспечивает пользователям возможность доступа к серверам, которые требуют ввода специфических команд (например, SITE или ALLO), и позволяет реализовать возможности, нереализованные в стандартных клиентах FTP. В качестве примера использования QUOTE может служить команда "TYPE A T" для передачи файла на печать хостам, которые требуют различия типов, хотя клиент FTP не распознает эти типы.
4.1.4.3 Передача откликов пользователю
Для FTP-клиентов рекомендуется выводить для пользователя полный текст всех полученных сообщений об ошибках. Рекомендуется также поддерживать режим verbose, в котором выводятся полностью все переданные команды и полный текст откликов с кодом результата. Такая возможность позволяет упростить поиск проблем.
|
||
|
|
||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1.4.4 Поддержка синхронизации
Клиентам FTP следует быть устойчивыми к потере сообщений и неожиданным откликам, чтобы поддерживать синхронизацию команд с сервером.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.1.5 Требования к FTP
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10 Число m задает размер слова памяти в битах.
11 Для хостов с файловой системой на основе записей; в остальных случаях необязательно.
12 Для показанных раньше значений.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Функция Параграф Требования
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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).
Обсуждение
Ошибка связана с правилом, по которому люба сторона, получив старый дубликат, может заново передать текущую дейтаграмму. Если пакет задержан в сети, но успешно доставлен после того, как истекло время ожидания и другая сторона повторила передачу, может быть сгенерирован дубликат отклика. Если в ответ на такой дубликат передача будет повторена еще раз, передача всех остальных дейтаграмм будет дублироваться (если не будет утери дейтаграммы, которая прервет повтор). В дополнение к этому, поскольку задержка зачастую связана с насыщением сети, передача дубликатов обычно усиливает насыщение, что ведет к новым задержкам и т. д. Для понимания проблемы может быть полезна приведенная ниже иллюстрация.
TFTP A TFTP B
(1) Прием ACK X-1 Передача DATA X
(2) Прием DATA X
Передача ACK X
(ACK X задерживается в сети и возникает тайм-аут):
(3) Повтор передачи DATA X
(4) Прием DATA X (повт.)
Передача ACK X (повт.)
(5) Прием (задерж.) ACK X Передача DATA X+1
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием ACK X (повт.) Передача DATA X+1 (повт.)
|
Прием DATA X+1 Передача ACK X+1
|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием DATA X+1 (повт.) Передача ACK X+1 (повт.)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием ACK X+1 Передача DATA X+2
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием DATA X+2 Передача ACK X+3
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием ACK X+1 (повт.) Передача DATA X+2 (повт.)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
Прием DATA X+2 (повт.)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
(12)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Передача ACK X+3 (повт.) Отметим, что после доставки задержанного подтверждения ACK протокол начинает дублировать все последующие пакеты (пп. 5-8 и 9-12). Проблема вызывается не тайм-аутом на любой из сторон, а повторной передачей обеими сторонами при получении дубликатов.
Для решения проблемы нужно разорвать возникшую петлю, как показано выше. Это аналогично поведению TCP. Можно удалить таймер повторной передачи на приемной стороне, поскольку повторна передача подтверждения ACK не будет вызывать каких-либо действий; это упрощение TFTP особенно полезно при использовании протокола для стартовой загрузки. Сохранение таймера возможно и может оказаться полезным, если повторно переданное подтверждение ACK заменяет потерянное в сети. Для отправителя таймер повторной передачи остается необходимым.
4.2.3.2 Алгоритм определения тайм-аута
Реализация TFTP должна использовать адаптивный тайм-аут. Реализация
Алгоритмы повторной передачи TCP обеспечивают полезный прототип. Необходимо реализовать по крайней мере экспоненциальное изменение тайм-аута повторной передачи.
4.2.3.3 Расширения
К протоколу TFTP было добавлено множество нестандартных расширений, включающих дополнительные режимы передачи и обеспечение безопасности (пароли). Ни одно из этих расширений не было стандартизовано.
4.2.3.4 Контроль доступа
При реализации сервера TFTP рекомендуется включать некоторые настраиваемые возможности контроля доступа с помощью имен файлов, допустимых при операциях TFTP.
4.2.3.5 Широковещательные запросы
Запрос TFTP, отправленный по широковещательному адресу, рекомендуется отбрасывать без уведомления. Обсуждение
По причине слабого контроля доступа в TFTP, передача широковещательных запросов TFTP в чужие сети может пробить существенную брешь в безопасности.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
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; в других почтовых средах, использующих эти протоколы, можно ожидать иных правил.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
19
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
|
||
|
|
||
|
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
Обсуждение
Электронная почта передается с помощью серии транзакций запрос-отклик между клиентом (sender-SMTP) и сервером (receiver-SMTP). Эти транзакции проверяют (1) корректность сообщения, состоящего из заголовка и тела письма, а также (2) SMTP-адреса для отправителя и получателя (envelope - конверт).
Программы SMTP аналогичны агентам MTA (Message Transfer Agents) в среде X.400. Есть также другой уровень программ, расположенных ближе к пользователю, которые отвечают за сборку и анализ заголовков в сообщениях RFC-822; эта компонента называется пользовательским агентом (User Agent) в среде X.400 и мы будем применять этот термин в данном документе. Существуют четкие различия между пользовательским агентом и реализацией SMTP, поскольку они работают на разных уровнях протокола. Отметим, однако, что это различие может неточно отражаться структурой типичных реализаций почтовых программ Internet. Очень часто программы, называемые mailer, реализуют функции SMTP и некоторые функции пользовательского агента; остальные функции UA13 включаются в пользовательский интерфейс, который служит для чтения и подготовки почтовых сообщений.
Конверт SMTP создается на стороне отправителя (обычно пользовательским агентом) при передаче сообщения в очередь для программы Sender-SMTP. Адрес для конверта может быть построен по адресу в заголовке сообщения, полученному от пользовательского интерфейса (например, для выполнения запроса bcc:), или найден в локальных конфигурационных параметрах (например, в списке рассылок). В общем случае конверт SMTP не может быть сгенерирован заново на более поздних этапах доставки почты, поэтому он передается отдельно от сообщения с использованием команд MAIL и RCPT протокола SMTP.
В RFC-821 предполагается, что почта доставляется отдельным пользователям на каждом хосте. С развитием доменной системы и началом маршрутизации почты на основе записей MX (mail-exchange - обмен почтой) почтовые программы должны обеспечивать доставку почты пользователям в домене, а не на отдельно взятом хосте. Однако это не меняет характера SMTP, который является протоколом обмена почтой между хостами (host-to-host mail exchange protocol).
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 - невозможно проверить пользователя (например, отсутствует локальна информация), но будет
предпринята попытка доставить почту этому пользователю.
Обсуждение
Пользователи и администраторы SMTP регулярно обращаются к этим командам для поиска проблем с доставкой почты. С ростом использования многоуровневых почтовых списков (зачастую, более 2 уровней), возрастает важность команды EXPN при определении возможных петель в списках доставки). С другой стороны, существует мнение, что команда EXPN представляет угрозу сохранению тайны личности (privacy) и, возможно, безопасности14.
5.2.4 Команды SEND, SOML, SAML: RFC-821, 3.4
SMTP может реализовать команды для передачи сообщений на пользовательский терминал: SEND, SOML, SAML. Обсуждение
Предполагается, что трансляция почты (mail relaying) с помощью записей MX несовместима с использованием команды SEND для непосредственной доставки сообщений на пользовательский терминал. Однако принимающая программа SMTP, которая не способна писать непосредственно на пользовательский терминал, может передавать отклик "251 User Not Local" (нелокальный пользователь) на RCPT с последующей командой SEND для информирования оператора о возможности отложенной доставки.
5.2.5 Команда HELO: RFC-821, 3.5
Отправитель SMTP должен обеспечивать корректность параметра <domain> в команде HELO (полное доменное им хоста) для
клиентского хоста. В результате этого получателю SMTP не нужно будет выполнять преобразования MX для этого имени, чтобы
проверить корректность параметра HELO.
Получатель HELO может проверить, что параметр HELO реально соответствует IP-адресу отправителя. Однако получатель не
имеет права отказываться от восприятия сообщения даже при отрицательном результате проверки отправителя команды HELO.
Обсуждение
Проверка параметра HELO требует просмотра доменного имени (domain name lookup) и может, следовательно, потребовать значительного времени. Ниже предлагается другой способ определения подставных отправителей (bogus mail source) с помощью команды DATA.
|
||
|
|
||
|
13 User Agent - пользовательский агент. Прим. перев.
14 Во многих современных руководствах по безопасности рекомендуется отключить команды VRFY и EXPN. Прим. перев.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Отметим также, что аргумент HELO все равно должен использовать корректный синтаксис <domain>, поскольку это им будет появляться в строке Received: (при некорректном имени возникает ошибка 501).
Реализация
Когда проверка параметра HELO дает отрицательный результат, предлагается вставлять примечание о невозможности проверки отправителя в заголовок сообщения (например, в строку Received:).
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 ТО:, содержащую явный маршрут, с использованием адреса в формате "@...:". Таким образом, функции трансляции почты, определенные в параграфе 3.6 RFC-821, не рекомендуется использовать.
Обсуждение
Задача состоит в полном искоренении source routing and упразднении явного задания маршрутов для доставки почты в среде Internet. Задание маршрута не требуется и во всех случаях следует использовать простую форму адреса получателя -user@domain. Это является результатом принятия решения на уровне архитектуры почтовой среды об использовании универсального именования вместо явного задания маршрутов доставки почты. Таким образом, SMTP обеспечивает сквозную доставку (end-to-end connectivity), а DNS - уникальные в масштабе планеты и не зависящие от местоположения имена. Для обработки случаев, когда может потребоваться задание маршрута используются записи MX. Получатель SMTP должен воспринимать синтаксис явного задания маршрута в конверте, но он может реализовать функции трансляции (relay) в соответствии с параграфом 3.6 RFC-821. Если функция трансляции не реализована, получателю рекомендуется попробовать доставить сообщение напрямую хосту, указанному в адресе справа от знака @. Обсуждение
Предположим для примера, что хост, не поддерживающий трансляции, получает сообщение с командой SMTP "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>"(ALPHA, BETA и GAMMA представляют доменные имена). Вместо отказа с возвратом ошибки 550 (как предлагается на стр. 20 в RFC-821), хосту следует попытаться переслать сообщение напрямую в GAMMA с помощью команды RCPT TO:<joe@GAMMA>”. Поскольку этот хост не поддерживает трансляции, ему не требуется обновлять путь возврата.
Некоторые считают, что задание маршрута может иногда потребоваться при отправке почты вручную при наличии сбоев; однако, реальность и важность такого использования весьма сомнительны. Использование явной трансляции SMTP для решения таких задач не представляется разумным и, фактически, не обеспечивает успеха, поскольку многие хосту не поддерживают явного задания маршрутов. В некоторых случаях для решения таких задач используется "%-hack" (см. параграф 5.2.16).
5.2.7 Команда RCPT: RFC-821, 4.1.1
Хост, поддерживающий SMTP-получатель, должен обеспечивать почтовый ящик Postmaster.
Получатель SMTP может проверять параметры RCPT при доставке; однако, отклики RCPT недопустимо задерживать сверх
разумного времени (см. 5.3.2).
Следовательно, отклик "250 ОК" для RCPT не обязательно говорит о корректности указанного адреса получателя. Информация об
ошибках, обнаруженных после восприятия сообщения, будет передаваться в виде почтовых сообщений в соответствующий адрес
(см. 5.3.3).
Обсуждение
Набор условий, по которому параметр RCPT должен проверяться незамедлительно, был задан при разработке архитектуры. Передача уведомления об ошибке в адресе получателя для отправителя SMTP до отправки всего сообщения имеет достаточно важное значение, поскольку позволяет снизить расход времени и полосы канала, но это преимущество может быть утеряно при длительной проверке RCPT.
Например, получатель можно проверить незамедлительно любую локальную ссылку (зарегистрированный локально почтовый ящик). С другой стороны, ограничение “разумным временем” в общем случае предполагает отложенную проверку для списков рассылки (пока сообщение не будет передано и воспринято), поскольку проверка большого числа адресов потребует продолжительного времени. Реализация программы может использовать или не использовать отложенную проверку адресов, которые не являются локальными и, следовательно, требуют обращения к DNS. Если используется DNS и при запросе обнаруживается некритична ошибка (например, тайм-аут), адрес следует считать корректным.
5.2.8 Команда DATA: RFC-821, 4.1.1
Каждый получатель SMTP (не только тот, который принимает сообщения для трансляции или окончательной доставки - "accepts а message for relaying or for final delivery" [SMTP1]) должен вставлять строку Received: в начале сообщения. В этой строке, которая названа "time stamp line" (строка с временной меткой) в RFC-821 указывается:
• В поле FROM рекомендуется включать (1) им хоста-отправителя, представленное в команде HELO, и (2) доменное им с адресом
IP, определенным из соединения TCP.
• Поле ID может содержать "@" (как предложено в RFC-822), но это необязательно.
• Поле FOR может содержать список <path>, если было введено множество команд RCPT. Для почтовых программ Internet недопустимо изменять строки Received:, добавленные в заголовок раньше. Обсуждение
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Включение имени хоста и IP-адреса отправителя в строку Received: может предоставить достаточно информации для
обнаружения источников недозволенной почты и позволяет избавиться от необходимости явной проверки параметра HELO.
Строки Received: предназначены, прежде всего, для прослеживания (человеком) почтовых маршрутов, прежде всего в целях
поиска проблем (см. также Обсуждение в параграфе 5.3.7). Когда получатель SMTP выполняет окончательную доставку (final delivery) сообщения, он должен передать адрес MAIL FROM из конверта SMTP, связанного с данным сообщением, для использования в тех случаях, когда позднее требуется передать отправителю информацию об ошибках (см. 5.3.3). Это аналогично требованию к шлюзам при передаче почты из Internet в иную почтовую среду (см. 5.3.7).
Обсуждение
Отметим, что окончательный отклик на команду DATA зависит только от успеха при передаче и сохранении сообщения. Проблемы с адресом получателя могут привести (1) к сообщению об ошибке при вызове команды RCPT или (2) передаче последующего сообщения об ошибке в адрес отправителя.
Реализация
Информация MAIL FROM: может передаваться как параметр или строка Return-Path: в начале сообщения.
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).
Обсуждение
Могут возникнуть проблемы с интероперабельностью при использовании кодов отклика, не указанных явно в параграфе 4.3 RFC-821, но корректных в соответствии с теорией откликов, рассмотренной в 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@relayl
знак % показывает, что почта маршрутизируется из relay 1 через relay2 и relay3 для передачи пользователю user в домене
domain. Такую нотацию часто называют "%-hack". Предполагается, что % имеет меньший приоритет, нежели другие операторы
маршрутизации (например, "!"), спрятанные в локальной части адреса. Например, "а!Ь%с" будет интерпретироваться как
"(а!Ь)%с".
Только хосту-получателю (в нашем случае, 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; недопустимо генерирование адресов с некорректным синтаксисом.
• Общей ошибкой является сохранение точки с запятой (;) после идентификатора группы.
• Некоторые системы допускают ошибки при генерации полных имен в создаваемых сообщениях. Справа от знака @ в адресе
заголовка должно размещаться полное доменное им (fully-qualified domain name).
Например, некоторые системы некорректно указывают доменное им в поле From:. В таких случаях возникают проблемы при
попытке использования команды reply на приемной стороне.
Обсуждение
Хотя RFC-822 допускает локальное (внутри домена) использование сокращенных доменных имен, применение RFC-822 для почты Internet не позволяет использовать такие сокращения. Для хостов Internet недопустимо передавать сообщения SMTP, заголовок которых содержит сокращенное доменное им в поле адреса. Такие сокращения допустимы только для заголовков сообщений, которые не будут передаваться через Internet, как сказано в параграфе 5.2.6.
• Многие системы не умеют корректно разбирать заголовки с указанным маршрутом из нескольких частей:
©relayl,@relay2,©relay3:user@domain.
• Некоторые системы ошибочно добавляют точку в конце полного доменного имени в адресах и идентификаторах сообщений. Это
является нарушением синтаксиса RFC-822.
5.2.19 Явное задание маршрута: RFC-822, 6.2.7
Программам хостов Internet не рекомендуется создавать заголовки RFC-822, содержащие адреса с явным маршрутом (explicit
source route), но они должны воспринимать такие заголовки в целях совместимости.
Обсуждение
RFC-822 говорит: "The use of explicit source routing is discouraged" (рекомендуется избегать использования явно заданных маршрутов в адресах). На многих хостах поддержка маршрутов RFC-822 реализована некорректно, поэтому синтаксис не обеспечивает однозначной трактовки на практике. Многие пользователи считают этот синтаксис опасным. Явное задание маршрута в конверте не требуется для доставки (см. 5.2.6). В силу всего сказанного явное задание маршрутов с использованием синтаксиса RFC-822 не применяется в заголовках электронной почты Internet.
Как было сказано в параграфе 5.2.16, необходимо обеспечить возможность встраивания явных маршрутов в локальную часть адреса (например, за счет использования "%-hack"), чтобы позволить шлюзам передавать почту в инородные среды, требующие явного задания маршрута. Внимательный читатель заметит, что для пользовательских агентов не существует способа обнаружить и предотвратить использование таких неявных маршрутов при передаче почты в среде Internet. Мы можем только рекомендовать не применять задание маршрутов для почты Internet - это не нужно и нежелательно.
5.3 Частные вопросы
5.3.1 Стратеги очередей SMTP
Обща структура реализации SMTP на хосте включает пользовательские почтовые ящики, одну или несколько областей для организации очередей транзитных сообщений, а также один или несколько процессов-демонов для приема и передачи почты. Точна структура будет зависеть от потребностей пользователей, а также числа и размера поддерживаемых хостом списков рассылок. Здесь рассмотрены вопросы оптимизации, позволяющие повысить эффективность работы почтовых систем (в частности, систем с большим трафиком). Люба стратеги работы с очередями должна включать:
• время ожидания (тайм-аут) для всех операций (см. 5.3.2).
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
• невозможность передачи сообщений об ошибке в ответ на сообщения об ошибке.
5.3.1.1 Стратеги передачи
Обща модель передающей стороны SMTP включает один или несколько процессов, периодически пытающихся передать
исходящую почту. В типовой системе программы, готовящие почтовые сообщения, используют некий метод запроса немедленных
действий для вновь созданного сообщений, однако, почта не может быть отправлена незамедлительно, поэтому новые сообщения
должны помещаться в очередь, к которой периодически обращается программа рассылки почты. Элемент почтовой очереди будет
включать не только почтовое сообщение, но и связанный с ним конверт.
Отправитель должен задерживать попытки отправить почту по тому или иному адресу после связанной с ним неудачи. В общем
случае рекомендуется использовать интервал повтора не менее 30 минут, однако более изощренные и гибкие стратегии с
определением причин неудачи являются более предпочтительными.
Попытки продолжаются, пока сообщение не будет передано или отправитель не откажется от дальнейших попыток (обычно отказ
происходит через 4-5 дней). Параметры повторов передачи должны быть настраиваемыми.
Отправителю рекомендуется сохранять список хостов, с которыми не удается связаться и соответствующее время ожидания
вместо простых попыток повтора передачи.
Обсуждение
Опыт показывает, что большинство отказов носит временный характер (например, перезагрузка хоста-получателя), поэтому рекомендуется делать две попытки передачи в течение первого часа пребывания сообщения в очереди и потом повторять попытки каждые 2 -3 часа.
Отправитель SMTP может сократить время нахождения сообщений в очереди за счет взаимодействия с принимающей стороной SMTP. В частности, если почта получена с конкретного адреса, очевидно, что доставка почты по этому адресу также возможна в данный момент. Дальнейшая оптимизация доставки может обеспечиваться путем учета множества почтовых адресов, связанных с хостом (см. 5.3.4), с учетом времени доставки и использованием ресурсов.
Отправитель SMTP может иметь большие очереди сообщений для каждого из недоступных хостов и при попытках передать все такие сообщения в каждом цикле повтора будет возникать излишняя загрузка, которая может привести к блокировке почтового демона на продолжительный период. Отметим, что SMTP в общем случае может определить отказ только по истечении времени ожидания (минута или больше); минутный тайм-аут для соединения будет приводить к очень большим задержкам при повторении попыток для десятков и даже сотен сообщений из очереди.
Когда одно сообщение доставляется нескольким пользователям на одном хосте, рекомендуется передавать только одну копию. Т.
е., отправителю SMTP рекомендуется использовать последовательность команд: RCPT, RCPT,... RCPT, DATA вместо
последовательности: RCPT, DATA, RCPT, DATA,... RCPT, DATA. Реализация этого эффективного варианта настоятельно
рекомендуется.
Подобно этому, отправитель SMTP может поддерживать множество одновременных исходящих почтовых транзакций для
обеспечения быстрой доставки. Однако рекомендуется задавать некоторый предел для предотвращения излишнего расхода
ресурсов на передачу почты.
Использование различных адресов на многодомных хостах рассматривается ниже.
5.3.1.2 Стратеги приема
На приемной стороне SMTP рекомендуется сохранять постоянное прослушивание порта SMTP. Это требуется для поддержки
множества входящих TCP-соединений для SMTP. Можно ввести некоторые ограничения.
Реализация
Когда принимающая сторона SMTP получает почту от того или иного хоста, она может уведомить отправителя SMTP о возможности повтора для любой почты на данный хост, хранящейся в очереди.
5.3.2 Тайм-ауты SMTP
Существует два подхода при выборе времени ожидания для отправителей SMTP: (а) раздельно ограничивать время для каждой команды SMTP или (Ь) ограничивать время диалога SMTP в целом для каждого почтового сообщения. Рекомендуется использовать для отправителей SMTP вариант (а) - покомандные тайм-ауты. Рекомендуется также обеспечивать простой способ изменения времени ожидания, предпочтительно без перекомпиляции кода SMTP.
Обсуждение
Время ожидания является важным параметром реализации SMTP. Если тайм-аут слишком велик (или не задан вообще) отказы
в соединения Internet или ошибки в программах на приемной стороне SMTP могут привести процессы SMTP в состояние
бесконечного ожидания. Если время ожидания слишком мало, это приведет к излишнему расходу ресурсов на попытки
повторной передачи сообщений.
При использовании варианта (Ь) тайм-аут должен быть достаточно большим (например, час), чтобы можно было работать с
очень большими списками рассылок. Может также потребоваться увеличение тайм-аута пропорционально размеру сообщения
при работе с сообщениями большого размера. Использование большого тайм-аута с фиксированным значением может привести
к двум проблемам - состояние отказа может сохраняться очень долго, а очень большие сообщения будут приводить к
фиктивным тайм-аутам просто потому, что не хватило времени на передачу (это ведет к очень серьезным издержкам!).
При использовании рекомендуемого варианта (а) таймер устанавливается для каждой команды SMTP и каждого буфера
передачи данных. Последнее означает, что общее время ожидания растет пропорционально размеру сообщения.
На основе опыта эксплуатации сильно загруженных почтовых хостов выработаны приведенные ниже правила, которые
рекомендуется использовать при выборе времени ожидания:
• Изначальное сообщение 220: 5 минут
Процесс-отправитель SMTP должен различать отказы соединений TCP от задержки при получении изначального отклика 220. Многие получатели SMTP будут воспринимать соединения TCP, но задерживать отклик 220 до тех пор, пока в системе не появится возможность обработки новой почты.
• Команда MAIL: 5 минут
• Команда RCPT: 5 минут
Более продолжительный тайм-аут требуется при обработке списков рассылки и псевдонимов, если ее невозможно отложить, пока не будет воспринятое сообщение.
• Инициирование команды DATA: 2 минуты
Это время ожидания отклика 354 Start Input на команду DATA.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
• Блок данных: 3 минуты
Это время, в течение которого вызов TCP SEND передает кусок данных.
• Прерывание команды DATA: 10 минут
Время ожидания отклика 250 ОК. Когда получатель переходит на этап завершения приема данных, он обычно выполняет операции по доставке сообщения в пользовательский почтовый ящик. Фиктивные тайм-ауты на этом этапе ведут к значительным издержкам, поскольку сообщение уже было передано целиком. Для получателей SMTP рекомендуется устанавливать тайм-аут не менее 5 минут для ожидания следующей команды отправителя.
5.3.3 Надежное получение почты
Когда получатель SMTP принимает часть почты (передавая сообщение 250 ОК в ответ на команду DATA), он берет на себя ответственность за доставку или трансляцию этого сообщения. Эта ответственность должна восприниматься серьезно, т. е., недопустимо терять сообщения по незначительным причинам (например, в результате последующего краха хоста или предсказуемой нехватки ресурсов).
Если после восприятия сообщения возникают проблемы с его доставкой, получатель SMTP должен сформулировать и передать уведомление об этом. Такие уведомления должны передаваться с использованием пустого ("о") пути возврата в конверте (см. параграф 3.6 в RFC-821). В качестве получателя такого уведомления рекомендуется указывать адрес из пути возврата в конверте или строки Return-Path:. Если этот адрес пуст ("<>"), для получателя SMTP недопустима передача уведомления о возникших проблемах. Если адрес содержит заданный явно маршрут, рекомендуется разобрать его до конечной точки. Обсуждение
Предположим, что уведомление об ошибке должно быть передано для сообщения, принятого с "MAIL
FROM:<@a,@b:user@d>". Уведомление в этом случае адресуется на: "RCPT TO:<user@d>".
Некоторые отказы при доставке после восприятия сообщения являются неизбежными. Например, причиной такого отказа
может послужить невозможность проверки всех адресов доставки в команде RCPT в результате некритичной ошибки в домене
или при отправке сообщения в адрес списка рассылок (см. обсуждение RCPT). Во избежание дублирования сообщений в результате тайм-аутов получатель SMTP должен искать способ минимизации времени, требуемого для отклика на финальную точку, завершающую передачу сообщения. Обсуждение этой проблемы приведено в RFC-1047 [SMTP:4].
5.3.4 Надежна доставка почты
Для передачи сообщения отправитель SMTP определяет ГР-аддрес хоста-получателя по адресу получателя в конверте (преобразуется в адрес IP часть адреса получателя справа от знака @). При таком отображении или преобразовании могут возникать некритичные ошибки (soft error), в результате которых отправитель SMTP будет перестраивать почтовую очередь для последующей доставки сообщений, связанных с неудачной попыткой (см. 5.3.1.1).
При успешном преобразовании может быть возвращен список адресов доставки вместо единственного адреса (причиной этого может служить (а) наличие множества записей MX, (b) многодомный характер хоста или то и другое вместе). Для обеспечения надежной доставки почты отправитель SMTP должен обеспечивать возможность попыток (и повторов) передачи по каждому из полученных адресов в соответствии с их порядком в списке, пока какая-либо из попыток не завершится успешно. Однако могут существовать конфигурационные ограничения на число альтернативных адресов, по которым могут осуществляться попытки доставки. В таких случаях хостам рекомендуется предпринять попытки хотя бы для двух адресов. Для ранжирования адресов в списке можно использовать следующую информацию:
(1)Множество записей MX - значение записи можно использовать в качестве ключа сортировки. При существовании множества получателей с одинаковым значением и отсутствии других критериев (например, предпочтительный адрес) установки очередности отправителю SMTP рекомендуется использовать случайный выбор для распределения нагрузки между почтовыми серверами, обслуживающими указанную организацию (отметим, что в работе [DNS:3] предложен усовершенствованный вариант этой процедуры). (2)Многодомный хост - хост-получатель (возможно определенный по записи MX с высшим приоритетом) может быть многодомным и в этом случае программа преобразования доменных имен будет возвращать список адресов IP. Упорядочивание адресов в списке (по уровню приоритета) является прерогативой программы-резольвера (см. параграф 6.1.3.4) и отправитель SMTP должен пытаться применять адреса в предложенном порядке. Обсуждение
Хотя возможность работы с множеством альтернативных является требованием, в некоторых обстоятельствах использование альтернативных адресов может быть ограничено или запрещено. Вопрос о возможности использования различных адресов многодомного хоста остается спорным. Главным аргументом в пользу работы с множеством адресов является повышение вероятности быстрой доставки и бесспорное повышение вероятности какой-либо доставки. Аргументом против такого использования является повышение расхода ресурсов15.
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:) должен сохраняться неизменным. Обсуждение
Важным вопросом для почтовой системы является доставка одного сообщения по множеству адресов, выполняемая путем преобразования или расширения (expanding) псевдо-адреса (mailbox) в список адресов реальных получателей. Когда сообщение
|
||
|
|
||
|
15 Отметим, что на затраты ресурсов при передаче значительное влияние оказывает выбор стратегии передачи (см. 5.3.1).
|
||
|
|
||
|
|
||||
|
|
||||
|
|
||||
|
передается по такому псевдо-адресу (иногда такой почтовый ящик называют exploder - детонатор), копии письма отправляются
по каждому из адресов, полученных путем преобразования. Такие псевдо-адреса делятся на псевдонимы (alias) и списки (list):
(a)Alias - псевдоним
Для расширения псевдонима принимающая программа просто заменяет псевдо-адрес в конверте на каждый включенный в псевдоним реальный адрес; остальная часть конверта и тело сообщения при этом не изменяются. Сообщение после этого доставляется или пересылается по каждому из адресов.
(b)List - список
Список адресов использует перераспределение (redistribution), а не рассылку (forwarding). Для расширения списка принимающая программа заменяет псевдо-адрес в конверте реальными адресами из списка. Адрес возврата в конверте изменяется, поэтому все сообщения об ошибках доставляются администратору списка, а не отправителю сообщения, который зачастую не имеет возможности контроля списка адресов.
5.3.7 Почтовый шлюз
Передача почты между различными почтовыми средами, использующими разные форматы и протоколы, является сложной задачей, для которой еще нет должного уровня стандартизации (см. примеры в [SMTP:5a], [SMTP:5b]). Однако здесь приведены некоторые общие требования для почтовых шлюзов, обеспечивающих пересылку между Internet и другими почтовыми средами. (A)Пол заголовков могут переписываться при необходимости в процессе обработки сообщений почтовыми шлюзами. Обсуждение
Основным вопросом является интерпретация локальной части адреса, рассмотренная в параграфе 5.2.16. Инородные почтовые системы при передаче сообщений в Internet обычно используют подмножество заголовков RFC-822, но некоторые из почтовых систем не имеют эквивалента конвертов SMTP. Следовательно, когда сообщение покидает среду Internet может потребоваться включение информации из конверта SMTP в заголовок сообщения. Возможным решением является создание новых полей заголовка для передачи информации из конверта (например, X-SMTP-MAIL: и X-SMTP-RCPT:); однако такое решение может потребовать изменений в почтовых программах чужой среды. (B)При пересылке сообщений в среду Internet или из нее, шлюз должен подготовить свою строку Received:, но недопустимо менять содержимое других строк Received: в полученном заголовке.
Обсуждение
Это требование является частью общих правил для строки Received:, рассмотренных в параграфе 5.2.8 и приведено здесь
только для напоминания.
Пол Received: сообщений из другой среды могут не соответствовать в точности RFC-822. Однако, наиболее важным
применением строк Received: является обнаружение почтовых отказов и такая отладка может быть испорчена шлюзами,
которые пытаются править строки Received:.
Для шлюзов настоятельно рекомендуется указывать среду и протокол в предложениях "via" строки Received:, доставляемой
шлюзом. (C)Со стороны Internet шлюзу рекомендуется принимать все допустимые форматы адресов в командах SMTP и заголовках RFC-822, а так же все допустимые сообщения RFC-822. Хотя шлюз должен воспринимать явно указанные маршруты RFC-822 (формат "@...:") в заголовке RFC-822 или в конверте, шлюз не обязан действовать на маршруте от отправителя (см. 5.2.6 и 5.2.19.
Обсуждение
Часто возникает искушение ограничить диапазон адресов, воспринимаемых почтовым шлюзом для упрощения трансляции адресов в форматы другой среды. Такая практика основывается на предположении, что пользователи почты имеют контроль над всеми адресами, по которым их почтовые программы шлют сообщения почтовому шлюзу. На практике, однако, пользователи имеют ограниченный контроль над адресами, которые они в конечном итоге используют, поскольку почтовые программы могут свободно менять адреса в любой допустимый формат RFC-822. (D)Шлюз должен гарантировать, что все поля заголовков сообщений, пересылаемых в Internet, соответствуют почтовым
требованиям Internet. На практике все адреса в полях From:, To:, Cc: и т. п. должны быть преобразованы (при необходимости) в
соответствии с требованиями синтаксиса RFC-822. (E)Алгоритму трансляции, используемый для преобразования почты Internet в другие почтовые системы, рекомендуется пытаться
обеспечить гарантии доставки сообщений об ошибках из чужой среды по пути возврата из конверта SMTP, а не отправителю,
указанному в поле From: сообщения RFC-822.
Обсуждение
Списки рассылок Internet обычно помещают адрес владельца списка (list maintainer) в конверт, но указывают реального отправителя в поле From:. Этот подход представляется разумным - ответ на письмо приходит его реальному отправителю, а сообщения об ошибках - администратору списка, который может исправить связанные со списком ошибки. (F)Подобно сказанному, при пересылке почты из чужой среды в Internet шлюзу рекомендуется установить в конверте путь возврата в соответствии с требованиями возврата сообщений об ошибках для инородной среды.
5.3.8 Максимальный размер сообщения
Почтовая программа должна обеспечивать возможность передачи и приема сообщений, размером не менее 64 кбайт (включая заголовок); желательно обеспечивать возможность работы с более крупными сообщениями.
Обсуждение
Хотя SMTP не задает максимальный размер сообщения, во многих системах этот размер ограничен.
Фактически в Internet обеспечивается гарантия передачи сообщений размером 64 кбайт. Однако электронная почта используется для решения различных задач и может потребоваться передача больших сообщений. Например, электронную почту зачастую используют взамен FTP для передачи ASCII-файлов, которые могут содержать целый документ. В результате сообщения размером 1 Мбайт и более не являются чем-то, из ряда вон выходящим.
|
||||
|
|
||||
|
26
|
||||
|
|
||||
| |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 5.4
Требования к SMTP
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||