text: SMTP ( — простой протокол передачи почты) — это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321 (2008) включает масштабируемое расширение — ESMTP (). В настоящее время под «протоколом SMTP», как правило, подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием порта TCP 25. В то время как электронные почтовые серверы и другие агенты пересылки сообщений используют SMTP для отправки и получения почтовых сообщений, работающие на пользовательском уровне клиентские почтовые приложения обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо POP ( — протокол почтового отделения), либо IMAP (), либо патентованные системы (такие как Microsoft Exchange и Lotus Notes/Domino) для доступа к учётной записи своего почтового ящика на сервере. История В 1960-х годах использовались различные виды электронной связи. Люди связывались друг с другом с помощью систем, разработанных для определённых мейнфреймов. Когда всё больше компьютеров становились связанными, особенно в сети Правительства США, ARPANET, были разработаны стандарты для того, чтобы пользователи на различных системах могли писать электронные сообщения друг другу. Эти стандарты, разработанные в 1970-х годах, стали основой для SMTP. Корни SMTP можно проследить в двух описанных в 1971 г. реализациях — Mail Box Protocol и SNDMSG, который был «изобретён» Рэем Томлинсоном из BBN Technologies для TOPS-20/TENEX-компьютеров, посылающих сообщения по ARPANET (в то время к ней были подсоединены менее 50 хостов). Дальнейшие реализации включают в себя FTP Mail и Mail Protocol, разработанные в 1973 г. Разработка продолжалась на протяжении 1970-х, пока ARPANET не преобразовалась в современный Интернет около 1980 г. В том же году Джон Постел предложил Mail Transport Protocol (протокол передачи почты), благодаря которому FTP перестал быть основой для передачи почты. SMTP опубликован в RFC 821 (также написанном Постелом) в августе 1982 г. Стандарт SMTP был разработан примерно в то же время, что и Usenet, сеть передачи данных, имеющая некоторые сходства с SMTP. SMTP стал широко использоваться в ранние 1980-е. В то время он был дополнением для работающей под Unix почтовой программы Unix to Unix CoPy (UUCP), которая больше подходила для обработки передачи электронных сообщений между периодически связанными устройствами. С другой стороны, SMTP прекрасно работает, когда как отправляющее, так и принимающее устройства связаны в сети постоянно. Оба устройства используют механизм хранения и пересылки и являются примером push-технологии (технологии «проталкивания»). Хотя новостные группы Usenet все ещё распространяются между серверами с помощью UUCP, почта UUCP фактически исчезла вместе с маршрутом «bang path» (последовательность хост-машин в сети, по которой сообщение должно дойти до адресата), которые использовались как заголовки маршрутизации. В статье о перезаписи отправителя содержится техническая справочная информация об истории раннего SMTP и маршрутизации от источника до RFC 1123. Sendmail был одним из первых (если не первым) агентом пересылки сообщений, в котором был реализован SMTP. В число других популярных серверных программ, поддерживающих SMTP, входят Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, Sun Java System Messaging Server. Предоставление сообщений (RFC 2476) и SMTP-AUTH (RFC 2554) были введены в 1998 и 1999 гг. и описывали новые тенденции в передаче электронных сообщений. Изначально SMTP-серверы были обычно внутренними для организации, получая сообщения от организаций извне и ретранслируя сообщения организации во внешнюю среду. Но с течением времени SMTP-серверы (агенты пересылки сообщений) на деле расширяли свои функции и в конце концов стали агентами предоставления сообщений для пользовательских почтовых приложений, некоторые из которых теперь ретранслировали почту извне организации (например, руководитель компании, будучи в поездке, хочет отправить электронное сообщение с помощью корпоративного SMTP-сервера). Данный вопрос, являясь следствием быстрого развития и популярности Всемирной паутины, означает, что SMTP должен был включать в себя особые правила и методы для ретрансляции сообщений и авторизации пользователей для предотвращения таких злоупотреблений, как ретрансляция нежелательной почты (спам). Поскольку этот протокол сначала был с текстовым (ASCII) интерфейсом, то он плохо работал с бинарными файлами и символами многих неанглийских языков. Такие стандарты, как Multipurpose Internet Mail Extensions (MIME), были разработаны для кодирования двоичных файлов для передачи через SMTP. Разработанные после Sendmail агенты пересылки, как правило, также осуществляли опцию чистых 8 бит, так что альтернативная стратегия «просто посылай восемь» может быть использована для передачи произвольных текстовых данных (в любой восьмибитной ASCII-подобной кодировке символов) через SMTP. Однако все ещё оставалась проблема , вызванная разным отображением наборов символов у производителей, хотя сами почтовые адреса все ещё позволяли использовать исключительно ASCII. Сегодня агенты пересылки, работающие с чистыми 8 битами, как правило, поддерживают расширение 8BITMIME, позволяющее передавать бинарные файлы почти так же легко, как обычный текст. Недавно было создано расширение SMTPUTF8 для поддержки текста в кодировке UTF-8, благодаря чему стало возможным включать международное содержимое и адреса с использованием таких алфавитов, как кириллица или китайский. Многие выдающиеся люди внесли свой вклад в спецификацию основного SMTP, среди них Джон Постел, Эрик Оллман, Дэйв Крокер, Нед Фрид, Рэндалл Джелленс, Джон Кленсин и Кейт Мур. Модель обработки почты Электронная почта представлена почтовым клиентом (MUA, mail user agent — пользовательский почтовый агент) для почтового сервера (MSA, mail submission agent — агент отправки электронной почты) с помощью SMTP по TCP-порту 587. Оттуда MSA доставляет почту своим агентам передачи сообщений (MTA, mail transfer agent). Часто эти два агента являются просто различными образцами одного и того же программного обеспечения, запущенного с разными параметрами на одном устройстве. Локальная обработка может быть проведена как на отдельной машине, так и разделена между различными устройствами; в первом случае вовлечённые процессы имеют общий доступ к файлам, во втором случае SMTP используется для пересылки сообщения внутренне, причём каждый хост настроен на использование следующего устройства в качестве промежуточного хоста. Каждый процесс — сам по себе MTA, то есть — SMTP-сервер. Граничный MTA должен найти целевой хост. Он использует систему доменных имен (DNS) для поиска записей почтового обменника (mail exchanger — MX) домена получателя (часть адреса, находящаяся справа от символа @). Возвращаемая запись почтового MX содержит имя целевого хоста. Затем MTA подключается к серверу обмена в качестве SMTP-клиента. Как только цель MX принимает входящее сообщение, она передаёт его агенту доставки почты (mail delivery agent — MDA) для локальной доставки сообщения. MDA предусматривает возможность сохранять сообщения в соответствующем формате почтового ящика. Приём почты, опять же, может быть проведён как несколькими, так и одним компьютером — изображение показывает два ближайших ящика для каждого случая. MDA может доставлять сообщения прямо на хранение или передавать их по сети с помощью SMTP или любых других средств, в том числе протокола локальной пересылки почты (Local Mail Transfer Protocol — LMTP) — производного от SMTP, предназначенного для этой цели. После доставки на локальный почтовый сервер сообщение хранится для пакетного поиска по аутентифицированным почтовым клиентам (MUA). Сообщение извлекается приложениями конечного пользователя (почтовыми клиентами) с использованием протокола IMAP (Internet Message Access Protocol), который облегчает доступ к сообщениям и управляет хранящейся почтой, или с помощью протокола POP (Post Office Protocol), который обычно использует традиционный mbox-формат файлов, или фирменными системами вроде Microsoft Exchange/Outlook или Lotus Notes/Domino. Клиенты сетевой почты могут использовать любой метод, но протокол поиска часто не соответствует официальным стандартам. SMTP определяет передачу сообщения, а не его содержание. Таким образом, он задаёт оболочку сообщения и её параметры (такие, как отправитель оболочки), но не заголовок либо тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (оболочку), в то время как STD 11 и RFC 5322 — сообщение (заголовок и тело), официально называемый форматом почтового сообщения (Internet Message Format). Обзор протокола SMTP — требующий соединения текстовый протокол, по которому отправитель сообщения связывается с получателем посредством выдачи командных строк и получения необходимых данных через надёжный канал, в роли которого обычно выступает TCP-соединение (Transmission Control Protocol — протокол управления передачей). SMTP-сессия состоит из команд, посылаемых SMTP-клиентом, и соответствующих ответов SMTP-сервера. Когда сессия открыта, сервер и клиент обмениваются её параметрами. Сессия может включать ноль и более SMTP-операций (транзакций). SMTP-операция состоит из трёх последовательностей команда/ответ (см. пример ниже). Описание последовательностей: MAIL FROM — устанавливает обратный адрес (то есть Return-Path, 5321.From, mfrom). Это адрес для возвращённых писем. RCPT TO — устанавливает получателя данного сообщения. Эта команда может быть дана несколько раз, по одной на каждого получателя. Эти адреса также являются частью оболочки. DATA — для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделённых пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо. Помимо промежуточных ответов для DATA-команды, каждый ответ сервера может быть положительным (код ответа 2хх) или отрицательным. Последний, в свою очередь, может быть постоянным (код 5хх) либо временным (код 4хх). Отказ SMTP-сервера в передаче сообщения — постоянная ошибка; в этом случае клиент должен отправить возвращённое письмо. После сброса — положительного ответа, сообщение скорее всего будет отвержено. Также сервер может сообщить о том, что ожидаются дополнительные данные от клиента (код 3xx). Изначальным хостом (SMTP-клиентом) может быть как почтовый клиент конечного пользователя (функционально определяемый как почтовый агент — MUA), так и агент пересылки сообщений (MTA) на сервере, то есть сервер действует как клиент в соответствующей сессии для ретрансляции сообщения. Полностью функциональные серверы поддерживают очереди сообщений для повторной передачи сообщения в случае ошибок. MUA знает SMTP-сервер для исходящей почты из своих настроек. SMTP-сервер, действующий как клиент, то есть пересылающий сообщения, определяет, к какому серверу подключиться, просмотром ресурса записей MX (Mail eXchange) DNS для домена каждого получателя. В случае, если запись MX не найдена, совместимые MTA (не все) возвращаются к простой А-записи. Пересылающие серверы также могут быть настроены на использование Smart host. SMTP-сервер, действующий как клиент, устанавливает TCP-соединение с сервером по разработанному для SMTP порту 25. MUA должен использовать порт 587 для подключения к агенту предоставления сообщений (MSA). Основное различие между MTA и MSA заключается в том, что SMTP-аутентификация обязательна только для последнего. SMTP и извлечение сообщений SMTP — всего лишь протокол доставки. Он не может по требованию взять сообщения с удалённого сервера. Для извлечения почты и управления почтовым ящиком разработаны другие протоколы, такие как POP и IMAP. Тем не менее, SMTP предоставляет возможность начать на удалённом сервере обработку очереди сообщений, при которой запрашивающая система может получать все направленные ей сообщения (см. Remote Message Queue Starting ниже). POP и IMAP предпочтительны, когда компьютер пользователя включён не постоянно, или же временно подключён к Интернету. Remote Message Queue Starting Remote Message Queue Starting (запуск удалённой очереди сообщений) — особенность SMTP, позволяющая удалённому хосту начать обработку очереди сообщений на сервере так, что он может получать предназначенные ему сообщения с помощью команды TURN. Однако эта особенность считалась небезопасной и была расширена в RFC 1985 командой ETRN, которая работает надёжнее благодаря основанному на информации DNS методу аутентификации. On-Demand Mail Relay ODMR (On-Demand Mail Relay — ретрансляция почты по требованию) — стандартизированное в RFC 2645 SMTP-расширение, позволяющее проводить ретрансляцию сообщения аутентифицированному пользователю. Интернационализация Многие пользователи, чей набор символов отличается от латиницы, сталкиваются с требованием адреса электронной почты на латинице. Для решения этой проблемы был создан RFC 6531, предоставляющий возможности для интернационализации для SMTP — расширение SMTPUTF8. RFC 6531 предоставляет поддержку многобайтных и не-ASCII символов в почтовом адресе, например: δοκιμή@παράδειγμα.δοκιμή или 测试@测试.测试. Текущая поддержка ограничена, но есть большой интерес в широком распространении RFC 6531 и связанных с ним RFC в странах с обширной базой пользователей, для которых латиница не является родным алфавитом. SMTP-сервер исходящей почты Почтовый клиент должен знать IP-адрес SMTP-сервера, который задаётся как часть конфигурации (обыкновенно в виде DNS-имени). Сервер будет доставлять исходящие сообщения от лица пользователя. Ограничения доступа к серверу исходящей почты Администраторам сервера необходимо контролировать то, какие клиенты могут использовать сервер. Это позволяет им бороться с такими злоупотреблениями, как спам. Обычно используются два решения: В прошлом многие системы вводили ограничения по местоположению клиента, допуская к использованию лишь тех, чей IP-адрес был среди подконтрольных администраторам. Современные серверы обычно предлагают альтернативную систему, требующую аутентификацию клиентов для получения доступа. Ограничение доступа по местоположению В этом случае SMTP-сервер интернет-провайдера не разрешит допуск пользователям «за пределами» сети провайдера. Точнее, сервер может допустить лишь тех пользователей, чей IP-адрес предоставлен данным провайдером, что эквивалентно требованию соединения с Интернетом с помощью этого провайдера. Мобильный пользователь часто может оказаться в сети, отличной от сети своего провайдера, и потому сообщения не будут отправляться. У данной системы есть несколько разновидностей. Например, SMTP-сервер организации может предоставлять доступ только пользователям той же сети, блокируя остальных пользователей. Также сервер может проводить ряд проверок клиентского IP-адреса. Эти методы обычно использовались организациями и учреждениями, например университетами, для внутреннего пользования сервером. Однако, большая их часть теперь использует описанные ниже методы аутентификации. Благодаря ограничению доступа определённым адресам, администраторы сервера могут легко определить адрес любого злоумышленника. Если пользователь может использовать различных провайдеров для соединения с Интернетом, этот вид ограничения становится нецелесообразным, а изменение настроенного адреса SMTP-сервера исходящей почты непрактично. Крайне желательно иметь возможность использовать такую информацию о настройках клиента, которая не нуждается в изменении. Аутентификация клиента Вместо описанного ранее ограничения по местоположению, современные SMTP-серверы обычно требуют аутентификацию пользователей перед получением доступа. Эта система, будучи более гибкой, поддерживает мобильных пользователей и предоставляет им фиксированный выбор настроенного сервера исходящей почты. Открытый релей Сервер, доступный для широкой сети и не предоставляющий эти виды ограничения доступа, называют открытым релеем. Сейчас такие серверы считаются дурным тоном. Порты Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты — 25 или 587. Спецификации и многие серверы поддерживают и тот, и другой порты. Хотя некоторые серверы поддерживают порт 465 для безопасного SMTP, но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищённая сессия между клиентом и сервером. Некоторые серверы настроены на отклонение всех ретрансляций по порту 25, но пользователям, прошедшим аутентификацию по порту 587, позволено перенаправлять сообщения на любой действительный адрес. Некоторые провайдеры перехватывают порт 25, перенаправляя трафик на свой собственный SMTP-сервер вне зависимости от адреса назначения. Таким образом, их пользователи не могут получить доступ к серверу за пределами провайдерской сети по порту 25. Некоторые серверы поддерживают аутентифицированный доступ по дополнительному, отличному от 25, порту, позволяя пользователям соединяться с ними, даже если порт 25 заблокирован. Пример простейшей SMTP-сессии C: — клиент, S: — серверы S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM: <someusername@somecompany.ru> S:250 someusername@somecompany.ru sender accepted C:RCPT TO: <user1@company.tld> S:250 user1@company.tld ok C:RCPT TO: <user2@company.tld> S:550 user2@company.tld unknown user account C:DATA S:354 Enter mail, end with "." on a line by itself C:From: Some User <someusername@somecompany.ru> C:To: User1 <user1@company.tld> C:Subject: tema C:Content-Type: text/plain C: C:Hi! C:. S:250 769947 message accepted for delivery C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP closing connection S: (закрывает соединение) В результате такой сессии письмо будет доставлено адресату user1@company.tld, но не будет доставлено адресату user2@company.tld, потому что такого адреса не существует. Дополнительные расширения Многие клиенты запрашивают расширения SMTP, поддерживаемые сервером, с помощью команды HELO из спецификации расширенного SMTP (RFC 1870). HELO используется только в том случае, если сервер не ответил на EHLO. Современные клиенты могут использовать ключ SIZE расширения ESMTP для запроса максимального размера сообщения, которое будет принято. Более старые клиенты и серверы могут попытаться передать чрезмерно большие сообщения, которые будут отклонены после потребления сетевых ресурсов, включая время соединения. Пользователи могут вручную заранее определить максимальный размер, принимаемый ESMTP-серверами. Клиент заменяет команду HELO на EHLO. S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP smtp2.example.com объявляет, что он примет сообщение размером не больше чем октетов (8-битных байтов). В зависимости от фактического использования сервера, он может на данный момент не принять сообщение такой величины. В простейшем случае ESMTP-сервер объявит максимальный SIZE только при взаимодействии с пользователем через HELO. Расширенный SMTP-протокол Расширенный SMTP (ESMTP) (иногда называемый Enhanced SMTP) — это определение расширений протокола для стандарта SMTP. ESMTP был определен в ноябре 1995 года в публикации IETF RFC 1869, которая установила общую структуру для всех существующих и будущих расширений. ESMTP определяет согласованные и управляемые средства, с помощью которых могут быть идентифицированы клиенты и серверы ESMTP, а серверы могут указывать поддерживаемые расширения. Исходный протокол SMTP поддерживал только неаутентифицированные незашифрованные текстовые сообщения ASCII, восприимчивые к атакам типа «злоумышленник в середине», спуфингу и рассылке спама, и требуя, чтобы любые двоичные данные перед передачей кодировались в читаемый текст. В ряде дополнительных расширений указаны различные механизмы решения этих проблем. Обнаружение дополнительных расширений Клиенты изучают поддерживаемые сервером параметры, используя приветствие EHLO вместо исходного HELO. Клиенты возвращаются к HELO, только если сервер не поддерживает расширения SMTP. Современные клиенты могут использовать ключевое слово SIZE расширения ESMTP, чтобы запросить у сервера максимальный размер сообщения, которое будет принято. Старые клиенты и серверы могут пытаться передать сообщения слишком большого размера, которые будут отклонены после использования сетевых ресурсов, включая время подключения к сетевым ссылкам, которое оплачивается поминутно. Пользователи могут заранее вручную определить максимальный размер, допустимый для серверов ESMTP. Клиент заменяет команду HELO командой EHLO. Передача двоичных данных Исходный SMTP поддерживает только одно тело текста ASCII, поэтому любые двоичные данные должны быть закодированы как текст в этом теле сообщения перед передачей, а затем декодированы получателем. Обычно использовались двоичные кодировки текста, такие как uuencode и BinHex. Для решения этой проблемы была разработана команда 8BITMIME. Он был стандартизирован в 1994 году как RFC 1652. Он упрощает прозрачный обмен сообщениями электронной почты, содержащими октеты вне семибитного набора символов ASCII, путем кодирования их как частей содержимого MIME, обычно кодируемых с помощью Base64. Расширения механизма доставки почты Ретранслятор почты по требованию (ODMR) — это расширение SMTP, стандартизованное в RFC 2645, которое позволяет периодически подключенному SMTP-серверу получать электронную почту, помещенную в очередь для него, когда он подключен. Расширение интернационализации Исходный SMTP поддерживает адреса электронной почты, состоящие только из символов ASCII, что неудобно для пользователей, чей собственный сценарий не основан на латинице или которые используют диакритические знаки вне набора символов ASCII. Это ограничение было снято с помощью расширений, позволяющих использовать UTF-8 в именах адресов. RFC 5336 представил экспериментальную команду UTF8SMTP, а позже был заменен RFC 6531, в котором была представлена команда SMTPUTF8. Эти расширения обеспечивают поддержку многобайтовых символов и символов, отличных от ASCII, в адресах электронной почты, например, с диакритическими знаками и другими языковыми символами, такими как греческий и китайский. Текущая поддержка ограничена, но существует большой интерес к широкому принятию RFC 6531 и связанных с ним RFC в таких странах, как Китай, с большой пользовательской базой, где латинский (ASCII) является иностранным алфавитом. Расширения Как и SMTP, ESMTP — это протокол, используемый для передачи почты Интернета. Он используется как межсерверный транспортный протокол и (с принудительным ограниченным поведением) как протокол отправки почты. Основная функция идентификации для клиентов ESMTP — открыть передачу с помощью команды EHLO (Extended HELLO), а не HELO (Hello, оригинальный стандарт RFC 821). Сервер ответит успешно (код 250), отказом (код 550) или ошибкой (код 500, 501, 502, 504 или 421), в зависимости от его конфигурации. Сервер ESMTP возвращает код 250 OK в многострочном ответе со своим доменом и списком ключевых слов для обозначения поддерживаемых расширений. Сервер, соответствующий RFC 821, возвращает код ошибки 500, позволяя клиентам ESMTP попробовать либо HELO, либо QUIT. Каждое расширение услуги определяется в утвержденном формате в последующих RFC и регистрируется в Internet Assigned Numbers Authority (IANA). Первыми определениями были дополнительные услуги RFC 821: SEND, SOML (отправка или почта), SAML (отправка и почта), EXPN, HELP и TURN. Был установлен формат дополнительных SMTP-глаголов и для новых параметров в MAIL и RCPT. Некоторые относительно распространенные ключевые слова (не все из которых соответствуют командам), используемые сегодня: 8BITMIME - 8-битная передача данных, RFC 6152 ATRN - TURN с проверкой подлинности для ретрансляции почты по требованию, RFC 2645 AUTH - аутентифицированный SMTP, RFC 4954 CHUNKING - Разделение на части, RFC 3030 DSN - уведомление о состоянии доставки, RFC 3461 ETRN - Расширенная версия команды запуска удаленной очереди сообщений TURN, RFC 1985 HELP - Предоставьте полезную информацию, RFC 821 PIPELINING - конвейерная обработка команд, RFC 2920 SIZE - Объявление размера сообщения, RFC 1870 STARTTLS - Безопасность транспортного уровня, RFC 3207 (2002) SMTPUTF8 - разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC 6531 Формат ESMTP был переформулирован в RFC 2821 (заменяющий RFC 821) и обновлен до последнего определения в RFC 5321 в 2008 году. Поддержка команды EHLO на серверах стала обязательной, а HELO обозначил обязательный откат. Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются ключевым словом сообщения EHLO, начинающимся с «X», и с любыми дополнительными параметрами или глаголами, отмеченными аналогичным образом. Команды SMTP не чувствительны к регистру. Они представлены здесь с заглавной буквы только для акцента. SMTP-сервер, для которого требуется особый метод использования заглавных букв, является нарушением стандарта. Безопасность SMTP и спам Изначальная спецификация SMTP не включала средств для аутентификации отправителей. Впоследствии, в RFC 2554, было введено расширение. Расширение SMTP (ESMTP) предоставляет почтовым клиентам возможности задания механизма обеспечения безопасности для сервера, аутентификации и профиля безопасности SASL (Simple Authentication and Security Layer) для последующих передач сообщений. Продукты Microsoft реализуют собственный протокол — SPA (Secure Password Authentication) с помощью расширения SMTP-AUTH. Однако непрактичность широкого распространения реализации и управления SMTP-AUTH означает, что проблема спама не может быть решена с его помощью. Обширное изменение SMTP, так же как и полная его замена, считаются непрактичными из-за огромной инсталлированной базы SMTP. Internet Mail 2000 был одним из претендентов для такой замены. Спам функционирует благодаря различным факторам, в том числе не соответствующие стандартам реализации MTA, уязвимости в защите операционных систем (усугубляемые постоянным широкополосным подключением), что позволяет спамерам удалённо контролировать компьютер конечного пользователя и посылать с него спам. Существует несколько предложений для побочных протоколов, помогающих работе SMTP. Исследовательская группа Anti-Spam (The Anti-Spam Research Group — ASRG) — подразделение Исследовательской группы Интернет-технологий работает над почтовой аутентификацией и другими предложениями для предоставления простой аутентификации, которая будет гибкой, легковесной и масштабируемой. Недавняя деятельность Инженерного совета Интернета (IETF) включает в себя MARID (2004), приведший к двум утверждённым IETF-экспериментам в 2005, и DomainKeys Identified Mail в 2006. Расширения ESMTP STARTTLS в RFC 1869 предписывает начинать сессию не командой HELO, а командой EHLO. В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола. Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например: ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 HELO Стандарты RFC RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653) RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30) RFC 4954 SMTP Service Extension for Authentication (заменяет RFC 2554) RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11) RFC 2920 SMTP Service Extension for Command Pipelining (STD 60) RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487) RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891) RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892) RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893) RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894) RFC 3552 Guidelines for Writing RFC Text on Security Considerations RFC 3834 Recommendations for Automatic Responses to Electronic Mail RFC 4409 Message Submission for Mail (заменяет RFC 2476) RFC 5321 Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821) RFC 5336 SMTP Extension for Internationalized Email Addresses Перевод RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA Перевод RFC 2554 — Расширение сервиса SMTP для аутентификации Перевод RFC 5321 — Простой протокол передачи электронной почты (SMTP) См. также LMTP — производный от SMTP протокол, ориентированный на работу без очереди сообщений. POP3 IMAP TCP Sender Policy Framework Sender ID X.400 Предотвращение утечек информации через SMTP Литература Электронная почта Протоколы прикладного уровня


source: wikipedia

text: SSH ( — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем. SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол. Таким образом, можно не только удалённо работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток или видео (например, с веб-камеры). Также SSH может использовать сжатие передаваемых данных для последующего их шифрования, что удобно, например, для удалённого запуска клиентов X Window System. Большинство хостинг-провайдеров за определённую плату предоставляет клиентам доступ к их домашнему каталогу по SSH. Это может быть удобно как для работы в командной строке, так и для удалённого запуска программ (в том числе графических приложений). Техническая информация о протоколе SSH — это протокол прикладного уровня. SSH-сервер обычно прослушивает соединения на TCP-порту 22. Спецификация протокола SSH-2 содержится в RFC 4251. Для аутентификации сервера в SSH используется протокол аутентификации сторон на основе алгоритмов электронно-цифровой подписи RSA или DSA, но допускается также аутентификация при помощи пароля (режим обратной совместимости с Telnet) и даже ip-адреса хоста (режим обратной совместимости с rlogin). Аутентификация по паролю наиболее распространена. При каждом подключении подобно https вырабатывается общий секретный ключ для шифрования трафика. При аутентификации по ключевой паре предварительно генерируется пара открытого и закрытого ключей для определённого пользователя. На машине, с которой требуется произвести подключение, хранится закрытый ключ, а на удалённой машине — открытый. Эти файлы не передаются при аутентификации, система лишь проверяет, что владелец открытого ключа также владеет и закрытым. При данном подходе, как правило, настраивается автоматический вход от имени конкретного пользователя в ОС. Аутентификация по ip-адресу небезопасна, эту возможность чаще всего отключают. Для создания общего секрета (сеансового ключа) используется алгоритм Диффи — Хеллмана (DH). Для шифрования передаваемых данных используется симметричное шифрование, алгоритмы AES, Blowfish или 3DES. Целостность передачи данных проверяется с помощью CRC32 в SSH1 или HMAC-SHA1/HMAC-MD5 в SSH2. Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, что и архиватор ZIP. Сжатие SSH включается лишь по запросу клиента, и на практике используется редко. История и разработка Версия 1.x В 1995 году Тату Юлёнен, исследователь из Технологического университета Хельсинки, Финляндия, разработал первую версию протокола (теперь называемого SSH-1), вызванную атакой по сбору пароля в его университетской сети. Целью SSH было заменить более ранние протоколы rlogin, TELNET, FTP [16] и rsh, которые не обеспечивали строгую аутентификацию и конфиденциальность. Юлёнен выпустил свою реализацию как бесплатное ПО в июле 1995 года, и инструмент быстро завоевал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах. В декабре 1995 года Юлёнен основал SSH Communications Security для продвижения и разработки SSH. Первоначальная версия программного обеспечения SSH использовала различные части бесплатного программного обеспечения, такие как GNU libgmp, но более поздние версии, выпущенные SSH Communications Security, превратились во всё более проприетарное программное обеспечение. Было подсчитано, что к 2000 году количество пользователей выросло до 2 миллионов. Версия 2.x «Secsh» было официальным названием группы инженеров Интернета (IETF) для рабочей группы IETF, ответственной за версию 2 протокола SSH. В 2006 году обновлённая версия протокола SSH-2 была принята в качестве стандарта. Эта версия несовместима с SSH-1. SSH-2 отличается как безопасностью, так и улучшенными функциями по сравнению с SSH-1. Например, лучшая безопасность достигается за счёт обмена ключами Диффи-Хеллмана и строгой проверки целостности с помощью кодов аутентификации сообщений. Новые функции SSH-2 включают возможность запускать любое количество сеансов оболочки через одно соединение SSH. Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0 +), Lsh и Dropbear , поддерживают только протокол SSH-2. Версия 1.99 В январе 2006 года, намного позже, чем была создана версия 2.1, RFC 4253 указывал, что сервер SSH, который поддерживает как 2.0, так и предыдущие версии SSH, должен идентифицировать свою прототипную версию как 1.99. Это не актуальная версия, а метод определения обратной совместимости. OpenSSH и OSSH В 1999 году разработчики, желающие иметь свободную реализацию, вернулись к старому выпуску 1.2.12 исходной программы SSH, который последний раз выпускался под лицензией с открытым исходным кодом. Пакет OSSH Бьорна Грёнвалля был разработан на основе этой кодовой базы. Вскоре после этого разработчики OpenBSD использовали код Грёнвалля и, проделав большую работу над ним, создали OpenSSH, который поставлялся с версией OpenBSD 2.6. Начиная с этой версии, была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы. По состоянию на 2005 год OpenSSH был самой популярной реализацией SSH, входящей по умолчанию в большое количество операционных систем. OSSH тем временем устарел. OpenSSH продолжает поддерживаться и поддерживает протокол SSH-2, исключив поддержку SSH-1 из кодовой базы с выпуском OpenSSH 7.6. Стандарты и программные реализации Первая версия протокола, SSH-1, была разработана в 1995 году исследователем Тату Улёненом из Технологического университета Хельсинки (Финляндия). SSH-1 был написан для обеспечения большей конфиденциальности, чем протоколы rlogin, telnet и rsh. В 1996 году была разработана более безопасная версия протокола, SSH-2, несовместимая с SSH-1. Протокол приобрёл ещё большую популярность, и к 2000 году у него было около двух миллионов пользователей. В настоящее время под термином «SSH» обычно подразумевается именно SSH-2, так как первая версия протокола ввиду существенных недостатков сейчас практически не применяется. В 2006 году протокол был утверждён рабочей группой IETF в качестве Интернет‐стандарта. Распространены две реализации SSH: частная коммерческая и бесплатная свободная. Свободная реализация называется OpenSSH. К 2006 году 80 % компьютеров сети Интернет использовало именно OpenSSH. Частная реализация разрабатывается организацией SSH Communications Security, которая является стопроцентным подразделением корпорации Tectia, она бесплатна для некоммерческого использования. Эти реализации содержат практически одинаковый набор команд. Протокол SSH-1, в отличие от протокола telnet, устойчив к атакам прослушивания трафика («снифинг»), но неустойчив к атакам «человек посередине». Протокол SSH-2 также устойчив к атакам путём присоединения посередине (), так как невозможно включиться в уже установленную сессию или перехватить её. Для предотвращения атак «человек посередине» при подключении к хосту, ключ которого ещё не известен клиенту, клиентское ПО показывает пользователю «слепок ключа» (). Рекомендуется тщательно сверять показываемый клиентским ПО «слепок ключа» со слепком ключа сервера, желательно полученным по надёжным каналам связи или лично. Поддержка SSH реализована во всех UNIX‐подобных системах, и на большинстве из них в числе стандартных утилит присутствуют клиент и сервер ssh. Существует множество реализаций SSH-клиентов и для не-UNIX ОС. Большую популярность протокол получил после широкого развития анализаторов трафика и способов нарушения работы локальных сетей, как альтернативное небезопасному протоколу Telnet решение для управления важными узлами. Для работы по SSH нужен SSH-сервер и SSH-клиент. Сервер прослушивает соединения от клиентских машин и при установлении связи производит аутентификацию, после чего начинает обслуживание клиента. Клиент используется для входа на удалённую машину и выполнения команд. Для соединения сервер и клиент должны создать пары ключей — открытых и закрытых — и обменяться открытыми ключами. Обычно используется также и пароль. SSH-серверы BSD: OpenSSH Linux: dropbear, lsh-server, openssh-server, ssh, Tectia SSH Server Windows: freeSSHd, copssh, WinSSHD, KpyM Telnet/SSH Server, MobaSSH, OpenSSH через Cygwin, Tectia SSH Server SSH-клиенты и оболочки GNU/Linux, *BSD: kdessh, lsh-client, openssh-client, putty, ssh, Vinagre, Tectia SSH (SSH Communications Security) Client MS Windows и Windows NT: PuTTY\KiTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell, Tectia SSH (SSH Communications Security) Client MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole, Tectia SSH (SSH Communications Security) Client Mac OS: iTerm2, NiftyTelnet SSH, vSSH, Symbian OS: PuTTY Java: MindTerm, AppGate Security Server J2ME: MidpSSH iPhone: i-SSH, ssh (в комплекте с Terminal), Termius, OpenTerm, LibTerm, Shelly Android: connectBot, Admin Hands, Server Auditor, JuiceSSH Blackberry: BBSSH MAEMO 5: OpenSSH MeeGo 1.2 Harmattan: OpenSSH Советы по безопасности использования SSH Запрет на удалённый root-доступ. Запрет подключения с пустым паролем или отключение входа по паролю. Выбор нестандартного порта для SSH-сервера. Использование длинных SSH2 RSA-ключей (2048 бит и более). Системы шифрования на основе RSA считаются надёжными, если длина ключа не менее . Ограничение списка IP-адресов, с которых разрешён доступ (например, настройкой файрвола). Запрет доступа с некоторых потенциально опасных адресов. Отказ от использования распространённых или широко известных системных логинов для доступа по SSH. Регулярный просмотр сообщений об ошибках аутентификации. Установка систем обнаружения вторжений (IDS). Использование ловушек, подделывающих SSH-сервис (honeypot). Реализация технологии. Примеры использования SSH Команда подключения к локальному SSH-серверу из командной строки GNU/Linux или FreeBSD для пользователя pacify (сервер прослушивает нестандартный порт 30000): $ ssh -p 30000 pacify@127.0.0.1 Генерация пары ключей (в UNIX-подобных ОС) осуществляется командой $ ssh-keygen Генерация пары SSH-2 RSA-ключей длиной 4096 бита программой puttygen под UNIX‐подобными ОС: $ puttygen -t rsa -b 4096 -o sample Некоторые клиенты, например, PuTTY, имеют и графический интерфейс пользователя. Для использования SSH в Python существуют такие модули, как python-paramiko и python-twisted-conch. SSH-туннелирование SSH-туннель — это туннель, создаваемый посредством SSH-соединения и используемый для шифрования туннелированных данных. Используется для того, чтобы обезопасить передачу данных в Интернете (аналогичное назначение имеет IPsec). При пересылке через SSH-туннель незашифрованный трафик любого протокола шифруется на одном конце SSH-соединения и расшифровывается на другом. Практическая реализация может выполняться несколькими способами: Созданием Socks-прокси для приложений, которые не умеют работать через SSH-туннель, но могут работать через Socks-прокси. Использованием приложений, умеющих работать через SSH-туннель. Созданием VPN-туннеля, подходит практически для любых приложений. Если приложение работает с одним определённым сервером, можно настроить SSH-клиент таким образом, чтобы он пропускал через SSH-туннель TCP-соединения, приходящие на определённый TCP-порт машины, на которой запущен SSH-клиент. Например, клиенты Jabber подключаются по умолчанию на порт 443. Тогда, чтобы настроить подключение к серверу Jabber через SSH-туннель, SSH-клиент настраивается на перенаправление подключений с любого порта локальной машины (например, с порта 4430) на удалённый сервер (например, jabber.example.com и порт 443): $ ssh -L 4430:jabber.example.com:443 somehostВ данном случае Jabber-клиент настраивается на подключение к порту 4430 сервера localhost (если ssh-клиент запущен на той же машине что и Jabber-клиент). Для создания ssh-туннеля необходима машина с запущенным ssh-сервером и доступом к jabber.example.com. Такая конфигурация может использоваться в случае, если с локальной машины доступ к jabber.example.com закрыт файрволом, но есть доступ к некоторому ssh-серверу, у которого ограничения доступа в Интернет отсутствуют. См. также SFTP SCP SSL TLS Mosh (программа) Примечания Ссылки Стандарты RFC 4250 — The Secure Shell (SSH) Protocol Assigned Numbers RFC 4251 — The Secure Shell (SSH) Protocol Architecture RFC 4252 — The Secure Shell (SSH) Authentication Protocol RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol RFC 4254 — The Secure Shell (SSH) Connection Protocol RFC 4255 — Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints RFC 4256 — Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) RFC 4335 — The Secure Shell (SSH) Session Channel Break Extension RFC 4344 — The Secure Shell (SSH) Transport Layer Encryption Modes RFC 4345 — Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol RFC 4419 — Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol RFC 4432 — RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol RFC 4716 — The Secure Shell (SSH) Public Key File Format SSH-клиенты OpenSSH — свободная библиотека и набор утилит для поддержки шифрования PuTTY — популярный кроссплатформенный SSH-клиент https://serverauditor.com/ - популярный мобильный кроссплатформенный SSH-клиент (Android, iOS, Google Chrome) Сравнение SSH-клиентов Программы доступа к файлам WinSCP — SFTP-клиент для Microsoft Windows FileZilla — SFTP-клиент для Microsoft Windows, Linux, MacOS Прочее Уязвимость в SSH Теория и практика использования SSH Analyzing Malicious SSH Login Attempts Команды Linux / SSH SSH для администратора Криптография Unix Текстовый интерфейс Интернет-протоколы SSH


text: TCP/IP — сетевая модель передачи данных, представленных в цифровом виде. Модель описывает способ передачи данных от источника информации к получателю. В модели предполагается прохождение информации через четыре уровня, каждый из которых описывается правилом (протоколом передачи). Наборы правил, решающих задачу по передаче данных, составляют стек протоколов передачи данных, на которых базируется Интернет. Название TCP/IP происходит из двух важнейших протоколов семейства — Transmission Control Protocol (TCP) и Internet Protocol (IP), которые были первыми разработаны и описаны в данном стандарте. Также изредка упоминается как модель DOD (Department of Defense) в связи с историческим происхождением от сети ARPANET из 1970-х годов (под управлением DARPA, Министерства обороны США). Набор интернет-протоколов обеспечивает сквозную передачу данных, определяющую, как данные должны пакетироваться, обрабатываться, передаваться, маршрутизироваться и приниматься. Эта функциональность организована в четыре слоя абстракции, которые классифицируют все связанные протоколы в соответствии с объёмом задействованных сетей. От самого низкого до самого высокого уровня — это уровень связи, содержащий методы связи для данных, которые остаются в пределах одного сегмента сети; интернет-уровень, обеспечивающий межсетевое взаимодействие между независимыми сетями; транспортный уровень, обрабатывающий связь между хостами; и прикладной уровень, который обеспечивает обмен данными между процессами для приложений. Развитием архитектуры Интернета и протоколов в модели TCP/IP занимается открытое международное сообщество проектировщиков IETF. История Стек протоколов TCP/IP был создан на основе NCP (Network Control Protocol) группой разработчиков под руководством Винтона Серфа в 1972 году. В июле 1976 года Винт Серф и Боб Кан впервые продемонстрировали передачу данных с использованием TCP по трём различным сетям. Пакет прошёл по следующему маршруту: Сан-Франциско — Лондон — Университет Южной Калифорнии. К концу своего путешествия пакет проделал не потеряв ни одного бита. В 1978 году Серф, Джон Постел и решили выделить в TCP две отдельные функции: межсетевой протокол). TCP был ответственен за разбивку сообщения на датаграммы () и соединение их в конечном пункте отправки. IP отвечал за передачу (с контролем получения) отдельных датаграмм. Вот так родился современный протокол Интернета. А с 1 января 1983 года ARPANET перешла на новый протокол. Этот день принято считать официальной датой рождения Интернета. Формальная спецификация и стандарты Технические стандарты, лежащие в основе набора TCP/IP протоколов, были переданы Инженерному совету Интернета (IETF). Характеристикой архитектуры Internet Protocol Suite является широкое разделение на рабочие области для протоколов, составляющих его основную функциональность. Определяющей спецификацией пакета является RFC 1122, которая в общих чертах описывает четыре уровня абстракции. Они выдержали испытание временем, поскольку IETF никогда не изменяла эту структуру. Как таковая модель сети TCP/IP предшествует модели OSI, более всеобъемлющей эталонной структуре для общих сетевых систем. Уровни стека TCP/IP Стек протоколов TCP/IP включает в себя четыре уровня: Прикладной уровень (Application Layer), Транспортный уровень (Transport Layer), Межсетевой уровень (Сетевой уровень) (Internet Layer), Канальный уровень (Network Access Layer). Протоколы этих уровней полностью реализуют функциональные возможности модели OSI. На стеке протоколов TCP/IP построено всё взаимодействие пользователей в IP-сетях. Стек является независимым от физической среды передачи данных, благодаря чему, в частности, обеспечивается полностью прозрачное взаимодействие между проводными и беспроводными сетями. Прикладной уровень На прикладном уровне (Application layer) работает большинство сетевых приложений. Эти программы имеют свои собственные протоколы обмена информацией, например, интернет браузер для протокола HTTP, ftp-клиент для протокола FTP (передача файлов), почтовая программа для протокола SMTP (электронная почта), SSH (безопасное соединение с удалённой машиной), DNS (преобразование символьных имён в IP-адреса) и многие другие. В массе своей эти протоколы работают поверх TCP или UDP и привязаны к определённому порту, например: HTTP на TCP-порт 80 или 8080, FTP на TCP-порт 20 (для передачи данных) и 21 (для управляющих команд), SSH на TCP-порт 22, запросы DNS на порт UDP (реже TCP) 53, обновление маршрутов по протоколу RIP на UDP-порт 520. Эти порты определены Агентством по выделению имён и уникальных параметров протоколов (IANA). К этому уровню относятся: Echo, Finger, Gopher, HTTP, HTTPS, IMAP, IMAPS, IRC, NNTP, NTP, POP3, POPS, QOTD, RTSP, SNMP, SSH, Telnet, XDMCP. Транспортный уровень Протоколы транспортного уровня (Transport layer) могут решать проблему негарантированной доставки сообщений («дошло ли сообщение до адресата?»), а также гарантировать правильную последовательность прихода данных. В стеке TCP/IP транспортные протоколы определяют, для какого именно приложения предназначены эти данные. Протоколы автоматической маршрутизации, логически представленные на этом уровне (поскольку работают поверх IP), на самом деле являются частью протоколов сетевого уровня; например OSPF (IP идентификатор 89). TCP (IP идентификатор 6) — «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP. UDP (IP идентификатор 17) протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов. В приложениях, требующих гарантированной передачи данных, используется протокол TCP. UDP обычно используется в таких приложениях, как потоковое видео и компьютерные игры, где допускается потеря пакетов, а повторный запрос затруднён или не оправдан, либо в приложениях вида запрос-ответ (например, запросы к DNS), где создание соединения занимает больше ресурсов, чем повторная отправка. И TCP, и UDP используют для определения протокола верхнего уровня число, называемое портом. Сетевой (межсетевой) уровень Межсетевой уровень (Network layer) изначально разработан для передачи данных из одной сети в другую. На этом уровне работают маршрутизаторы, которые перенаправляют пакеты в нужную сеть путём расчёта адреса сети по маске сети. Примерами такого протокола является X.25 и IPC в сети ARPANET. С развитием концепции глобальной сети в уровень были внесены дополнительные возможности по передаче из любой сети в любую сеть, независимо от протоколов нижнего уровня, а также возможность запрашивать данные от удалённой стороны, например в протоколе ICMP (используется для передачи диагностической информации IP-соединения) и IGMP (используется для управления multicast-потоками). ICMP и IGMP расположены над IP и должны попасть на следующий — транспортный — уровень, но функционально являются протоколами сетевого уровня, и поэтому их невозможно вписать в модель OSI. Пакеты сетевого протокола IP могут содержать код, указывающий, какой именно протокол следующего уровня нужно использовать, чтобы извлечь данные из пакета. Это число — уникальный IP-номер протокола. ICMP и IGMP имеют номера, соответственно, 1 и 2. К этому уровню относятся: DVMRP, ICMP, IGMP, MARS, PIM, RIP, RIP2, RSVP Канальный уровень Канальный уровень () описывает способ кодирования данных для передачи пакета данных на физическом уровне (то есть специальные последовательности бит, определяющих начало и конец пакета данных, а также обеспечивающие помехоустойчивость). Ethernet, например, в полях заголовка пакета содержит указание того, какой машине или машинам в сети предназначен этот пакет. Примеры протоколов канального уровня — Ethernet, IEEE 802.11 WLAN, SLIP, Token Ring, ATM и MPLS. PPP не совсем вписывается в такое определение, поэтому обычно описывается в виде пары протоколов HDLC/SDLC. MPLS занимает промежуточное положение между канальным и сетевым уровнем и, строго говоря, его нельзя отнести ни к одному из них. Канальный уровень иногда разделяют на 2 подуровня — LLC и MAC. Кроме того, канальный уровень описывает среду передачи данных (будь то коаксиальный кабель, витая пара, оптическое волокно или радиоканал), физические характеристики такой среды и принцип передачи данных (разделение каналов, модуляцию, амплитуду сигналов, частоту сигналов, способ синхронизации передачи, время ожидания ответа и максимальное расстояние). При проектировании стека протоколов на канальном уровне рассматривают помехоустойчивое кодирование — позволяющие обнаруживать и исправлять ошибки в данных вследствие воздействия шумов и помех на канал связи. Сравнение с моделью OSI Три верхних уровня в модели OSI, то есть уровень приложения, уровень представления и уровень сеанса, отдельно не различаются в модели TCP/IP, которая имеет только прикладной уровень над транспортным уровнем. Хотя некоторые чистые приложения протокола OSI, такие как X.400, также объединяют их, нет требования, чтобы стек протокола TCP/IP должен накладывать монолитную архитектуру над транспортным уровнем. Например, протокол NFS-приложений работает через протокол представления данных External Data Representation (XDR), который, в свою очередь, работает по протоколу Remote Procedure Call (RPC). RPC обеспечивает надёжную передачу данных, поэтому он может безопасно использовать транспорт UDP с максимальным усилием. Различные авторы интерпретировали модель TCP/IP по-разному и не согласны с тем, что уровень связи или вся модель TCP/IP охватывает проблемы первого уровня модели OSI (физический уровень) или предполагается, что аппаратный уровень ниже уровня канала. Несколько авторов попытались включить слои 1 и 2 модели OSI в модель TCP/IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU). Это часто приводит к модели с пятью слоями, где уровень связи или уровень доступа к сети разделяются на слои 1 и 2 модели OSI. Усилия по разработке протокола IETF не касаются строгого расслоения. Некоторые из его протоколов могут не соответствовать чисто модели OSI, хотя RFC иногда ссылаются на неё и часто используют старые номера уровня OSI. IETF неоднократно заявлял, что разработка интернет-протокола и архитектуры не должна соответствовать требованиям OSI. В RFC 3439, адресованном интернет-архитектуре, содержится раздел, озаглавленный «Слой, считающийся вредным». Например, считается, что уровни сеанса и представления пакета OSI включены в прикладной уровень пакета TCP/IP. Функциональность уровня сеанса можно найти в протоколах, таких как HTTP и SMTP, и более очевидна в таких протоколах, как Telnet и протокол инициации сеанса (SIP). Функциональность уровня сеанса также реализована с нумерацией портов протоколов TCP и UDP, которые охватывают транспортный уровень в наборе TCP/IP. Функции уровня представления реализуются в приложениях TCP/IP со стандартом MIME при обмене данными. Конфликты очевидны также в оригинальной модели OSI, ISO 7498, когда не рассматриваются приложения к этой модели, например, ISO 7498/4 Management Framework или ISO 8648 Internal Organization of the Network layer (IONL). Когда рассматриваются документы IONL и Management Framework, ICMP и IGMP определяются как протоколы управления уровнем для сетевого уровня. Аналогичным образом IONL предоставляет структуру для «зависимых от подсетей объектов конвергенции», таких как ARP и RARP. Протоколы IETF могут быть инкапсулированы рекурсивно, о чём свидетельствуют протоколы туннелирования, такие как Инкапсуляция общей маршрутизации (GRE). GRE использует тот же механизм, который OSI использует для туннелирования на сетевом уровне. Существуют разногласия в том, как вписать модель TCP/IP в модель OSI, поскольку уровни в этих моделях не совпадают. К тому же, модель OSI не использует дополнительный уровень — «Internetworking» — между канальным и сетевым уровнями. Примером спорного протокола может быть ARP или STP. Вот как традиционно протоколы TCP/IP вписываются в модель OSI: Обычно в стеке TCP/IP верхние 3 уровня модели OSI (прикладной, представления и сеансовый) объединяют в один — прикладной. Поскольку в таком стеке не предусматривается унифицированный протокол передачи данных, функции по определению типа данных передаются приложению. Описание модели TCP/IP в технической литературе В модели TCP/IP, в отличие от модели OSI, физический уровень никак не описывается. Тем не менее, в некоторых учебниках, для лучшего понимания, описывается «гибридная модель TCP/IP — OSI» из 5 уровней, содержащая дополнительный — физический уровень. Следующая таблица показывает различные вариации в описании модели TCP/IP. Количество уровней варьируется от трёх до семи. Некоторые из моделей в приведённой таблицы взяты из учебников, которые являются вторичными источниками и могут расходиться с RFC 1122 и другими IETF-первоисточниками. См. также Сетевые сервисы Модель OSI Модель DOD Динамический порт lwIP uIP (micro IP) Примечания Литература Ссылки Официальный сайт IANA IANA — идентификаторы протоколов IANA — номера портов RFC 1122 RFC 793 — TCP RFC 791 — IP Интернет-протоколы


text: WackoWiki (произносится как "Ва́ккоВики", в документации часто используется просторечное название "Ва́ка") — вики-движок на PHP. В настоящий момент выпущена версия R6.1. Основные особенности Основное предполагаемое применение, на которое рассчитан движок — совместная работа группы над некоторым проектом, представляющим собой набор совместно редактируемых документов. В связи с этим в движке реализован достаточно мощный механизм разграничения прав, позволяющий ограничивать возможности пользователей по воздействию на документы (создатель страницы и администратор системы имеют возможность для операций чтения, изменения и комментирования её содержимого назначить список групп и конкретных пользователей, которым данная операция доступна). Также движок поддерживает автоматическое уведомление пользователей об изменениях в наблюдаемых страницах. Выбранный в движке способ ввода и редактирования текстов типичен для вики-движков: оформление текста делается с помощью несложной системы вики-разметки. Синтаксис разметки минимизирует переключение раскладок клавиатуры. Особенностью данной реализации является автоматический корректор типографики — некоторые действия по оформлению текста при выводе производятся автоматически, без преобразования исходного текста страницы (например, знак «минус», помещённый в тексте между словами и отделённый от них пробелами, автоматически преобразуется в типографское длинное тире, обычные парные кавычки — в кавычки-"ёлочки"). WikiEdit — javascript-расширение обычного поля ввода, позволяет вводить вики-разметку при помощи «горячих клавиш». Реализована довольно широкая номенклатура «форматеров» — средств для структурированного вывода текстов в различных формализованных видах, таких как логи IM, исходные тексты программ на языках PHP и SQL и т. п. Для упрощения оформления ссылок на вики-страницы в движке поддерживается соглашение, по которому выражение, записанное в стиле CamelCase (например, «ВотТакоеСлово»), считается именем страницы и автоматически преобразуется при выводе в ссылку на страницу с соответствующим именем. Это упрощает оформление (чтобы поставить ссылку на страницу с подобным именем, не нужно никакой разметки), что провоцирует соответствующее именование страниц на вики-сайтах, поддерживаемых данным движком. Для структуризации набора страниц используется механизм «кластеров». Страницы организуются в структуру, подобную древовидной файловой системе; присваиванием новой странице соответствующего имени она может быть помещена в нужное место этой структуры. Поддерживается два вида синтаксиса для описания страниц в кластере: url-like и twiki-like. Механизм «действий» (по сути — макросов, помещаемых в текст и при выводе автоматически заменяемых на определяемую действием информацию) позволяет автоматически выводить на страницы служебную информацию, например, формировать оглавления страниц, списки содержимого кластеров, перекрёстные ссылки и многое другое. Система многоязычна — на данный момент доступны 20 языков (bg, da, de, el, en, es, et, fa, fr, hi, hu, it, ja, ko, nl, pl, pt, ru, zh-tw, zh).Использует кодировку UTF-8. Поддерживаются устройства с различными размерами экранов благодаря адаптивному дизайну шаблона оформления. История Движок WackoWiki был создан на основании более раннего проекта WakkaWiki (разработчики Carlos Zottman и Hendrik Mans), предназначенного для совместной разработки в рамках небольших intranet-проектов. Разработка исходного движка была остановлена на стадии версии 0.1.2, в 2003 году. На его основе было запущено несколько (не менее шести) fork-проектов, одним из которых и стал WackoWiki. 30 апреля 2003 года вышла первая версия WackoWiki, получившая сразу номер 3. 31 июля 2004 года был завершён четвёртый выпуск WackoWiki. 27 марта 2005 года была выпущена версия R4.2После выхода версии 4.2 разработчики сфокусировались на новом проекте — NPJ, активность разработки WackoWiki резко снизилась. Некоторое время изменения в SVN-репозитории проекта ещё делались, но новых официальных версий так и не появилось. В настоящее время команда прекратила и разработку NPJ. В 2007 году проект был подобран maintainer-ом из Германии, сменил сайт с wackowiki.com на wackowiki.org, и теперь WackoWiki разрабатывает международная команда. 28 сентября 2008 года выпущена версия RC4.3 (статус — release candidate), не имеющая принципиальных отличий от 4.2, а содержащая лишь исправления некоторых ошибок. 20 марта 2011 года выпущена финальная версия R4.3. На конец 2011 года был заявлен выпуск версии 5.0. Фактически версия 5.0RC3 была доступна для скачивания с 20 марта 2012 года. Основные заявленные изменения: совместимость с PHP 5.3, нормализация базы данных, перенос изменений из проекта openSpace (также вики-движок, форк-проект WackoWiki 4.2, добавлен ряд новых инструментов, в частности, панель администратора. 22 апреля 2012 года выпущен релиз версии 5.0, а 17 июня 2012 года — 5.1 (с минимальными исправлениями). 12 июля 2014 года выпущена версия R5.4. 8 февраля 2018 года выпущена версия R5.5. 15 декабря 2019 года выпущена версия R6.0. Добавлена поддержка Юникода. 4 сентября 2021 года выпущена версия R6.1. Добавлена поддержка PHP 8, внедрён адаптивный интерфейс. Примечания Ссылки wackowiki.org на русском Недостатки Наследование ролей не поддерживается. Наследование настроек прав на ветку документов отсутствует, вместо него права родительского документа копируются в дочерний на момент его создания, так что впоследствии изменение прав на статью-родителя не отражается на дочерних материалах. Вики-движки Свободные системы управления сайтами Свободное программное обеспечение, написанное на PHP


text: TELNET ( от ) — сетевой протокол для реализации текстового терминального интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола. Современный стандарт протокола описан в RFC 854. Выполняет функции протокола прикладного уровня модели OSI. Протокол telnet использовался для удалённого администрирования различными сетевыми устройствами и программными серверами, но уступил SSH из-за безопасности. Тем не менее может являться единственной возможностью взаимодействовать через cli со встраиваемыми системами, например, с маршрутизаторами, так как на них отсутствует ssh. Введение Назначение протокола TELNET — в предоставлении достаточно общего двунаправленного восьмибитного байт-ориентированного средства связи. Его основная задача заключается в том, чтобы позволить терминальным устройствам и терминальным процессам взаимодействовать друг с другом. Предполагается, что этот протокол может быть использован для связи вида терминал-терминал («связывание») или для связи процесс-процесс («распределенные вычисления»). Устройство Хотя в сессии Telnet выделяют клиентскую и серверную стороны, протокол на самом деле полностью симметричен. После установления транспортного соединения (как правило, TCP) оба его конца играют роль «сетевых виртуальных терминалов» (, NVT), обменивающихся двумя типами данных: Прикладными данными (то есть данными, которые идут от пользователя к текстовому приложению на стороне сервера и обратно); Командами протокола Telnet, частным случаем которых являются опции, служащие для уяснения возможностей и предпочтений сторон. Хотя Telnet-сессии, выполняющейся по TCP, свойственен полный дуплекс, NVT должен рассматриваться как полудуплексное устройство, работающее по умолчанию в буферизированном строковом режиме. Прикладные данные проходят через протокол без изменений, то есть на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола данные представляют просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII, но при включённой опции Binary — любых. Хотя были предложены расширения для идентификации набора символов, на практике ими не пользуются. Все значения октетов прикладных данных, кроме 0xFF (десятичное: 255), передаются по транспорту как есть. Значение 0xFF передаётся последовательностью из двух октетов 0xFF. Это связано с тем, что октет 0xFF используется на транспортном уровне для кодирования опций. Опции Протокол предоставляет по умолчанию минимальную функциональность и набор расширяющих её опций. Принцип оговорённых опций требует проводить переговоры при включении каждой из опций. Одна сторона инициирует запрос, а другая сторона может либо принять, либо отвергнуть предложение. Если запрос принимается, то опция немедленно вступает в силу. Опции описаны отдельно от протокола как такового, и их поддержка программным обеспечением произвольна. Клиенту протокола (сетевому терминалу) предписывается отвергать запросы на включение неподдерживаемых и неизвестных опций. Принтер и клавиатура NVT Принтер NVT имеет неопределённую ширину каретки и длину страницы и должен иметь представление всех 95 печатных символов US-ASCII (коды с 32 по 126). Управляющие символы имеют следующие значения: Поддержка действия символов, помеченных как *, обязательна. Прочие могут производить заданное действие или не производить никакого; одна сторона не обязана предполагать ничего определённого о поддержке конкретных необязательных управляющих символов другой стороной. Последовательность «CR LF» должна обрабатываться как единый символ перевода строки и использоваться всякий раз, когда требуется их объединённое действие; последовательность «CR NUL» должна использоваться, где требуется только возврат каретки; использования символа CR следует избегать в других контекстах. Структура команд Telnet Каждая команда TELNET является многобайтовой последовательностью, начинающейся с кода 0xFF (десятичное: 255) «Interpret as Command» (IAC) и кода команды. Команды, отвечающие за договорённости по опции, являются трёхбайтовыми последовательностями, где третий байт является кодом опции. Нижеперечисленные коды и кодовые последовательности имеют соответственный смысл, только когда следуют сразу за IAC. Применения Исторически Telnet служил для удалённого доступа к интерфейсу командной строки операционных систем. Впоследствии его стали использовать для прочих текстовых интерфейсов, вплоть до игр MUD и анимированного ASCII-art. Теоретически даже обе стороны протокола могут являться не только людьми, но и программами. Иногда клиенты telnet используются для доступа к другим протоколам на основе транспорта TCP, см. Telnet и другие протоколы. Протокол telnet используется в управляющем соединении FTP, то есть заходить на сервер командой telnet ftp.example.net ftp для выполнения отладки и экспериментов не только возможно, но и правильно (в отличие от применения клиентов telnet для доступа к HTTP, IRC и большинству других протоколов). Telnet, наряду с HTTP, является основным протоколом для удалённой работы с сетевым оборудованием (управляемые коммутаторы и маршрутизаторы) и, в отличие от веб-интерфейса, предоставляет полный доступ к функциональным возможностям устройства, но при этом требует от специалиста навыков работы с командной строкой. Безопасность В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому он уязвим для любого вида атак, к которым уязвим его транспорт, то есть протокол TCP. Для функциональности удалённого доступа к системе в настоящее время применяется сетевой протокол SSH (особенно его версия 2), при создании которого упор делался именно на вопросы безопасности. Так что следует иметь в виду, что сессия Telnet весьма беззащитна, если только не осуществляется в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от Telnet как средства управления операционными системами давно отказались. Telnet и другие протоколы В среде специалистов по технологиям Интернета клиент Telnet иногда используется для осуществления ручного доступа (например, в целях отладки) к таким протоколам прикладного уровня, как HTTP, IRC, SMTP, POP3 и прочим текст-ориентированным протоколам на основе транспорта TCP. Однако использование клиента telnet в качестве клиента TCP может вызывать следующие нежелательные эффекты: Клиент может передать данные, которые вы не вводили (опции Telnet); Клиент не будет принимать октет 0xFF; Клиент будет искажать октет 0xFF при передаче; Клиент вообще может отказаться передавать октеты со старшим битом 1. Такие программы, как netcat, действительно обеспечивают чистый доступ к TCP, однако требуются специальные ухищрения (как-то stty -icrnl на UNIX-системе) для передачи перевода строки как CR LF (что требуется многими протоколами). Обычно клиент Telnet по умолчанию передаёт любой перевод строки как CR LF, независимо от его кодирования в системе клиента. Также для отладочного доступа к прикладным протоколам (кроме FTP и, собственно, Telnet) можно использовать клиент PuTTY в режиме «Raw» (чистый доступ к TCP) — PuTTY преобразует переводы строки отдельно от поддержки протокола Telnet. Ссылки RFC 854 TELNET protocol specification RFC 855 TELNET option specifications RFC 856 TELNET binary transmission RFC 857 TELNET echo option RFC 858 TELNET suppress Go Ahead option RFC 859 TELNET status option RFC 860 TELNET timing mark option RFC 861 TELNET extended options — list option RFC 885 Telnet end of record option RFC 1041 Telnet 3270 regime option RFC 1073 Telnet Window Size Option RFC 1079 Telnet terminal speed option RFC 1091 Telnet terminal-type option RFC 1096 Telnet X display location option RFC 1184 Telnet linemode option RFC 1205 5250 Telnet interface RFC 1372 Telnet remote flow control option RFC 1408 Telnet Environment Option RFC 1572 Telnet Environment Option (NEW-ENVIRON) RFC 2217 Telnet Com Port Control Option RFC 2941 Telnet Authentication Option RFC 2942 Telnet Authentication: Kerberos Version 5 RFC 2943 TELNET Authentication Using DSA RFC 2944 Telnet Authentication: SRP RFC 2946 Telnet Data Encryption Option RFC 4248 The telnet URI Scheme RFC 4777 IBM’s iSeries Telnet Enhancements Примечания Протоколы прикладного уровня Текстовый интерфейс Интернет-протоколы Сетевое программное обеспечение Программы удалённого администрирования


text: Ви́ки () — веб-сайт, содержимое которого пользователи могут самостоятельно изменять с помощью инструментов, предоставляемых самим сайтом. Форматирование текста и вставка различных объектов в текст производятся с использованием вики-разметки. В частности, на базе этих принципов построена Википедия и другие проекты Фонда Викимедиа. История Впервые термин «вики» для описания веб-сайта был использован в 1995 году Уордом Каннингемом, разработчиком первой вики-системы WikiWikiWeb, «Портлендского хранилища образцов» программного кода, созданной 25 марта 1995 года, который заимствовал слово гавайского языка, означающее «быстрый». Каннингем объяснил выбор названия движка тем, что он вспомнил работника международного аэропорта Гонолулу, посоветовавшего ему воспользоваться вики-вики шаттлом — небольшим автобусом, курсировавшим между терминалами аэропорта. Каннингем же планировал сделать движок, позволявший пользователям максимально быстро редактировать и создавать статьи. Каннингем первоначально описал вики как «простейшую онлайн-базу данных, которая может функционировать». Позже этому слову был придуман английский бэкроним («то, что я знаю, это...»). Сущность концепции вики Уорд Каннингем и его соавтор Бо Леуф в их книге The Wiki Way: Quick Collaboration on the Web описали сущность концепции вики следующим образом: Вики предлагает всем пользователям редактировать любую страницу или создавать новые страницы на вики-сайте, используя обычный веб-браузер без каких-либо его расширений. Вики поддерживает связи между разными страницами за счёт почти интуитивно понятного создания ссылок на другие страницы и отображения того, существуют данные страницы или нет. Вики не является тщательно изготовленным сайтом для случайных посетителей. Напротив, Вики стремится привлечь посетителей к непрерывному процессу создания и сотрудничества, который постоянно меняет вид сайта. Определяющие свойства Вики характеризуется такими признаками: Возможность многократно править текст посредством самой вики-среды (сайта), без применения особых приспособлений на стороне редактора. Особый язык разметки — так называемая вики-разметка, которая позволяет легко и быстро размечать в тексте структурные элементы и гиперссылки; форматировать и оформлять отдельные элементы. Учёт изменений (версий) страниц: возможность сравнения редакций и восстановления ранних. Проявление изменений сразу после их внесения. Разделение содержимого на именованные страницы. Гипертекст: связь страниц и подразделов сайта через контекстные гиперссылки. Множество авторов. Некоторые вики могут править все посетители сайта. Техническая основа Для создания вики-среды необходимо особое ПО — движок вики. Это частный вид систем управления сайтом, довольно простой в своём устройстве и функциональности, поскольку почти все действия по структурированию и обработке содержимого делаются пользователями вручную. Работа Википедии и других сайтов Фонда Викимедиа основана на движке MediaWiki. Особенности Язык вики поддерживает гиперссылки для создания ссылок между вики-страницами и является более наглядным, чем HTML, и более безопасным, поскольку использование JavaScript и каскадных таблиц стилей ограничено. Вандализм Многие вики позволяют изменять своё содержимое всем желающим, а не только зарегистрированным пользователям. Подобно тому, как стены зданий и заборы исписывают непристойными надписями и украшают рисунками граффити, в таких вики иногда портят содержимое или добавляют что-то неуместное. Но, в отличие от стен и заборов, в вики легко вернуть содержимое к ранней версии: исправлять легче, чем портить. Если же кто-либо настойчиво и намеренно стремится навредить пользователям вики-сайта, можно закрыть ему возможность вносить правки. См. также Семантическая вики .wiki — домен верхнего уровня, предназначенный специально для вики Примечания Ссылки WikiMatrix — сайт-энциклопедия о вики-движках Языки разметки