SMTP реализуется в современных сетях стандарта TCP/IP. Впервые информация об использовании протокола появилась еще в 1982 г. Несмотря на то, что сервер SMTP может быть использован и для получения сообщений, на сегодняшний день большинство почтовых клиентов используют его только для отправки, предпочитая другие технологии (например, POP или IMAP) для приема информации. Протокол является одним из наиболее популярных и используется подавляющим числом почтовых программ и серверов.
Функция SMTP заключается в проверке правильности указания настроек и параметров для отправки письма. По данному протоколу проходит верификация настроек компьютера пользователя, пытающегося отправить сообщения, а затем производится доставка, если все настройки были выполнены правильно. После этого работа SMTP не заканчивается и сервер дожидается сообщения об успешной доставке данных. Если сообщение по каким-то причинам не может быть доставлено, отправляется соответствующее сообщение отправителю.
Настройка SMTP
Настройка SMTP заключается в установке нужного программного обеспечения и определения адреса сервера, используемого для отправки. Для отправки со стороны пользователя требуется установить программу-клиент, которая умеет передавать письма и связываться с сервером SMTP по протоколу TCP/IP. После этого программа запускается и настраивается на работу с сервисом отправки и получения почты путем указания нужных настроек. Затем пользователь пытается отправить сообщение. Если настройка осуществлена верно, письмо будет доставлено адресату.
Большинство современных сервисов электронной почты уже имеют настроенные серверы для отправки сообщений. Если вы не пользуетесь сторонним программным обеспечением для отправки писем, вы сможете отправить письмо без произведения дополнительных настроек на сайте сервиса, где у вас зарегистрирован аккаунт.
Современные администраторы SMTP-серверов требуют от пользователей прохождения аутентификации перед тем, как они смогут отправить свое сообщение. Пользователю необходимо сначала указать свой логин и пароль на сервере, а лишь затем перейти к отправке. Данная защита используется для блокирования возможности рассылки спама, использующего простые SMTP-протоколы. Ранее же для идентификации в протоколе SMTP использовался уникальный IP-адрес отправителя.
SMTP (Simple Message Transfer Protocol), или в дословном переводе простой протокол передачи сообщений, был рожден в среде UNIX и предназначался исключительно для общения между собой почтовых серверов. В терминах модели OSI протокол SMTP находится на уровне приложений.
В настоящее время SMTP стал стандартом де-факто. В большой степени такая популярность объясняется сравнительной простотой реализации и широкими возможностями расширяемости без ущерба для обратной совместимости с существующими версиями почтовых систем. Немаловажным фактором является также широкая доступность спецификаций и отсутствие необходимости отчислять средства за их использование.
SMTP-системы за последнее время активно развивались в следующих направлениях:
расширение протокола общения сервер-сервер (собственно SMTP);
создание и улучшение протокола общения клиент-сервер (POP3, IMAP4);
внедрение и расширение нового формата сообщений (MIME).
Начальная версия протокола SMTP поддерживала ограниченный набор команд и сервисов для приема и передачи сообщений. В последнее время был разработан его расширенный вариант (Extended или ESMTP), обеспечивающий стандартную возможность дальнейшего расширения и поддержку таких функций как подтверждение доставки (Delivery Notification Request или DNR), согласование максимального допустимого размера сообщений, передаваемых между серверами и принудительная инициация передачи накопленной почты (dequeue). Однако одной из слабых сторон на данный момент SMTP было и продолжает быть отсутствие возможности аутентификации входящих соединений, шифрования диалога и потока передачи данных между серверами.
Отсутствие средств аутентификации входящих соединений не позволило использовать SMTP для обслуживания клиентского доступа. Классическая почтовая SMTP-система требует наличия файлового доступа клиента к своему почтовому ящику для получения и работы с сообщениями. Для реализации работы в режиме клиент-сервер был создан протокол обслуживания почтового офиса (Post Office Protocol или POP). Наиболее удачной оказалась версия POP3, широко используемая в современных SMTP-системах. Наиболее продвинутые реализации поддерживают аутентификацию с шифрованием имени и пароля и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако, при использовании протокола POP3 отсутствует возможность просмотра характеристик сообщения без предварительной загрузки его на станцию клиента. Для решения проблемы просмотра и манипуляции свойствами почтового сообщения непосредственно на сервере, а также преодоления ряда других функциональных ограничений был разработан протокол IMAP4, его поддержка в большинстве коммерческих систем ожидается в ближайшем будущем. Следует заметить, что как для случая использования классического клиента (команда mail), так и для случая применения POP3 или IMAP4 отправка подготовленных клиентом сообщений требует наличия сервера SMTP. На рисунке 1.6 приведена схема представления типичной SMTP-системы, использующей как традиционный для ОС UNIX файловый метод доступа к почтовому ящику, так и доступ по протоколам POP3 и IMAP4.
Изначально SMTP-системы рассчитывались на передачу информации исключительно в текстовом виде и не были ориентированы на передачу символов национальных алфавитов, т.е. использовали 7-битный набор символов. Для решения проблемы передачи двоичных файлов был разработан стандарт UUENCODE, позволяющий внедрять предварительно преобразованные из бинарного в текстовый вид произвольные данные непосредственно в текст сообщения. Однако всеобъемлющим данный подход назвать было трудно, ибо в общем случае никакой информации о природе вложения (типе передаваемых данных и породившем их приложении) принимающая сторона не имела. По мере расширения сети Internet, усложнения программного обеспечения и активного внедрения мультимедиа назрела необходимость создания универсального формата типизации и представления двоичных данных и текста, содержащего национальные символы. Таким универсальным форматом стали многофункциональные расширения почты Internet (Multipurpose Internet Mail Extensions или MIME). Формат MIME оказался чрезвычайно удачным, поскольку в него были заложены возможности неограниченного расширения, как поддерживаемых типов данных, так и национальных кодировок.
Схема типичной SMTP-системы с поддержкой POP3 и IMAP4
Сообщение SMTP, подобно сообщению X.400, использует понятия конверта и содержимого, которое в свою очередь имеет заголовок и тело. Функциональное назначение их полностью идентично. Состав полей в заголовке определяется форматом тела сообщения (UUENCODE или MIME). Ни одно поле не является обязательным, но, как правило, указываются такие поля как, кому (To:), от кого (From:) и тема (Subject:). В случае использования формата MIME, в заголовке обязательно должна присутствовать строка "MIME-Version: 1.0". Полный перечень возможных полей в заголовке сообщения SMTP содержится в RFC 2076.
Отличительной особенностью SMTP-систем является то, что в них, как правило, обеспечивается фактическая независимость процесса передачи от формата содержимого. За интерпретацию содержимого должна отвечать только клиентская программа (mail reader). Однако платой за совместимость на уровне MTA в данном случае является неэффективность передачи любых нетекстовых данных или сообщений, использующих символы национальных алфавитов, вследствие предварительной трансляции информации в текстовое представление. В зависимости от используемого алгоритма преобразования размер фактически передаваемых данных может возрасти на 30-100%.
Немаловажной проблемой при передаче данных через SMTP-системы является обеспечение конфиденциальности. Поскольку сообщения передаются в текстовом виде, они могут быть легко перехвачены и произвольным образом изменены. Для решения проблем с защитой информации был создан стандарт на шифрование тела сообщения, так называемый засекреченные многофункциональные расширения почты (Secure MIME или S/MIME). Однако, этот протокол не в состоянии защитить от перехвата заголовки сообщений.
Simple Mail Transfer Protocol не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и Х.25. Достигается это за счет концепции IPCE (InterProcess Communication Environment). IPCE позволяет взаимодействовать процессам, поддерживающим SMTP в интерактивном режиме, а не в режиме "STOP-GO".
Модель протокола. Взаимодействие в рамках SMTP строится по принципу двусторонней связи, которая устанавливается между отправителем и получателем почтового сообщения. При этом отправитель инициирует соединение и посылает запросы на обслуживание, а получатель на эти запросы отвечает. Фактически, отправитель выступает в роли клиента, а получатель - сервера.
Схема взаимодействия по протоколу SMTP
Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течение нескольких секунд после отправки.
Протокол SMTP
O В этой главе:
O Основные команды протокола
O Серверы-ретрансляторы
O Непосредственная пересылка
Для доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol ).
При его создании протокола SMTP разработчиками была допущена грубая ошибка, испортившая немало крови, как системным администраторам, так и простым пользователям. Суть ее заключается в том, что протокол SMTP не требует аутентификации пользователя перед отправкой сообщения, и это позволяет использовать чужие сервера для массовой рассылки.
Современные SMTP-сервера используют различные защитные механизмы, препятствующие отправке корреспонденции неизвестными пользователями. Подробно об этом рассказывается в главе «Почтовый сервер изнутри».
В терминологии SMTP-протокола нет таких понятий как «клиент» и «сервер». Вместо этого говорят об отправителе (sender ) и получателе (receiver ). То, что большинство называют «SMTP-сервером», является одновременно и отправителем, и получателем. Когда клиент устанавливает с ним соединение для передачи письма, сервер выступает в роли получателя, а когда доставляет сообщение абоненту, становится отправителем.
Каждый почтовый ящик представляет собой SMTP-получатель, связавшись с которым напрямую, можно передать сообщение без посредников. Однако такой способ не обрел большой популярности. Связь с далекими узлами может быть медленной и ненадежной, поэтому миссию доставки сообщения удобно возложить на специальный сервер, часто называемый сервером исходящей почты. Если связь с сервером исходящей почты быстрая и надежная, то такой подход вполне оправдан. Напротив, рассылать письма через далекие, тормозные и нестабильно работающее сервера не имеет никакого смыла. В таком случае лучше положить сообщение непосредственно в ящик получателя. Однако немногие почтовые клиенты поддерживают такую возможность.
Приведенный ниже пример демонстрирует, как посредством протокола SMTP отправить абоненту сообщение. Первым шагом необходимо запустить telnet-клиента и, установив соединение с выбранным SMTP-сервером (например, mail.aport.ru) по двадцать пятому порту, дождаться выдачи приглашения.
Рисунок 009 Подключение к серверу mail.aport.ru
Первые три символа возвращенной сервером строки представляют собой код завершения операции. Полный перечень кодов всевозможных ошибок содержится в RFC-821, и здесь не приводится.
Для передачи корреспонденции одного лишь TCP-соединения не достаточно, и необходимо установить еще одно, так называемое SMTP-соединение. Это достигается возвращением ответного приветствия серверу с указанием имени узла клиента (если у него есть имя) или IP-адреса (если у клиента нет имени).
Далеко не всегда требуется указывать свой точный адрес. Часто достаточно ввести произвольную текстовую строку, например “ABDCEF”
· HELO ppp-15.krintel.ru
Ответное приветствие осуществляется командой “HELO
”. Сервер, установив SMTP-соединение, возвращает код успешного завершения операции (250) и в большинстве случаев определяет IP-адрес клиента или его доменное имя.
Следующим шагом требуется указать отправителя сообщения. Для этого необходимо воспользоваться командой «MAIL FROM» с указанием собственного почтового адреса при желании заключенного в угловые скобки.
Например:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
Затем указывается получатель сообщения, передаваемый с помощью команды “RCPT TO”, пример использования которой продемонстрирован ниже:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» is syntactically correct
· RCPT TO:«[email protected]»
При возникновении потребности в отправке одного и того же сообщения нескольким респондентам, достаточно вызвать “RCPT TO” еще один (или более) раз (максимальное количество получателей обычно не ограничено). Если кому-то из них сервер не возьмется доставить сообщение, он вернет ошибку, никак, однако не сказывающуюся на остальных получателях.
Команда “DATA”, вызываемая без аргументов, переводит сервер в ожидание получения текста письма.
· 354 Enter message, ending with "." on a line by itself
Последовательность завершения ввода представляет собой обыкновенную точку, «окаймленную» с двух сторон переносами строк. Если такая последовательность встретится в тексте сообщения, формирование письма будет немедленно завершено. Почтовые клиенты, обычно распознают такую ситуацию и прибегают к перекодировке, но при работе с telnet-клиентом эта забота ложиться на пользователя.
Пример использования команды “DATA” приведен ниже:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» is syntactically correct
· RCPT TO:«[email protected]»
· 250 «[email protected]» verified
· Hello, Sailor!
· 250 OK id=12ZDEd-000Eks-00
Команда “QUIT” завершает сеанс и закрывает соединение.
· 221 camel.mail.ru closing connection
Содержимое полученного сообщения (механизм получения сообщений на локальный компьютер пользователя рассмотрен в главах «Протокол POP» и «Протокол IMAP4») может выглядеть, например, следующим образом:
· From [email protected] Sun Mar 26 17:38:03 2000
· Received: from ppp-15.krintel.ru ()
· by camel.mail.ru with smtp (Exim 3.02 #107)
· id 12ZDEd-000Eks-00
· Message-Id: «[email protected]»
· From: [email protected]
· Hello,Sailor!
Ниже будет показано, каким образом злоумышленники находят и используют чужие сервера исходящей почты. Один из способов поиска общедоступных SMTP-серверов заключается в анализе заголовков приходящей корреспонденции. Среди узлов, оставивших свои адреса в поле “Received”, порой встречаются сервера, которые не требуют аутентификации пользователя для отправки писем.
Например, ниже показан заголовок письма, вытащенного автором этой книги из его собственного почтового ящика:
· From [email protected] Wed Mar 22 16:57:03 2000
· Received: from gate.chiti.uch.net ()
· by msk2.mail.ru with esmtp (Exim 3.02 #116)
· id 12Xld1-0008jx-00
· Received: from 13.chiti.uch.net ()
· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id PAA29678
· From: "irt" «[email protected] »
Анализ заголовка позволяет установить, что письмо было отправлено с адреса 13.chiti.uch.net через сервер исходящей почты gate.chiti.uch.net. Если попробовать установить с ним соединение, то результат может выглядеть так:
Для проверки возможности пересылки сообщения необходимо послать серверу приглашение, а затем идентифицировать отправителя и получателя письма. Например, это может выглядеть так:
· HELO kpnc.krintel.ru
· 250 gate.chiti.uch.net Hello kpnc.krintel.ru , pleased to meet you
· MAIL FROM:«[email protected]»
· 250 «[email protected]»… Sender ok
· RCPT TO:«[email protected]»
· 250 «[email protected]»… Recipient ok
Код успешного завершения операции (250) и срока «Recipient ok» свидетельствуют о том, что сервер согласился на пересылку. Остается ввести текст послания и можно отправлять письмо. Спустя какое-то время (обычно не превышающее одной минуты) сообщение должно прийти по назначению. А его заголовок может выглядеть, например, так:
· From [email protected] Sun Mar 26 17:28:33 2000
· Received: from gate.chiti.uch.net ()
· by camel.mail.ru with esmtp (Exim 3.02 #107)
· id 12ZD5a-000Dhm-00
· Received: from kpnc.krintel.ru (kpnc.krintel.ru )
· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id QAA02468
· (envelope-from [email protected])
· From: [email protected]
· Message-Id: «[email protected]»
Жирным шрифтом выделен адрес отправителя, показывая, что он не смог остаться анонимным. Если это оказывается неприемлемо, среди входящих писем своего почтового ящика можно попробовать отыскать такие, в чьих заголовках нет никаких сведений об отправителе, за исключением той информации, которую он пожелал сообщить сам.
Один из анонимных серверов расположен (точнее, был когда-то расположен на момент написания этой главы) по адресу dore.on.ru. Однако его использование посторонними лицами запрещено, что и демонстрирует следующий эксперимент:
· HELO kpnc.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» Sender Ok
· RCPT TO:«[email protected]»
· 550 Relaying denied for «[email protected]»
Сервер, действительно, не делает никаких видимых попыток определить адрес клиента, но в то же время пересылать его корреспонденцию за пределы сервера наотрез отказывается. Причем достоверно известно, что владельцы этого сервера используют его для рассылки сообщений по нелокальным адресам. Отсюда вытекает существование механизма, позволяющего отличить «своих» от «чужих». Права «чужих» ограничиваются доставкой писем по локальным адресам, а «своим» разрешается отправлять сообщения и за пределы сервера. Ввиду отсутствия в протоколе SMTP средств аутентификации пользователей, отличить одних от других помогает IP адрес клиента. Локальные пользователи, находящиеся в одной подсети с сервером, считаются «своими», и наоборот .
Но если сервер не снабжен функцией определения IP адреса клиентов, ему не остается ничего другого, кроме как воспользоваться информацией, предоставленной самим отправителем, поверив тому на слово. Поэтому, существует возможность сообщения подложных данных, и, выдачи себя за локального пользователя, имеющего право отправки сообщений по любому адресу.
Клиент дважды указывает свой адрес: приветствуя сервер, командой “HELO” он сообщает свой домен, а в поле “MAIL FROM” приводит собственный обратный адрес. Некоторые сервера проверяют одно из этих значений, а некоторые оба одновременно.
В эксперименте, приведенном ниже, отправитель сообщает не свой собственный домен, а домен владельца сервера, и в качестве обратного адреса, использует один из адресов локальных пользователей сервера (чтобы его узнать, необходимо получить с этого сервера хотя бы одно письмо, или попробовать выяснить имена зарегистрированных пользователей методом перебора):
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· MAIL FROM:«[email protected]»
· RCPT TO:«[email protected]»
· 250 Recipient Ok
В результате такого подлога, сервер оказался введен в заблуждение и согласился доставить письмо. Очевидно, подлинный отправитель сообщения не может быть установлен по заголовку, поскольку в нем находится только та информация, которую отправитель пожелал оставить самостоятельно.
Для массовой рассылки лучшего способа и придумать невозможно, но вот для обычной переписки такая методика не подходит. Ведь ответ на письмо возвратится по адресу [email protected]! Этого можно избежать, если добавить в заголовок поле “Reply-To”, содержащее истинный адрес отправителя (тот, который он захотел оставить сам). Это может выглядеть, например, таким образом:
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» Sender Ok
· RCPT TO:«[email protected]»
· 250 Recipient Ok
· 354 Start mail input; end with «CRLF».«CRLF»
· Reply-To:«[email protected]»
· 250 Ok Message queued
· 221 dore.on.ru Service closing transmission channel
Заголовок такого письма должен выглядеть приблизительно так:
· Received: from relay1.aha.ru ( verified)
· by aha.ru (CommuniGate Pro SMTP 3.1b2)
· Received: from warlock.miem.edu.ru (miem-as.ins.ru )
· by relay1.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id UAA07173
· Received: from dore.miem.edu.ru (rtuis.miem.edu.ru )
· by warlock.miem.edu.ru (8.9.3/8.9.3) with ESMTP id UAA00637
· Received: from fox by dore.on.ru (FTGate 2, 1, 2, 1);
· Message-ID: «000301bec6ff$c87f5220$16fe7dc1@fox»
· From: «[email protected]»
· To: «[email protected]»
· Subject: TEST
· Reply-To:«[email protected]»
При попытке ответить отправителю, почтовый клиент получателя извлечет содержимое поля “Reply-To” и отправит письмо по указанному в нем адресу. Именно этим и пользуются спамеры для достижения полной анонимности с одной стороны, и возможности получения ответов от заинтересованных лиц - с другой.
Если внимательно посмотреть на заголовок письма, в нем можно обнаружить несколько строк “Received”. Их оставили транзитные сервера, иначе называемые Релеями (от английского relay ).
Любой почтовый клиент может отправить письмо напрямую. Однако для этого придется собственноручно указать в настойках сервера исходящей почты адрес получателя.
Например, чтобы отправить письмо для [email protected] с помощью “OutLock Express” придется зайти в «Учетные записи» (меню «Сервис»), выбрать «Свойства» и перейти к закладке «Серверы», задав для исходящей почты сервер «computerra.ru».
Очевидно, это слишком утомительно и непрактично. До тех пор, пока программное обеспечение не научиться выполнять такую операцию автоматически, пользователи будут вынуждены пользоваться прежними методами.
Работа типичного мелкокорпоративного сервера исходящей почты выглядит приблизительно так: получив в свое распоряжение письмо, он тут же устанавливает соединение с почтовым ящиком получателя, и отправляет послание. При этом он сталкивается с теми же затруднениями, что и обычный клиент. Поэтому, широко используется ретрансляция сообщений. Если письмо по каким-то причинам не может быть передано напрямую, оно передается ретранслятору.
Ретранслятор - точно такой же SMTP-сервер, как и все остальные, обсуждаемые в этой главе. В зависимости от настоек сервера маршрут пересылки письма может варьироваться. Одно сообщение может отправляться напрямую, а другое - долго «крутиться» на Релеях. Доверие это прекрасно, но только когда не касается вопросов безопасности. Кто рискнет доверять ретрансляторам неизвестного происхождения? Тем более, дальнейший маршрут письма каждым из транзитных серверов определяется самостоятельно, и нет никаких гарантий, что в эту цепочку не вклиниться злоумышленник.
Но протокол SMTP позволяет отправителю самостоятельно задавать маршрут пересылки сообщения Параметр команды “RCPT TO” может содержать не только адрес получателя, но и путь ретрансляции!
Формат его следующий:
· RCPT TO:«@s1,@s2,@s3,@sn:name@host»
где s1,s2,s3,sn - имена (или IP адреса) промежуточных хвостов, а name@host почтовый ящик получателя. В первую очередь сообщение передается узлу s1 - самому левому серверу в цепочке. Он модифицирует параметр команды RCPT TO, «выкусывая» из нее имя своего узла:
· RCPT TO:«@s2,@s3,@sn:name@host»
Затем, извлекается адрес следующего получателя - s2. Если сервер s1 не берется за доставку корреспонденции серверу s2, письмо возвращается назад отправителю с сообщением об ошибке. В противном случае процесс повторяется до тех пор, пока сообщение не окажется в почтовом ящике получателя.
Недостаток такой схемы заключается в том, что некоторые SMTP сервера для пересылки на очередной хвост могут прибегать к услугам своих собственных ретрансляторов. Таким образом, гарантируется, что письмо при успешной доставке посетит все заданные узлы в указанном порядке. Но не всегда выполняется прямая пересылка между соседними хвостами в цепочке.
Поэтому, задача подбора транзитных серверов осложняется. Каждый из них должен быть не только защищен от посторонних вторжений, но заведомо не пользоваться услугами сторонних ретрансляторов.
К сожалению, большинство почтовых клиентов, проверяя корректность ввода адреса получателя, считают такую операцию синтаксически неправильной и отказываются отправлять письмо. Приходится в очередной раз запускать telnet и передавать сообщение вручную.
Узнать какие именно команды поддерживаются конкретным SMTP сервером можно с помощью «HELP», а подробнее о назначении каждой из них “HELP command”.
Для получения детальной информации о командах протокола SMTP можно обратиться к RFC-788, RFC-821, RFC-822, RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049, RFC-2076.
Из книги Техника сетевых атак автора Касперски КрисПротокол SMTP O В этой главе:O Основные команды протоколаO Серверы-ретрансляторыO Непосредственная пересылкаO Автоматизация почтовой рассылки и спамO Анонимная рассылка писемДля доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol).При его
автора Реймонд Эрик Стивен5.3.1. Учебный пример: SMTP, простой протокол передачи почты В примере 5.7. иллюстрируется транзакция SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты), который описан в спецификации RFC 2821. В данном примере строки, начинающиеся с С:, отправляются почтовым транспортным
Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен5.3.1. Учебный пример: SMTP, простой протокол передачи почты В примере 5.7. иллюстрируется транзакция SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты), который описан в спецификации RFC 2821. В данном примере строки, начинающиеся с C:, отправляются почтовым транспортным
Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М5.24 Протокол ARP Перед тем как датаграмма будет передана с одной системы локальной сети на другую, она будет обрамлена заголовком и завершающей частью кадра. Кадр доставляется на сетевой адаптер, физический адрес которого совпадает с физическим адресом назначения из
Из книги Программирование на языке Ruby [Идеология языка, теория и практика применения] автора Фултон Хэл8.9 Протокол RIP Наиболее широко используемым протоколом IGP является RIP, заимствованный из протокола маршрутизации сетевой системы компании Xerox (Xerox Network System - XNS). Популярность RIP основана на его простоте и доступности.RIP был первоначально реализован в TCP/IP операционной
Из книги Сетевые средства Linux автора Смит Родерик В.8.17 Протокол BGP В Интернете широко используется протокол граничного шлюза (Border Gateway Protocol - BGP). Текущей версией протокола является BGP-4.В современном Интернете существует множество провайдеров, объединенных между собой на манер сети межсоединений. При движении к точке
Из книги автора14.6 Протокол FTP С протоколом FTP связаны следующие понятия:? Команды и их параметры, пересылаемые по управляющему соединению? Числовые коды, возвращенные в ответ на команду? Формат пересылаемых данныхНиже рассмотрен набор команд FTP. Они передаются по управляющему
Из книги автора15.17 Протокол NFS Последней реализацией NFS является версия 3, хотя продолжают успешно применяться реализации версии 2. Программа NFS сервера имеет номер 100003 и, по соглашению, NFS захватывает при инициализации порт
Из книги автора16.9 Команды SMTP Сценарий из раздела 16.6.1 содержал наиболее часто используемые команды SMTP. Полный набор команд SMTP представлен в таблице 16.1.Таблица 16.1 Команды SMTP Команда Описание HELO Идентифицирует отправителя для получателя. MAIL FROM Начало почтовой транзакции и указание на
Из книги автора16.12.2 Диалог в улучшенной версии SMTP Показанный ниже пример демонстрирует, как улучшенный агент пересылки почты формирует транзакцию для отправки сообщения MIME в 8-битном формате:? Получатель объявляет о своих улучшенных возможностях, включая 8BITMIME.? Команда MAIL FROM имеет
Программы, реализующие сервер SMTP в системе Linux sendmail. В составе системы Linux часто поставляется наиболее популярный в настоящее время почтовый сервер sendmail. Этот пакет предоставляет обширные возможности и многие программы по умолчанию считают, что он установлен в
Из книги автора Из книги автораСпециальные функции сервера SMTP В последующих разделах описываются различные характеристики почтового сервера, которые задаются при его настройке. Чтобы не описывать эти характеристики для каждого сервера, рассмотрим их
