Администрирование почтовых и файловых серверов в Internet

Введение

2. Электронная почта в Internet

2.1. Принципы организации  
2.2. Протокол SMTP  
2.3. Протокол POP3 (Post Office Protocol)  
2.4. Формат почтового сообщения (RFC-822)  
2.5. Спецификация MIME (Multipurpose Internet Mail Extension)

3. Программное обеспечение почтового обмена

3.1. Программа Sendmail

3.1.1. Настройка программы sendmail  
3.1.2. Тестирование обслуживания по протоколу SMTP  
3.1.3. Тестирование по протоколу POP3  
3.1.4. Протокол IMAP  
3.1.5. Тестирование отправки почты программой Sendmail - флаг "-v"  
3.1.6. Тестирование правил преобразования адресов

 
3.2. Доступ к ресурсам Internet через электронную почту

3.2.1. Доступ к ресурсам архивов FTP  
3.2.2. Поиск ресурсов посредством Archie

4. Файловые архивы Internet

4.1. Протокол FTP (File Transfer Protocol)  
4.2. Режимы обмена данными  
4.3. Программное обеспечение доступа к FTP-архивам

4.3.1. Сервер протокола - программа ftpd  
4.3.2. Программа обмена файлами - ftp  
4.3.3. Поиск в FTP-архивах - программа Archie

Приложения

 Приложение 1. Команды протокола SMTP  
Приложение 2. Коды возврата SMTP  
 
 

Введение

В сознании большинства пользователей глобальной компьютерной сети Internet сама эта сеть ассоциируется с тремя основными  информационными технологиями:

• электронная почта (e-mail);
• файловые архивы FTP;
• World Wide Web.

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

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

Сеть Internet развивалась в первые свои годы как государственная. Это значит, что главным ее назначением был свободный обмен информацией. Доступность Internet из высших учебных заведений только способствовала этой тенденции. Если электронная почта - это основное средство коммуникаций, то основным способом обмена программным обеспечением и регламентными материалами в Internet стали FTP-архивы. Это только в последнее время Internet стала высокоскоростной информационной магистралью. Долгое время канал со скоростью 9600 бит/с был быстрым каналом связи. В этом легко убедиться, стоит только внимательно почитать файлы настройки терминалов в ОС Unix (termcap). Для работы по этим каналам связи и были разработаны такие протоколы как Telnet и FTP. Упоминание этих двух протоколов вместе здесь не случайно. Telnet и FTP - это отличный пример комплексного решения проблемы. Все управление (сеанс связи и выдача команд) происходит при обмене файлами по протоколу Telnet и только собственно обмен файлами использует специальный канал передачи данных, который определен в спецификации протокола FTP (File Transfer Protocol).

В настоящее  время назначение FTP-архивов существенно  расширилось. Несмотря на то, что на арену сетевого обмена выходят все  новые средства и технологии, вряд ли они смогут потеснить FTP-обмен  в рамках существующих стандартов TCP/IP. Если обратиться к хорошо известной  картинке распределения трафика  по информационным сервисам Internet (рисунок 1.1), то легко можно обнаружить, что  два протокола FTP и Prospero в совокупности довольно сильно превышают трафик HTTP.

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

Для того чтобы понять насколько эффективен FTP-обмен достаточно взглянуть еще  на один график (рисунок 1.2), на котором  представлено соотношение переданных по сети байтов и пакетов.

При обсуждении сравнения эффективности обмена следует принимать во внимание особенности  организации транспорта информации в сетях TCP/IP при использовании  транспортного протокола TCP (Transfer Control Protocol).

Рис. 1.2. Пакеты и байты

Если  не вдаваться в детали и не придерживаться терминологии сетей TCP/IP, то при обмене информацией по сети TCP/IP при транспорте TCP, перед тем как начать отправку сообщения, устанавливается виртуальный TCP-канал. Это означает, что сначала выполняется процедура организации этого канала или, как ее еще называют, трехфазный "хэндшейк" (handshake). При этой процедуре стороной, которая устанавливает соединение отправляется запрос на организацию канала, затем получается подтверждение на получение этого запроса, после этого отправляется подтверждение на получение подтверждения и первый пакет данных (рисунок 1.3).

Рис. 1.3. Процедура инициирования TCP-соединения

Аналогично  началу TCP-обмена устроена и процедура  разрыва виртуального TCP-канала. Также  посылается уведомление об окончании  соединения, получается подтверждение  и только после этого канал  разрывается.

Очевидно, что чем больше данных за один TCP-сеанс  будет передано, тем более эффективней (с точки зрения соотношения переданной полезной и служебной информации) будет обмен. В этом смысле FTP работает эффективно. В начале сессии организуется канал, который потом будет использоваться для всего обмена. Если сравнить теперь FTP и HTTP (основной протокол World Wide Web), то станет ясно, что ориентированный на разрыв соединения после передачи порции данных HTTP гораздо менее эффективен, чем FTP.

Это небольшое  отступление в область основ  технологии межсетевого обмена должно было продемонстрировать, что при  использовании той или иной технологии всегда следует помнить о том, как эта технология в конечном счете реализуется. Это важно, например, для выбора времени создания "зеркала" чужого FTP-архива. Если такое "зеркало" создавать в рабочее время в организации, где большое количество пользователей работает с информационными ресурсами Internet, то можно довольно сильно затормозить их работу. Особенно это актуально для организаций, которые работают по выделенным каналам связи с пропускной способностью 64Кб/с-128Кб/с и имеют в штате порядка сотни сотрудников, которые одновременно используют этот канал. Сервис FTP будет стремиться захватить канал целиком и это ему удастся сделать, т.к. HTTP будет использовать канал только в короткие промежутки времени.

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

Так, например, к FTP-архиву можно обратиться через  электронную почту или использовать Web-броузер для доступа к FTP-архиву. Все эти возможности предполагают использование программ-шлюзов. Если представить такое взаимодействие в виде схемы, то выглядеть это  будет так, как представлено на рисунке 1.4.

Рис. 1.4 Организация доступа  к ресурсу через программы-посредники

На принципе использования посредников в  настоящее время строится универсальная  система доступа к ресурсам Internet из World Wide Web. Чем более широко внедряется Web на рабочие столы пользователей, тем меньше вероятность того, что  им придется изучать технологии типа Telnet или FTP. Но это не означает, что  эти технологии исчезли из сети. Администраторы узлов Web все равно обязаны знать, как все это спрятанное от пользователей "хозяйство" функционирует.

2. Электронная почта в Internet

Электронная почта - один из важнейших информационных ресурсов Internet. Она является самым  массовым средством электронных  коммуникаций. Любой из пользователей Internet имеет свой почтовый ящик в  сети. Если учесть, что через Internet можно  принять или послать сообщения  еще в два десятка международных  компьютерных сетей, некоторые из которых  не имеют on-line сервиса вовсе, то становится понятным, что почта предоставляет  возможности в некотором смысле даже более широкие, чем просто информационный сервис Internet. Через почту можно  получить доступ к информационным ресурсам других сетей. Хорошим примером может служить доступ к архивам сети BITNET - документам и телеконференциям, которые ведутся на серверах списков (LISTSERVER) BITNET.

2.1. Принципы организации

Электронная почта во многом похожа на обычную  почтовую службу. Корреспонденция подготавливается пользователем на своем рабочем  месте либо программой подготовки почты, либо просто обычным текстовым редактором. Обычно программа подготовки почты  вызывает текстовый редактор, который  пользователь предпочитает всем остальным  программам этого типа. Затем пользователь должен вызвать программу отправки почты (программа подготовки почты  вызывает программу отправки автоматически). Стандартной программой отправки является программа sendmail. Sendmail работает как почтовый курьер, который доставляет обычную почту в отделение связи для дальнейшей рассылки. В Unix-системах программа sendmail сама является отделением связи. Она сортирует почту и рассылает ее адресатам. Для пользователей персональных компьютеров, имеющих почтовые ящики на своих машинах и работающих с почтовыми серверами через коммутируемые телефонные линии, могут потребоваться дополнительные действия. Так, например, пользователи почтовой службы Relcom должны запускать программу UUPC, которая осуществляет доставку почты на почтовый сервер.

Для работы электронной почты в Internet разработан специальный протокол Simple Mail Transfer Protocol (SMTP), который является протоколом прикладного уровня и использует транспортный протокол TCP. Однако, совместно с этим протоколом используется и Unix-Unix-CoPy (UUCP) протокол. UUCP хорошо подходит для использования телефонных линий связи. Большинство пользователей электронной почты Relcom реально пользуются для доставки почты на узел именно этим протоколом. Разница между SMTP и UUCP заключается в том, что при использовании первого протокола sendmail пытается найти машину-получателя почты и установить с ней взаимодействие в режиме on-line для того, чтобы передать почту в ее почтовый ящик. В случае использования SMTP почта достигает почтового ящика получателя за считанные минуты и время получения сообщения зависит только от того, как часто получатель просматривает свой почтовый ящик. При использовании UUCP почта передается по принципу "stop-go", т.е. почтовое сообщение передается по цепочке почтовых серверов от одной машины к другой пока не достигнет машины-получателя или не будет отвергнуто по причине отсутствия абонента-получателя. С одной стороны, UUCP позволяет доставлять почту по плохим телефонным каналам, т.к. не требуется поддерживать линию все время доставки от отправителя к получателю, а с другой стороны, бывает обидно получить возврат сообщения через сутки после его отправки из-за того, что допущена ошибка в имени пользователя. В целом же общие рекомендации таковы: если имеется возможность надежно работать в режиме on-line и это является нормой, то следует настраивать почту для работы по протоколу SMTP, если линии связи плохие или on-line используется чрезвычайно редко, то лучше использовать UUCP.

Рис. 2.1. Структура взаимодействия участников почтового  обмена

Основой любой почтовой службы является система  адресов. Без точного адреса невозможно доставить почту адресату. В Internet принята система адресов, которая  базируется на доменном адресе машины, подключенной к сети. Например, для  пользователя paul машины с адресом polyn.net.kiae.su почтовый адрес будет выглядеть как:

      [email protected].

Таким образом, адрес состоит из двух частей: идентификатора пользователя, который  записывается перед знаком "коммерческого  эй" - "@", и доменного адреса машины, который записывается после знака "@". Адрес UUCP был бы записан как строка вида:

      net.kiae.su!polyn!paul

Программа рассылки почты Sendmail сама преобразует  адреса формата Internet в адреса формата UUCP, если доставка сообщения осуществляется по этому протоколу.

2.2. Протокол SMTP

Simple Mail Transfer Protocol был разработан для обмена почтовыми сообщениями в сети Internet. SMTP не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и Х.25. Достигается это за счет концепции IPCE (InterProcess Communication Environment). IPCE позволяет взаимодействовать процессам, поддерживающим SMTP в интерактивном режиме, а не в режиме "STOP-GO".

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

Рис. 2.2. Схема взаимодействия по протоколу SMTP

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

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

Наиболее  распространенной дисциплиной является отправка почтового сообщения, которая  начинается по команде MAIL, идентифицирующей отправителя:

      MAIL FROM: [email protected]

Следующей командой определяется адрес получателя:

      RCPT TO: [email protected]

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

      DATA

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

      S: MAIL FROM: <[email protected]>

      R: 250 Ok

      S: RCPT TO: <[email protected]>

      R: 250 Ok

      S: DATA

      R: 354 Start mail input; end with <CRLF>.<CRLF>

      S: Это текст почтового  сообщения

      S: .

      R: 250

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

      R: 251 User not local;

      will forward to <[email protected]>

Если  сервер может сделать только предположение  о дальнейшей рассылке, то ответ  будет несколько иным:

      R: 551 User not local;

      please try <[email protected]>

Верификация и расширение адресов составляют дисциплину верификации. В ней используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие или отсутствие указанного пользователя:

      S: VRFY paul

      R: 250-Paul Khramtsov<[email protected].kiae.su>

Используя команду EXPN можно получить список местных  пользователей:

      S: EXPN Example-People

      R: 250-Paul Khramtsov<[email protected].kiae.su>

      R: 250-Vladimir Drach-Gorkunov<vovka@quest.polyn.kiae.su>

В список дисциплин, разрешенных протоколом SMTP входит кроме отправки почты еще и прямая рассылка сообщений. В этом случае сообщение будет отправляться не в почтовый ящик, а непосредственно на терминал пользователя, если пользователь в данный момент находится за своим терминалом. Прямая рассылка осуществляется по команде SEND, которая имеет такой же синтаксис, как и команда MAIL. Кроме SEND прямую рассылку осуществляют SOML (Send or Mail) и SAML (Send and Mail). Назначение этих команд легко понять из их названия.

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

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

Если  сообщение по какой-либо причине  не может быть разослано, то получатель формирует сообщение о неразосланном  сообщении:

      S: MAIL FROM:<>

      R:  250 Ok

      S: RCPT TO: <@host.domain:[email protected]>

      R: 250 Ok

      S: DATA

      R: 354 send the mail data, end with .

      S: Date 23 Oct 95 11:23:30

      S: From: [email protected]

      S: To: <[email protected]>

      S:

      S: Undelivered message. Your message lost. 550 No such user.

      S: .

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

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

Для отладки  или проверки соединения по SMTP можно  использовать telnet. Для этого вслед  за адресом машины следует ввести номер порта:

      /users/local>telnet

      apollo.polyn.kiae.su 25

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

2.3. Протокол POP3 (Post Office Protocol)

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

2.4. Формат почтового  сообщения (RFC-822)

При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его  подробнее. Формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или To, например:

      Date: 26 Aug 76 1429 EDT

      From: [email protected]

      cc:

или

      Date: 26 Aug 76 1429 EDT

      From: [email protected]

      To: [email protected]

Поле  Date определяет дату отправки сообщения, поле From - отправителя, а поля сс и To - получателя(ей). Чаще заголовок содержит дополнительные поля:

      Date: 26 Aug 76 1429 EDT

      From: George Jones<[email protected]>

      Sender: Secy@SHOST

      To:  [email protected]

      Message-ID: <4231.629.XYzi-What@Registry.org>

В данном случае поле Sender указывает, что George Jones не является автором сообщения. Он только переслал сообщение, которое получил из Secy@SHOST. Поле Message-ID содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка:

      Date:  27 Aug 76 0932

      From:  Ken Davis <[email protected]>

      Subject:  Re: The Syntax in the RFC

      Sender:  KSecy@Other-host

      Reply-To:  Sam.Irving@Reg.Organization

      To:   George Jones <[email protected]>

      cc:   Important folks:

                        Tom Softwood <[email protected]>,

                        "Sam Irving"@Other-Host;,

                        Standard Distribution:

                        /main/davis/people/standard@Other-Host

      Comment:  Sam is away on bisiness.

      In-Reply-To: <some.[email protected]>, George`s message

      X-Special-action: This is a sample of user-defined field- 

                        names.

      Message-ID: <4331.629.XYzi-What@Other-Host

Поле  Subject определяет тему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение относится к типу "В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее ...", X-Special-action - поле, определенное пользователем, которое не определено в стандарте.

Следует сказать, что формат сообщения постоянно  дополняется и совершенствуется. В RFC-1327 введены дополнительные поля для совместимости с почтой X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто  встречающихся заголовков, которые  не регламентированы в RFC-822. Так первое предложение заголовка, которое  начинается со слова From, содержит UUCP-путь сообщения, по которому можно определить, через какие машины сообщение "пробиралось". Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты.

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

2.5. Спецификация MIME (Multipurpose Internet Mail Extension)

Стандарт MIME, или в нотации Internet RFC-1341, предназначен для описания тела почтового сообщения Internet. Предшественником MIME является стандарт почтового сообщения ARPA (RFC822). Стандарт RFC822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети невозможно передать по почте без специальных ухищрений. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать в семибитовой кодировке ASCII. Естественно, что при использовании RFC822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400, который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть по-различному проинтерпретированы в X.400 и программе рассылки почты в Internet (mail-agent).

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

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

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

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