Доступ к ресурсам архивов FTP
Файловые архивы - это библиотеки, содержащие различную информацию - от программ до картинок, музыки, фильмов и просто текстовых файлов. Доступ к этим архивам осуществляется специальной программой FTP (File Transfer Programm), которая обращается к специальному серверу, управляющему файловым архивом на удаленной машине. Из названия программы уже понятно, что вся информация хранится в виде файлов, которые организованы в директории. Вообще говоря, FTP-архив - это часть файловой системы, которая доступна для удаленного пользователя FTP-сервера. Важным свойством многих FTP-архивов является возможность так называемого анонимного доступа. Рассмотрим доступ к FTP-архиву на примере робота decwr1.dec.com.
Для того, чтобы получить доступ к архиву следует отправить сообщение по адресу:
mail ftpmail@decwr1.dec.com
Поле Subject можно оставить пустым, а в теле сообщения следует ввести команды. Для доступа к архиву oak.oakland.edu
и получения его оглавления следует отправить следующее сообщение:
mail ftpmail@decwr1.dec.com Subject: connect oak.oakland.edu anonymous user@domail.net ls quit
По команде connect робот попытается установить анонимное соединение с FTP-сервером oak.oakland.edu. В качестве пароля (четвертый аргумент команды connect) следует указать свой почтовый адрес. По команде ls будет получен список файлов корневой директории сервера, а по команде quit робот прервет работу с сервером и вернет результаты пользователю. Важным моментом, ради которого собственно и осуществляется доступ к FTP-серверу, является запрос на передачу файлов. Предавать можно как текстовые, так и двоичные файлы. Для управления типом запрашиваемого файла существует две команды - ascii и binary. Для того, чтобы получить ASCII-файл, следует послать сообщение типа:
mail ftpmail@decwr1.dec.com Subject: connect oak.oakland.edu anonymous user@domail.net ascii get README quit
Команда get позволяет заказать файл README. Для получения двоичного файла следует послать сообщение типа:
mail ftpmail@decwr1.dec.com Subject: connect oak.oakland.edu anonymous user@domail.net cd windows/mosaic binary get mosaic.zip quit
В приведенном выше примере используется команда cd, которая позволяет переходить по дереву файловой системы от одной директории к другой. При запросе двоичных файлов надо быть уверенным в том, что почтовая программа способна извлечь данные из почтового сообщения (пакет BML позволяет это сделать), или иметь на машине программу uudecode. В случае приема закодированного двоичного файла в тексте сообщения должен быть блок типа:
begin 600 kuku.zip &4$%53`H* ` end
Этот блок следует выделить в отдельный файл и обработать программой uudecode.
Пользователи BITNET имеют роботов, которые позволяют использовать более широкие возможности FTP-сервиса. Одним из таких роботов является робот bitftp@pucc.princeton.edu. Этот робот позволяет пользоваться всем набором команд FTP. В течении одной сессии можно открывать и закрывать FTP-соединения с разными ftp серверами, заказывать кодировку двоичных файлов, отличную от uuencode,
получать подсказку о своем месте в файловой системы сервера и т.п. В принципе, робот bitftp@pucc.princenton.edu
доступен не только пользователям BITNET, но администраторы робота не рекомендуют пользователям других сетей пользоваться данным роботом. Однако для другого робота - BITFTP@vm.gmd.de, таких оговорок нет. Важным достоинством BITNET-роботов является возможность получения списка FTP-архивов. И последнее замечание по поводу доступа к FTP по e-mail: если в теле сообщения указать только слово "help", то робот расскажет о своих возможностях. Ниже приведен пример ответа ftpmail.
From ftpmail@doc.ic.ac.uk Thu Mar 16 02:03 EET 1995 Received: from puffin.doc.ic.ac.uk by apollo.polyn.kiae.su with SMTP (1.38.193.4/16.2) id AA02419; Thu, 16 Mar 1995 02:02:56 +0200 Return-Path: <ftpmail@doc.ic.ac.uk> Received: from doc.ic.ac.uk by puffin.doc.ic.ac.uk id <14782-0@puffin.doc.ic.ac.uk>; Wed, 15 Mar 1995 19:22:26 +0000 To: paul@apollo.polyn.kiae.su Subject: <FTP EMAIL> response Date: Wed, 15 Mar 1995 19:22:26 +0000 From: Email-FTP Gateway Account <ftpmail@doc.ic.ac.uk> Message-Id: <"puffin.doc.790:15.02.95.19.22.34"@doc.ic.ac.uk> Status: RO <FTP EMAIL> response ftpmail has received the following job from you: reply-to paul@apollo.polyn.kiae.su open oak.oakland.edu anonymous paul@apollo.polyn.kiae.su ls cd pub get README ftpmail has queued your job as: 995331.14774 Your priority is 9 (0 = highest, 9 = lowest) Requests to src.doc.ic.ac.uk will be done before other jobs. There are 2057 jobs ahead of this one in the queue. 5 ftpmail handlers available. To remove send a message to ftpmail@src.doc.ic.ac.uk containing just: delete 995331.14774 Your original input was>> >Return-Path: <paul@apollo.polyn.kiae.su> >Received: from doc.ic.ac.uk by puffin.doc.ic.ac.uk with SMTP (PP) > id <13192-1@puffin.doc.ic.ac.uk>; Wed, 15 Mar 1995 18:52:46 +0000 >Received: from apollo.polyn.kiae.su by frigate.doc.ic.ac.uk with SMTP (PP) > id <23071-0@frigate.doc.ic.ac.uk>; Wed, 15 Mar 1995 18:42:06 +0000 >Received: by apollo.polyn.kiae.su (1.38.193.4/16.2) id AA02362; > Wed, 15 Mar 1995 21:42:40 +0200 >From: Pavel Khramtsov <paul@apollo.polyn.kiae.su> >Subject: >To: ftpmail@doc.ic.ac.uk >Date: Wed, 15 Mar 95 21:42:40 EET >Mailer: Elm [revision: 70.85] >Message-ID: <"frigate.do.244:15.02.95.18.52.41"@doc.ic.ac.uk> > >connect oak.oakland.edu anonymous paul@apollo.polyn.kiae.su >ls >cd pub >get README >quit > <<End of your input
Сервер уведомил о получении запроса на передачу файла "README".
Назад | Содержание | Вперед
Доступ к ресурсам Internet через электронную почту
Доступ через электронную почту к другим ресурсам сети основан на использовании программ-шлюзов. Для этого среди почтовых пользователей заводят таких, для которых в файле aliases задают обработку почтовых сообщений. Прежде чем рассмотреть этот способ посмотрим как выглядит такой способ для доступа к файловым архивам и сервису Archie.
Назад | Содержание | Вперед
Файловые архивы Internet
В настоящее время, когда популярность World Wide Web достаточно велика, объем трафика передаваемого по сети Internet по протоколу FTP занимает тем не менее первое место, несколько опережая объем трафика по протоколу HTTP. В этом свете организация файловых архивов в рамках технологии TCP/IP является крайне актуальной задачей.
Архивы используют для решения разных задач, однако наиболее популярными в сети являются свободно доступные архивы или такие архивы, доступ к которым разрешен по анонимному идентификатору пользователя. Таким образом эти архивы можно использовать в качестве:
коллекции свободно распространяемого программного обеспечения;
коллекции программ для бета-тестирования;
коллекции нормативных и регламентных документов;
и т.п.
FTP-архив можно использовать и в качестве архива коммерческого программного обеспечения, которое используется в компании, только в этом случае такой архив не должен разрешать анонимного доступа к хранящимся в нем ресурсам.
Часто возможность авторизированного FTP-доступа используют и для обмена сообщениями, т.е. в качестве средства коммуникации. Это происходит обычно в том случае, когда система электронной почты по тем или иным причинам не работает.
В настоящее время всю систему взаимодействия компонентов FTP-обмена можно представить в виде схемы представленной на рисунке 4.1.
На этой схеме показано два важных технологических момента: во-первых, доступ к архиву можно осуществлять не только из специализированной программы-клиента, но и из универсального броузера, например Netscape Communicator или Microsoft Internet Explorer, а во-вторых, для поиска информации в FTP-архивах можно воспользоваться программой Archie.
Рис. 4.1. Схема взаимодействия компонентов FTP-обмена
При этом следует четко понимать, что Archie и FTP - это совершенно разные технологии. В большинстве случаев доступ к Archie-серверу пользователи осуществляют из Archie-клиента, который находится на той же машине, что и сервер, т.е. сначала пользователь по Telnet заходит как пользователь Archie, а потом использует программу-клиент (обычно она запускается в качестве оболочки) для доступа к Archie серверу.
Назад | Содержание | Вперед
Формат почтового сообщения (RFC-
При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или To, например:
Date: 26 Aug 76 1429 EDT From: Jones@Registry.org cc:
или
Date: 26 Aug 76 1429 EDT From: Jones@Registry.org To: Smith@Registry.org
Поле Date определяет дату отправки сообщения, поле From - отправителя, а поля сс и To
- получателя(ей). Чаще заголовок содержит дополнительные поля:
Date: 26 Aug 76 1429 EDT From: George Jones<Jones@Registry.org> Sender: Secy@SHOST To: Smith@Registry.org Message-ID: <4231.629.XYzi-What@Registry.org>
В данном случае поле Sender
указывает, что George Jones не является автором сообщения. Он только переслал сообщение, которое получил из Secy@SHOST. Поле Message-ID
содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка:
Date: 27 Aug 76 0932 From: Ken Davis <Kdavis@This-Host.This.net> Subject: Re: The Syntax in the RFC Sender: KSecy@Other-host Reply-To: Sam.Irving@Reg.Organization To: George Jones <Jones@Registry.org> cc: Important folks: Tom Softwood <Balsa@Tree.Root>, "Sam Irving"@Other-Host;, Standard Distribution: /main/davis/people/standard@Other-Host Comment: Sam is away on bisiness. In-Reply-To: <some.string@DBM.Group>, 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. Время, затраченное на чтение документации и опыты, окупятся возможностью получения информации из информационных архивов сети.
Назад | Содержание | Вперед
Электронная почта в Internet
Электронная почта - один из важнейших информационных ресурсов Internet. Она является самым массовым средством электронных коммуникаций. Любой из пользователей Internet имеет свой почтовый ящик в сети. Если учесть, что через Internet можно принять или послать сообщения еще в два десятка международных компьютерных сетей, некоторые из которых не имеют on-line сервиса вовсе, то становится понятным, что почта предоставляет возможности в некотором смысле даже более широкие, чем просто информационный сервис Internet. Через почту можно получить доступ к информационным ресурсам других сетей. Хорошим примером может служить доступ к архивам сети BITNET - документам и телеконференциям, которые ведутся на серверах списков (LISTSERVER) BITNET.
Назад | Содержание | Вперед
Настройка программы sendmail
Настройка программы sendmail происходит при помощи файла /etc/sendmail/conf. Этот файл можно разбить на несколько частей:
Описание особенностей данной машины (local information) - в данной секции описываются такие параметры, как имя данной машины, имя UUCP и т.п.
Описание макроопределений sendmail, отвечающих за работу в локальной сети, например, имя домена и "официальное имя" машины.
Описание классов, т.е. групп имен, которые используются программой для рассылки почты. Например, для рассылки в другие почтовые службы.
Номер версии файла конфигурации. Данная переменная должна изменяться каждый раз, как только в файл конфигурации вносятся какие-либо изменения.
Внутренние макроопределения sendmail. В данном разделе присваиваются значения переменным, которые sendmail использует при взаимодействии с другими транспортными агентами.
Опции команды sendmail. Опции определяют режимы работы программы. Опции можно задавать в виде параметров командной строки, а можно в виде описаний в файле настройки.
Определение порядка сообщений программы sendmail (Precedence). Обычно эта секция не модифицируется администратором.
Доверенные пользователи. В данной секции описываются пользователи, которым разрешено переписывать адреса отправителей, т.е. выступать не под тем адресом, который за ними закреплен.
Описание формата заголовка почтового сообщения. В данной секции определяются поля и их формат, которые отображаются в заголовке. Многие поля заголовка sendmail генерирует на основе информации из конверта почтового сообщения.
Правила преобразования адресов. Это самая большая часть файла конфигурации программы sendmail. Преобразование адресов необходимо для принятия программой решений о пути рассылки почтовых сообщений, т.к. это решение принимается на основе полученного в результате преобразований почтового адреса.
Описание программ рассылки. В данной секции описываются имена программ рассылки, пути и параметры командной строки этих программ. Обычно это программа местной рассылки, рассылка по UUCP, рассылка по SMTP, рассылка на выполнение.
Общий набор правил преобразования адресов, который не меняется от машины к машине и от конфигурации к конфигурации (Rule Set 0).
Машинно-зависимая часть общего правила преобразования адресов. В данной секции содержание определяется способом рассылки почты. Например, данная секция при рассылке по SMTP будет отличаться от случая рассылки по UUCP.
В большинстве случаев все изменения, которые приходиться внести в файл конфигурации, касаются только имени машины, домена и машин шлюзов в другие почтовые службы. Однако, если у организации имеется достаточно продолжительная и славная история использования электронной почты, то может оказаться, что для нормального функционирования придется произвести и ряд более существенных изменений.
В целом все описанные выше секции решают три основных задачи:
определение окружения sendmail,
анализ и преобразование адресов электронной почты,
рассылка сообщений при помощи программ рассылки.
При редактировании файла следует учитывать некоторые правила, которые используются при написании файла конфигурации: вся информация локального характера сосредоточена в начале файла, команды одного типа собраны в компактные группы, большую часть файла составляют правила преобразования адресов, в конце файла описаны программы рассылки электронной почты.
Все команды, которые используются в файле настроек sendmail можно представить в виде следующей таблицы:
| Define Macro | Dxvalue | Установить значение "x" |
| Define Class | Ссword1 word2 ... | Установить значение класса "c" |
| Define Class | Fcfile | загрузить значение класса из файла |
| Set Option | Oovalue | Установить значение опции "o" |
| Trusted Users | Tuser1 user2 ... | Определить доверенных пользователей |
| Set Precedence | Pname=number | Для номера ошибки number установить имя name |
| Define Mailer | Mname,[field=value] | Определить программу рассылки почты |
| Define Header | H[?mflag?]name:format | Определить формат поля заголовка |
| Set Rulset | Sn | Начать определение набора правил преобразования адресов |
| Define Rule | Rlhs rhs comment | Определить правило преобразования адреса |
Формат команды файла настроек sendmail не очень удобен для чтения. В целом его можно определить следующим образом:
Рис. 3.2. Структура команды файла настроек sendmail
Теперь разберем более подробно некоторые команды и секции файла настроек sendmail. Лучше всего это сделать на основе реального файла. Начнем с секции описания локальных параметров:
################## # local info # ################## Cwlocalhost CP. # UUCP relay host DYucbvax.Berkeley.EDU CPUUCP # BITNET relay host #DBmailhost.Berkeley.EDU DBrelay.kiae.su CPBITNET # "Smart" relay host (may be null) DSrelay.kiae.su # who I send unqualified names to (null means deliver locally) DR # who gets all local email traffic ($R has precedence for unqualified names) DH # who I masquerade as (null for no masquerading) DM # class L: names that should be delivered locally, even if we have a relay # class E: names that should be exposed as from this host, even if we masquerade #CLroot CEroot # operators that cannot be in local usernames (i.e., network indicators) CO @ % ! # a class with just dot (for identifying canonical names) C.. # dequoting map Kdequote dequote
Как видно из этого листинга, в данной секции описаны имя данной машины (Cwlocalhost), а также класс машин-шлюзов в другие почтовые системы (CP....). При этом наращивание класса происходит по мере описания шлюза для каждого из видов почтовых служб. В конце секции описаны символы, которые не могут использоваться в качестве имен пользователей или доменов.
Следующая секция - определение макросов sendmail:
###################### # Special macros # ###################### # SMTP initial login message De$j Sendmail $v/$Z ready at $b # UNIX initial From header format DlFrom $g $d # my name for error messages DnMAILER-DAEMON # delimiter (operator) characters Do.:%@!^/[] # format of a total name Dq$?x$x <$g>$|$g$. # Configuration version number DZ8.6.6
В данной секции описаны сообщения, которые выдает sendmail при взаимодействии с другими транспортными агентами. Как видно из этого описания, определение макроса это не только присваивание значения, но и выполнение определенных действий. Наиболее интересное предложение из всех - предложение, определяющее значение макроса q:
Dq$?x$x <$g>$|$g$.
Здесь описана условная подстановка значения. Все предложение можно описать следующей фразой:
"Если значение переменной x установлено, то: q = значение_x <значение_g>, иначе: q=значение_g".
То же самое можно записать и по-другому:
if(x!=NULL) { strcpy(q,x); strcat(q," <"); strcat(q,g); strcat(q,">"); { else { strcpy(q,g); }
В данном случае $?
соответствует оператору if, $|
- else, а $. - конец условного оператора.
Следующая секция - это определение опций:
############### # Options # ############### # strip message body to 7 bits on input? #O7False # Insist that the BIND name server be running to resolve names OI # deliver MIME-encapsulated error messages? OjTrue
В данном случае приведен только фрагмент этой секции. Большинство параметров общие для всех установок sendmail. Указанные же в листинге параметры являются принципиальными с точки зрения режимов работы sendmail. Первый параметр определяет тот факт, что по почте можно пересылать семибитовую информацию. Согласно RFC-822 информация должна быть семибитовая, но для передачи кириллицы это значит использовать кодирование, что абсолютно не приемлемо. Поэтому данный параметр должен быть закоментарен. В системах, где используется сервер доменных имен, опция I (OI) должна быть установлена, чтобы не было ошибок при идентификации доменов. Последний параметр не является принципиальным, но для целей более понятного представления его следует установить. Если почтовый клиент не поддерживает MIME, то данный параметр следует закоментарить.
Следующие две секции определяют уровень сообщений об ошибках и доверенных пользователей:
########################### # Message precedence # ########################### Pfirst-class=0 Pspecial-delivery=100 Plist=-30 Pbulk=-60 Pjunk=-100 ##################### # Trusted users # ##################### Troot Tdaemon Tuucp
За этими двумя секциями следует секция описания полей заголовка почтового сообщения, который генерируется программой sendmail:
######################### # Format of headers # ######################### H?P?Return-Path: $g HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.by $j ($v/$Z)$?r with $r$. id $i$?u for $u$.; $b H?D?Resent-Date: $a H?D?Date: $a H?F?Resent-From: $q H?F?From: $q H?x?Full-Name: $x HSubject: # HPosted-Date: $a # H?l?Received-Date: $b H?M?Resent-Message-Id: <$t.$i@$j> H?M?Message-Id: <$t.$i@$j>
Формат команд данной секции определяет какие поля включаются в заголовок, а какие не включаются. Данная секция тесно связана с секцией определения программ рассылки почты. Если после H нет знака вопроса, то поле включается в заголовок сообщения для любой программы рассылки, если после H символ "?" присутствует, то в строке аргументов программы рассылки данный флаг должен быть определен для того, чтобы данное поле было включено в заголовок. Как следует из приведенного выше описания, всегда включаются только поля Received и Subject. Все перечисленные поля не являются обязательными полями заголовка.
Следующая секция - правила преобразования адресов. Но прежде чем обсуждать ее содержание следует сказать как и когда sendmail эти адреса преобразовывает.
Прежде всего необходимо рассмотреть схему преобразования (рисунок 3.3).
Рис. 3.3. Правила
При получении почтового сообщения адреса, указанные в полях To, From, Cc, преобразуются в соответствии с правилами преобразования.
###################################################################### ###################################################################### ##### ##### REWRITING RULES ##### ###################################################################### ###################################################################### ########################################### ### Rulset 3 - Name Canonicalization ### ########################################### S3 # handle null input (translate to <@> special case) R$@ $@ <@> # basic textual canonicalization -- note RFC733 heuristic here R$*<$*>$*<$*>$* $2$3<$4>$5 strip multiple <> <> R$*<$*<$+>$*>$* <$3>$5 2-level <> nesting R$*<>$* $@ <@> MAIL FROM:<> case R$*<$+>$* $2 basic RFC821/822 parsing # handle list:; syntax as special case R$*:;$* $@ $1 :; <@> # make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later R@ $+ , $+ @ $1 : $2 change all "," to ":" # localize and dispose of route-based addresses R@ $+ : $+ $@ $>96 < @$1 > : $2 handle <route-addr> # find focus for list syntax R $+ : $* ; @ $+ $@ $>96 $1 : $2 ; < @ $3 > list syntax R $+ : $* ; $@ $1 : $2; list syntax # find focus for @ syntax addresses R$+ @ $+ $: $1 < @ $2 > focus on domain R$+ < $+ @ $+ > $1 $2 < @ $3 > move gaze right R$+ < @ $+ > $@ $>96 $1 < @ $2 > already canonical # do some sanity checking R$* < @ $* : $* > $* $1 < @ $2 $3 > $4 nix colons in addrs
# convert old-style addresses to a domain-based address R$- ! $+ $@ $>96 $2 < @ $1 .UUCP > resolve uucp names R$+ . $- ! $+ $@ $>96 $3 < @ $1 . $2 > domain uucps R$+ ! $+ $@ $>96 $2 < @ $1 .UUCP > uucp subdomains # if we have % signs, take the rightmost one R$* % $* $1 @ $ 2 First make them all @s. R$* @ $* @ $* $1 % $2 @ $3 Undo all but the last. R$* @ $* $@ $>96 $1 < @ $2 > Insert < > and finish # else we must be a local name ################################################ ### Ruleset 96 - bottom half of ruleset 3 ### ################################################ # At this point, everything should be in a "local_part<@domain>extra" format. S96 # handle special cases for local names R$* < @ localhost > $* $: $1 < @ $j . > $2 no domain at all R$* < @ localhost . $m > $* $: $1 < @ $j . > $2 local domain R$* < @ localhost . UUCP > $* $: $1 < @ $j . > $2 .UUCP domain R$* < @ [ $+ ] > $* $: $1 < @@ [ $2 ] > $3 mark [a.b.c.d] R$* < @@ $=w > $* $: $1 < @ $j . > $3 self-literal R$* < @@ $+ > $* $@ $1 < @ $2 > $3 canon IP addr # pass UUCP addresses straight through R$* < @ $+ . UUCP > $* $@ $1 < @ $2 . UUCP . > $3 # pass to name server to make hostname canonical R$* < @ $* $~P > $* $: $1 < @ $[ $2 $3 $] > $4 # local host aliases and pseudo-domains are always canonical R$* < @ $=w > $* $: $1 < @ $2 . > $3 R$* < @ $* $=P > $* $: $1 < @ $2 $3 . > $4 R$* < @ $* . . > $* $1 < @ $2 . > $3 # if this is the local hostname, make sure we treat is as canonical R$* < @ $j > $* $: $1 < @ $j . > $2 ################################################## ### Ruleset 4 - Final Output Post-rewriting ### ################################################## S4 R$*<@> $@ $1 handle <> and list:; # strip trailing dot off possibly canonical name R$* < @ $+ . > $* $1 < @ $2 > $3 # externalize local domain info R$* < $+ > $* $1 $2 $3 defocus R@ $+ : @ $+ : $+ @ $1 , @ $2 : $3 <route-addr> canonical R@ $* $@ @ $1 ...and exit # UUCP must always be presented in old form R$+ @ $- . UUCP $2!$1 u@h.UUCP => h!u # delete duplicate local names R$+ % $=w @ $=w $1 @ $j u%host@host => u@host ############################################################## ### Ruleset 97 - recanonicalize and call ruleset zero ### ### (used for recursive calls) ### ############################################################## S97 R$* $: $>3 $1 R$* $@ $>0 $1 ###################################### ### Ruleset 0 - Parse Address ### ###################################### S0 R<@> $#local $: <> special case error msgs R$* : $* ; $#error $@ USAGE $: "list:; syntax illegal for recipient addresses" R<@ $+> $#error $@ USAGE $: "user address required" R<$* : $* > $#error $@ USAGE $: "colon illegal in host name part" # handle numeric address spec R$* < @ [ $+ ] > $* $: $>98 $1 < @ [ $2 ] > $3 numeric internet spec R$* < @ [ $+ ] > $* $#smtp $@ [$2] $: $1 < @ [$2] > $3 still numeric: send # now delete the local info -- note $=O to find characters that cause forwarding R$* < @ > $* $@ $>97 $1 user@ => user R< @ $=w . > : $* $@ $>97 $2 @here:... -> ... R$* $=O $* < @ $=w . > $@ $>97 $1 $2 $3 ...@here -> ...
# handle local hacks R$* $: $>98 $1 # short circuit local delivery so forwarded email works R$+ < @ $=w . > $: $1 < @ $2 . @ $H > first try hub R$+ < $+ @ $+ > $#local $: $1 yep .... R$+ < $+ @ > $#local $: @ $1 nope, local address # resolve remotely connected UUCP links (if any) # resolve fake top level domains by forwarding to other hosts R$*<@$+.BITNET.>$* $: $>95 < $B > $1 <@$2.BITNET.> $3 user@host.BITNET # forward non-local UUCP traffic to our UUCP relay R$*<@$*.UUCP.>$* $: $>95 < $Y > $1 <@$2.UUCP.> $3 uucp mail # pass names that still have a host to a smarthost (if defined) R$* < @ $* > $* $: $>95 < $S > $1 < @ $2 > $3 glue on smarthost name # deal with other remote names R$* < @$* > $* $#smtp $@ $2 $: $1 < @ $2 > $3 user@host.domain # if this is quoted, strip the quotes and try again R$+ $: $(dequote $1 $) strip quotes R$+ $=O $+ $@ $>97 $1 $2 $3 try again # handle locally delivered names R$=L $#local $: @ $1 special local names R$+ $#local $: $1 regular local names ########################################################################### ### Ruleset 5 - special rewriting after aliases have been expanded ### ### (new sendmail only) ### ########################################################################### S5 # see if we have a relay or a hub R$+ $: < $R > $1 try relay R< > $+ $: < $H > $1 try hub R< > $+ $@ $1 nope, give up R< $- : $+ > $+ $: $>95 < $1 : $2 > $3 < @ $2 > R< $+ > $+ $@ $>95 < $1 > $2 < @ $1 > ################################################################### ### Ruleset 95 - canonify mailer:host syntax to triple ### ################################################################### S95 R< > $* $@ $1 strip off null relay R< $- : $+ > $* $# $1 $@ $2 $: $3 try qualified mailer R< $=w > $* $@ $2 delete local host R< $+ > $* $#relay $@ $1 $: $2 use unqualified mailer ################################################################### ### Ruleset 98 - local part of ruleset zero (can be null) ### ################################################################### S98
За секцией преобразования адресов следует секция определения программ рассылки почты. В ней определяется локальная программа рассылки (mail), программа рассылки для выполнения (sh) и программа рассылки по SMTP.
################################################## ### Local and Program Mailer specification ### ################################################## Mlocal, P=/usr/libexec/mail.local, F=lsDFMrmn, S=10, R=20/40, A=mail -d $u Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, A=sh -c $u S10 R<@> $n errors to mailer-daemon R$+ $: $>40 $1 S20 R$+ < @ $* > $: $1 strip host part S40 ##################################### ### SMTP Mailer specification ### ##################################### Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, A=IPC $h Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, A=IPC $h Mrelay, P=[IPC], F=mDFMuXa, S=11/31, R=61, E=\r\n, L=2040, A=IPC $h
Затем идут правила определения локального преобразования адресов для конкретных программ рассылки, в частности набор правил S11.
# envelope sender and masquerading recipient rewriting # S11 R$+ $: $>51 $1 sender/recipient common R$* :; <@> $@ $1:; list:; special case R$* $@ $>61 $1 qualify unqual'ed names
В секции программ рассылки мы в нашем примере не указали еще одну важную возможность - рассылку по протоколу UUCP:
Мuucp, P=/usr/bin/uux, F=DFMhuU, S=13, R=23, M=100000, A=uux - -r -z -a$f -gC $h!rmail
Естественно, что правила преобразования адресов S13 и R23 должны быть описаны в файле настроек sendmail.
Назад | Содержание | Вперед
Поиск ресурсов посредством Archie
Archie тесно связана с сервисом, который был рассмотрен в предыдущем разделе, так как тоже работает с FTP-архивами. Назначение Archie - поиск программы в FTP-архиве по шаблону. Действительно, мало знать, где взять, надо еще знать что брать. Если точное имя программы или документа не известно, но есть подозрение, что данный файл храниться в одном из FTP-архивов, к которым есть анонимный доступ, то следует воспользоваться программой archie. В стандартном режиме серверу archie отправляют слово, например "tex", а получают список адресов FTP-архивов, в которых есть программы, начинающиеся с этого слова. После того, как выбран подходящий архив, при помощи FTP списывают программу на свой компьютер. Аналогичный сервис существует через электронную почту.
Рассмотрим в качестве примера робот archie archie@cs.mcgill.ca. Для получения доступа к услугам archie по адресу робота следует отправить следующее сообщение:
mail archie@cs.mcgill.ca Subject: help prog tex quit
В поле Subject указывается первая команда из списка команд, которые пользователь предполагает выполнить в течении сессии. Если помощи не требуется, то в поле Subject
можно указать сразу команду "prog ...". Если сервер имеет специальный файл описания назначения отдельных программ, то можно выполнить команду "whatis tex" и получить объяснение.
Аналогично стандартному режиму работы, после получения адресов FTP-архивов, хранящих необходимую программу, можно воспользоваться доступом к архиву FTP по электронной почте. Ниже приведен пример ответа почтового робота archie.
From archie-errors@titanic.CS.McGill.CA Wed Mar 15 21:41 EET 1995 Received: from titanic.CS.McGill.CA by apollo.polyn.kiae.su with SMTP (1.38.193.4/16.2) id AA02354; Wed, 15 Mar 1995 21:40:45 +0200 Return-Path: <archie-errors@titanic.CS.McGill.CA> Received: (from archie@localhost) by titanic.cs.mcgill.ca (8.6.9/8.6.9) id NAA56049; Wed, 15 Mar 1995 13:39:50 -0500 Message-Id: <199503151839.NAA56049@titanic.cs.mcgill.ca> To: Pavel Khramtsov <paul@apollo.polyn.kiae.su> From: (Archie Server)archie-errors@titanic.CS.McGill.CA Reply-To: (Archie Server)archie-errors@titanic.CS.McGill.CA Date: Wed, 15 Mar 95 18:39 GMT Subject: archie [prog tex] part 1 of 1 Status: RO >> path Pavel Khramtsov <paul@apollo.polyn.kiae.su> >> help Archie Email Help (Version 3.2) HELP for this archie email server, as of 11 April, 1994. To perform an archie search via email, send mail to archie@<archie_server> where <archie_server> is the name of an archie host, some of which are listed below. The "Subject:" header in mail sent to archie is treated as part of the message body. Command lines begin in the first column. All lines that do not match a valid commands are igored. Empty messages are treated as "help" requests (this file). If no command in a particular message can be recognized, the message is treated as "empty" and this file will be returned. The current (and complete) list of archie servers can be found with the "servers" command
В этом примере приведен сокращенный ответ сервера.
Назад | Содержание | Вперед
Поиск в FTP-архивах - программа Archie
В настоящее время доступ по FTP-протоколу осуществляется из множества мультипротокольных интерфейсов (например, Mosaic или Netscape) или графических ftp-оболочек типа ftptool для X-Window. Все они гораздо удобнее и проще в использовании, но и потребляют гораздо больше ресурсов.
Любопытно, что FTP-сервер есть даже для MS-DOS (пакет NCSA Telbin), не говоря о многозадачных средах. Однако поиск нужного FTP-сервера в Internet - задача сложная и трудоемкая. Для ее облегчения существует специальное средство - Archie. Archie был разработан в Университете McGill в Канаде. Задача Archie - сканировать FTP-архивы на предмет наличия в них требуемых файлов. Работать с Archie можно через telnet-сессию, через локального клиента или по электронной почте. Для работы по telnet следует открыть telnet-сессию, в ответ на login ввести слово "archie":
telnet archie.mcgill.ca login: archie ...... archie>
После появления приглашения "archie>"
следует поинтересоваться возможностями сервера, введя команду "help".
При работе через локального клиента вводят просто:
archie gnuplot.tar.gz
и в ответ получают список архивов, где имеется файл "gnuplot.tar.gz". Следует принять во внимание, что различные модификации клиентов (особенно графические) могут значительно отличаться по синтаксису друг от друга.
Назад | Содержание | Вперед
Коды возврата SMTP
| 211 | System status, or system help reply | Статус системы или Help |
| 214 | Help message. [Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user] | Краткая справка |
| 220 | <domain> Service ready | SMTP-сервис готов к работе |
| 221 | <domain> Service closing transmission channel | Сервис закрыл канал передачи данных |
| 250 | Requested mail action okay, completed | Соединение установлено |
| 251 | User not local; will forward to <forward-path> | Пользователь не местный. Выполнить перенаправление запроса |
| 354 | Start mail input; end with <CRLF>.<CRLF> | Начать ввод почтового сообщения |
| 421 | <domain> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down] | Сервис отсутствует. Канал передачи данных закрыт |
| 450 | Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] | Нет возможности записать данные в почтовый ящик |
| 451 | Requested action aborted: local error in processing | Ошибка при обработке запроса |
| 452 | Requested action not taken: insufficient system storage | Запрос не выполнен недостаточно памяти на вычислительной установке |
| 500 | Syntax error, command unrecognized [This may include errors such as command line too long] | Синтаксическая ошибка - нет такой команды |
| 501 | Syntax error in parameters or arguments | Синтаксическая ошибка в аргументах команды |
| 502 | Command not implemented | Данная команда не может быть выполнена |
| 503 | Bad sequence of commands | Неправильная последовательность команд |
| 504 | Command parameter not implemented | Параметр команды не может быть использован в данном контексте |
| 550 | Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] | Не найден соответствующий почтовый ящик |
| 551 | User not local; please try <forward-path> | Пользователь не найден можно попробовать отправить почту по другому адресу |
| 552 | Requested mail action aborted: exceeded storage allocation | Превышены квоты на использование ресурсов памяти |
| 553 | Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] | Имя почтового ящика неправильное |
| 554 | Transaction failed | Обмен завершился аварийно |
Назад | Содержание
Команды протокола SMTP
| HELO <SP> <domain> <CRLF> | Открыть сессию взаимодействия по протоколу SMTP. <domain> - доменное имя машины |
| MAIL <SP> FROM:<reverse-path> <CRLF> | Сообщить адрес отправителя (<reverse-path>). Обязательная команда, которую надо выдать перед отправкой сообщения |
| RCPT <SP> TO:<forward-path> <CRLF> | Сообщить адрес получателя (forward-path). Обязательная команда, которую выдают после MAIL FROM, но перед DATA |
| DATA <CRLF> | Начать передачу тела почтового сообщения. Тело сообщения должно кончаться точкою(".") в первой позиции строки |
| RSET <CRLF> | |
| SEND <SP> FROM:<reverse-path> <CRLF> | Послать сообщение на терминал пользователя, который определяется командой RCPT |
| SOML <SP> FROM:<reverse-path> <CRLF> | SEND OR MAIL. Послать в почтовый ящик или на терминал пользователя |
| SAML <SP> FROM:<reverse-path> <CRLF> | SEND AND MAIL. Послать в почтовый ящик и на терминал пользователя |
| VRFY <SP> <string> <CRLF> | Получить информацию о пользователе, имя которого указывается в качестве аргумента команды (<string>) |
| EXPN <SP> <string> <CRLF> | Получить информацию о пользователях зарегистрированных в качестве получателей корреспонденции |
| HELP [<SP> <string>] <CRLF> | Краткая справка по командам протокола |
| NOOP <CRLF> | Нет операции |
| QUIT <CRLF> | Завершить сессию |
| TURN <CRLF> | Поменяться местами серверу и клиенту |
Принципы организации
Электронная почта во многом похожа на обычную почтовую службу. Корреспонденция подготавливается пользователем на своем рабочем месте либо программой подготовки почты, либо просто обычным текстовым редактором. Обычно программа подготовки почты вызывает текстовый редактор, который пользователь предпочитает всем остальным программам этого типа. Затем пользователь должен вызвать программу отправки почты (программа подготовки почты вызывает программу отправки автоматически). Стандартной программой отправки является программа 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
почтовый адрес будет выглядеть как:
paul@polyn.net.kiae.su.
Таким образом, адрес состоит из двух частей: идентификатора пользователя, который записывается перед знаком "коммерческого эй" - "@", и доменного адреса машины, который записывается после знака "@". Адрес UUCP был бы записан как строка вида:
net.kiae.su!polyn!paul
Программа рассылки почты Sendmail сама преобразует адреса формата Internet в адреса формата UUCP, если доставка сообщения осуществляется по этому протоколу.
Назад | Содержание | Вперед
Программа обмена файлами - ftp
FTP - это интерфейс пользователя при обмене файлами по одноименному протоколу. Программа устанавливает канал управления с удаленным сервером и ожидает команд пользователя. Идентификатор удаленного сервера указывается либо аргументом программы, либо в команде интерфейса open.
Если команда ftp работает с пользователем и ожидает его команд, то на экране отображается приглашение "ftp>".
Синтаксис команды:
ftp [-v][-d][-i][-n][host]
v - подавляет ответы сервера и статистику передачи данных;
n - управляет режимом идентификации пользователя. Если указан этот ключ, то сначала проверяется файл .netrc;
i - выключает подтверждения передачи файла при массовом копировании файлов;
d - включает режим отладки;
g - отключает прозрачность передачи имен.
В рамках данного курса нет возможности перечислить все команды ftp, поэтому остановимся только на самых необходимых.
Первой такой командой является команда open. По этой команде открывается сеанс работы с удаленным сервером:
ftp>open polyn.net.kiae.su
После выдачи такой команды последуют запросы идентификации пользователя. Зарегистрировать пользователя можно и по команде user:
ftp> user anonymous
В данном примере пользователь не имеет особых прав доступа на удаленном сервере и поэтому регистрируется как аноним. В ответ на запрос идентификации следует в этом случае ввести свой почтовый адрес. Обычно достаточно ввести что-то похожее на почтовый адрес для допуска к ресурсам архива, но бывают и дотошные серверы, которые проверяют наличие такого адреса, поэтому лучше никого не обманывать и честно регистрироваться.
Следующими по важности командами являются команды cd и ls (dir).
Назначение этих команд достаточно прозрачно и понятно всем пользователям - навигация по дереву файловой системы и просмотр содержания каталогов. Здесь следует посоветовать пользоваться при просмотре каталогов командой ls
с дополнительными параметрами:
ftp>ls -FC
В этом случае пользователь может получить многоколоночный отчет с указанием типов файлов. Однако не все серверы отрабатывают эту комбинацию.
Так как в процессе приема- передачи участвуют две машины, то кроме навигации в удаленной файловой системе нужна еще навигация в локальной файловой системе. Для этой цели служит команда lcd (локальная cd). Кроме этого пользователь может выдать и любую команду локальной оболочки, если предварит ее символом "!":
ftp> !pwd
По этой команде будет выдано имя текущей директории на локальной машине.
И, наконец, самыми важными являются команды
приема/передачи данных get, put, mget, mput и bin. По командам get и put можно принять или передать один файл:
ftp> get README.TXT
Команды mget, mput предназначены для приема/передачи набора файлов:
ftp> mget *.gz
Из примера видно, что в последнем случае применяется маска "*". Обычно при передаче групп файлов для каждого файла запрашивается подтверждение. Для того, чтобы избежать этого перед приемом/передачей, следует выдать команду prompt. Последняя переключает режим запроса подтверждения и при повторном использовании этой команды состояние запроса подтверждения восстанавливается. Другой полезной командой является команда hash:
ftp> hash #
Символ "#" можно заменить на любой другой. При работе по медленным линиям или при передаче больших файлов после включения режима hash пользователь имеет возможность видеть процесс передачи данных (знак "#" выдается после передачи каждого блока). И последнее, на чем следует остановить внимание - это команда bin. После выдачи этой команды по умолчанию данные будут передаваться в режиме передачи двоичных данных. Последнее чрезвычайно важно, т.к. при передачи в ASCII нельзя передать программы и архивированные данные. Часто бывает полезно включить режим bin
и для символьных данных с произвольной длиной строки, например файлов postscript (*.ps), т.к. в ASCII режиме есть ограничение на длину строки (обычно 254 символа).
Для выхода из ftp следует выполнить команду quit.
Назад | Содержание | Вперед
Программа Sendmail
Основным средством рассылки почты в Internet является программа sendmail. Она обеспечивает работу модульной системы рассылки, которая предназначена для получения и отправки корреспонденции, а также управления программами подготовки и просмотра почтовых сообщений. Sendmail позволяет организовать почтовую службу локальной сети и обмениваться почтой с другими серверами почтовых служб через специальные шлюзы. Sendmail может быть сконфигурирована для работы с различными почтовыми протоколами. Обычно это протоколы UUCP (Unix-Unix-CoPy)
и SMTP (Simple Mail Transfer Protocol).
Sendmail работает как "отделение связи" обычной почтовой службы, которое принимает и пересылает почтовые сообщения. Sendmail может интерпретировать два типа почтовых адресов:
почтовые адреса SMTP;
почтовые адреса UUCP.
Первые являются стандартными адресами Internet и, фактически, являются стандартом де-факто. Именно этот адрес обычно указан на визитных карточках.
Sendmail можно настроить для поддержки:
списка адресов-синонимов;
списка адресов рассылки пользователя;
автоматической рассылки почты через шлюзы;
очередей сообщений для повторной рассылки почты в случае отказов при рассылке;
работы в качестве SMTP-сервера;
доступа к адресам машин через сервер доменных имен BIND;
доступа к внешним серверам имен.
Принцип работы программы sendmail
Sendmail отправляет почту в два приема: сначала почтовые сообщения собираются в очереди, а затем отсылаются.
Каждое сообщение состоит из трех частей: конверта, заголовка и тела сообщения.
Конверт. Конверт состоит из адреса отправителя, адреса получателя и информации рассылки, которая используется программами подготовки, рассылки и получения почты. Конверт остается невидимым для отправителя и получателя почтового сообщения.
Заголовок. Заголовок состоит из стандартных текстовых строк, которые содержат адреса, информацию о рассылке и данные. Заголовок может быть частью подготовленного пользователем текстового файла, а может быть подготовлен и добавлен к телу сообщения программой подготовки почты. Данные из заголовка могут быть использованы для оформления конверта сообщения.
Тело сообщения. Первая пустая строка в файле почтового сообщения отделяет заголовок от тела сообщения. Все, что следует после этой строки, называется телом сообщения и передается по почте без изменений.
Sendmail может быть вызвана:
программой подготовки сообщений для отправки уже подготовленных сообщений;
программой получения почты для пересылки полученной из сети почты;
непосредственно пользователем для отправки по почте файла или короткого сообщения;
почтовым демоном, которым обычно является сама sendmail.
После того, как почта собрана, начинается ее рассылка. При этом выполняются следующие действия:
адреса отправителя и получателя преобразуются в формат сети-получателя почты;
если необходимо, то в заголовок сообщения добавляются строки, позволяющие получателю отвечать на принятое сообщение (например: FROM: <адрес>);
почта передается одной из программ рассылки почты.
На рисунке 3.1 представлена схема функционирования почтового сервера на базе программы sendmail.
Когда программа приема почты получает сообщение, она передает его программе sendmail для последующей рассылки. Если сообщение достигло машины адресата, то оно отправляется программой местной рассылки в почтовый ящик пользователя.
Первый этап рассылки - сбор сообщений. Sendmail получает почтовые сообщения из трех источников:
командной строки или стандартного ввода;
через SMTP-протокол (из сети);
из очереди сообщений.
При получении сообщений из командной строки или стандартного ввода, sendmail вызывается пользователем с указанием адреса доставки сообщения. При этом выполняются следующие действия: определяется адрес отправителя, выбирается из командной строки адрес получателя и оба адреса преобразуются в соответствии с описанием файла конфигурации, определяется способ доставки сообщения, размещается заголовок в оперативной памяти для последующих преобразований, а тело сообщения размещается во временном файле для отправки без изменений.
При получении сообщений по протоколу SMTP, sendmail используется как программа клиента и сервера протокола. Протокол определен в RFC-821 и является основным для рассылки почты в Internet. В этом случае sendmail запускается как демон, который "слушает" порт TCP и в случае получения сообщения устанавливает соединение с удаленным клиентом SMTP. Как правило, таким клиентом является другая программа sendmail.
Программа подготовки почты на локальной машине также может использовать SMTP. Для этого sendmail открывает канал (pipe) межпроцессного обмена.
При получении сообщений из очереди используются временные файлы очередей. Эти очереди используются для хранения неразосланных сообщений. Сообщение хранится в двух файлах. В одном файле хранится тело сообщения, а в другом конверт и заголовок сообщения. Обычно sendmail опрашивает очереди через определенные администратором почтового сервера промежутки времени, на предмет наличия в них неразосланных сообщений.
Рис. 3.1. Схема почтового взаимодействия на базе программы Sendmail
Вторая стадия рассылки почты - рассылка сообщений.
Как только одним из описанных выше способов sendmail получила сообщение, делается попытка его отправить по адресу. Для этого sendmail определяет три параметра: программу рассылки, узел сети и получателя. Эта процедура производится по правилам, которые содержатся в файле конфигурации. Sendmail сохраняет одну копию тела сообщения во временном файле, а заголовок загружает в оперативную память. Для каждого сообщения программа доставки (рассылки) сообщений вызывается отдельно. Если сообщение должно быть доставлено на разные машины, то для каждой из машин также вызывается своя программа доставки. Некоторые программы могут обслуживать сразу несколько абонентов одной машины, если это невозможно, то для каждого абонента вызывается также своя программа доставки. Рассматривают два типа рассылки: на удаленную машину и местную рассылку.
Рассылка на удаленную машину. Для вызова программы рассылки sendmail открывает pipe и запускает программу рассылки, командная строка которой находится в файле конфигурации. Sendmail записывает заголовок и тело сообщения в pipe. Если программа рассылки не использует протокол SMTP, то адрес получателя передается через pipe. Если используется SMTP, то открывается двунаправленный канал для интерактивного взаимодействия с удаленным сервером SMTP. Если в качестве транспортного протокола используется TCP, то sendmail не запускает внешнюю программу рассылки, а сама инициирует TCP-соединение с удаленным сервером SMTP.
Доставка местной почты. Если sendmail определяет, что адреса доставки местные, то происходит обращение к файлу адресных синонимов и производится преобразование адресов (расширение). Файл адресных синонимов можно использовать для перенаправления почты в файлы или для обработки местными программами. Пользователь может иметь и свой собственный файл адресных синонимов для управления рассылкой персональной почты. После преобразования адресов почта отправляется программе местной рассылки (например rmail).
Важным моментом при работе sendmail является алгоритм определения типа адресов. При использовании стандартного файла конфигурации применяются следующие правила: почта рассылается в соответствии с форматом адреса получателя, адреса при этом бывают местные, UUCP и SMTP.
Местные адреса имеют вид:
user user@localhost user@localhost.localdomain user@alias user@alias.localdomain user@[local.host.internet.address] localhost!user localhost!localhost!user user@localhost.uucp
Местный адрес - это адрес, который распознается как адрес машины, с которой осуществляется отправка почты.
Адреса UUCP имеют вид:
host!user host!host!user user@host.uucp
Если машина, с которой отправляется почта, имеет прямую линию связи по протоколу UUCP со следующей машиной (в адресе), то почта передается на эту машину, если такого соединения нет, то почта не рассылается и выдается сообщение об ошибке. Файл конфигурации должен содержать детальное описание маршрутов для пересылки сообщений на машины по протоколу UUCP.
Адреса SMTP - это адреса, описанные в стандарте RFC-822 или стандартные адреса Internet. Эти адреса имеют вид:
usr@host usr@host.domain <@host1,@host2,@host3:user@host4> user@[remote.host`s.internet.address]
Почта с адресами SMTP рассылается по протоколу SMTP.
Если в системе для адресации используется Berkeley Internet Name Domain (BIND) сервер, то sendmail может определять адреса получателей, используя сервис BIND. Если BIND не используется, то sendmail сама определяет адреса.
При рассылке почты можно использовать и смешанную адресацию:
user%hostA@hostB - почта отправляется с машины hostB на машину hostA user!hostA@hostB - почта отправляется с машины hostB на машину hostA hostA!user%hostB - почта отправляется с hostA на hostB
Подводя итог обсуждению принципов работы sendmail, следует специально подчеркнуть тот факт, что почта реально рассылается двумя принципиально разными способами. При использовании протокола UUCP почта рассылается по принципу "stop-go", т.е. сообщения передаются от машины к машине по указанному в адресе пути. Следует ясно представлять, если почта ушла с машины отправителя, то это не означает, что она поступит получателю. Промежуточная машина может вернуть почту назад, если не сможет разослать. Электронная почта действительно работает как система обычной почты, физически перемещая и храня сообщения на промежуточных почтовых станциях. При работе по протоколу SMTP почта реально отправляется только тогда, когда установлено интерактивное соединение с программой-сервером на машине-получателе почты. При этом происходит обмен командами между клиентом и сервером протокола SMTP в режиме on-line. При смешанной адресации доставка почты происходит по смешанному сценарию. Как шла доставка и как маршрутизировалось сообщение можно определить из заголовка сообщения, которое вы получили.
Анализ типа адресов в программе sendmail - это самый главный процесс, т.к. по типу адреса получателя sendmail определяет каким способом сообщение будет разослано. Вызов программы доставки вмонтирован в правила преобразования адресов отправителя и получателя. При этом как только система решит, что дальнейшее преобразование адреса нецелесообразно, так сразу вызывается программа доставки. Наибольшее число сообщений об ошибках при рассылке сообщений связано как раз с определением адреса получателя. В этом процессе принимают участие, по крайней мере, два сервиса Internet: система рассылки почтовых сообщений и служба доменных имен. Sendmail постоянно обращается к службе доменных имен на предмет канонизации имен электронной почты сверяет эти имена с теми, которые закреплены за компьютером, на котором данная система установлена. Если имена совпадают, то осуществляется местная рассылка по адресам местной почты.
Назад | Содержание | Вперед
Программное обеспечение доступа к FTP-архивам
Для работы с Ftp-архивами необходимо следующее программное обеспечение: сервер, клиент и поисковая программа. Сервер обеспечивает доступ к ресурсам архива из любой точки сети, клиент обеспечивает доступ пользователя к любому архиву в сети, а поисковая система обеспечивает навигацию во всем множестве архивов сети.
В разных операционных системах эти компоненты Ftp-обмена изменяются как по форме, так и по возможностям, но некоторые общие принципы остаются, кроме этого, программы, ориентированные на интерфейс командной строки, по большей части остаются неизменными в разных операционных средах.
Назад | Содержание | Вперед
Программное обеспечение почтового обмена
Согласно схеме почтового обмена (рисунок 2.1) взаимодействие между участниками этого обмена строится по классической схеме "клиент-сервер". При этом схему можно подразделить на несколько этапов. Первый - взаимодействие по протоколу SMTP между почтовым клиентом (Internet Mail, Netscape Messager, Eudora и т.п.) и почтовым транспортным агентом (sendmail, smail, ntmail и т.п.), второй - взаимодействие между транспортными агентами в процессе доставки почты получателю, результатом которого является доставка почтового сообщения в почтовый ящик пользователя и третий - выборка сообщения из почтового ящика пользователя почтовым клиентом в почтовый ящик пользователя на машине пользователя по протоколу POP3 или IMAP.
Назад | Содержание | Вперед
Протокол FTP (File Transfer Protocol)
FTP (File Transfer Protocol или "Протокол Передачи Файлов") - один из старейших протоколов в Internet и входит в его стандарты. Обмен данными в FTP проходит по TCP-каналу. Построен обмен по технологии "клиент-сервер". На рисунке 4.2 изображена модель протокола.
Рис. 4.2. Модель протокола
В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора пользователя средствами.
Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.
Сессия управления инициализирует канал передачи данных. При организации канала передачи данных последовательность действий другая, отличная от организации канала управления. В этом случае сервер инициирует обмен данными в соответствии с параметрами, согласованными в сессии управления.
Канал данных устанавливается для того же host'а, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.
Возможна ситуация, когда данные могут передаваться на третью машину. В этом случае пользователь организует канал управления с двумя серверами и организует прямой канал данных между ними. Команды управления идут через пользователя, а данные напрямую между серверами (рисунок 4.3).
Канал управления должен быть открыт при передаче данных между машинами. В случае его закрытия передача данных прекращается.
Рис. 4.3. Соединение с двумя разными серверами и передача данных между ними
Назад | Содержание | Вперед
Протокол IMAP
Другим протоколом разбора почты является протокол IMAP (Interactive Mail Access Protocol), который по своим возможностям очень похож на POP3, но был разработан как более надежная альтернатива последнего и к тому же обладает более широкими возможностями по управлению процессом обмена с сервером.
Работа протокола осуществляется по 143 потру TCP. Главным отличием от POP является возможность поиска нужного сообщения и разбор заголовков сообщения.
Ниже приведен пример взаимодействия по протоколу IMAP
OK IMAP2 Server Ready A001 LOGIN Fred Secret A001 OK User Fred logged in A002 SELECT INBOX * FLAGS (Meeting Notice \Answered \Flagged \Deleted \Seen) * 19 Exists * 2 Recent * A002 OK Select compete A003 FETCH 1:19 ALL * 1 Fetch ( ..... * 19 Fetch (.... A003 OK Fetch complete A004 LOGOUT * Bye IMAP2 server quitting A004 OK Logout complete
Для поиска информации используются команды FIND с различными аргументами.
Назад | Содержание | Вперед
Протокол POP(Post Office Protocol)
Протокол обмена почтовой информацией POP3 предназначен для разбора почты из почтовых ящиков пользователей на их рабочие места при помощи программ-клиентов. Если по протоколу SMTP пользователи отправляют корреспонденцию через Internet, то по протоколу POP3 пользователи получают корреспонденцию из своих почтовых ящиков на почтовом сервере в локальные файлы.
Назад | Содержание | Вперед
Протокол 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: paul@quest.polyn.kiae.su
Следующей командой определяется адрес получателя:
RCPT TO: paul@apollo.polyn.kiae.su
После того, как определен отправитель и получатель почтового сообщения, можно отправлять последнее:
DATA
Команда DATA вводится без параметров и идентифицирует начало ввода почтового сообщения. Сообщение вводится до тех пор, пока не будет введена строка с точкой в первой позиции. Согласно стандарту почтового сообщения RFC822 отправитель передает заголовок и тело сообщения, которые разделены пустой строкой. Сам протокол SMTP не накладывает каких-либо ограничений на информацию, которая заключена между командой DATA и "." в первой позиции последней строки. Приведем пример обмена сообщениями при дисциплине отправки почты:
S: MAIL FROM: <paul@quest.polyn.kiae.su> R: 250 Ok S: RCPT TO: <dobr@kiae.su> 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 <user@domain.domain>
Если сервер может сделать только предположение о дальнейшей рассылке, то ответ будет несколько иным:
R: 551 User not local; please try <user@host.domain>
Верификация и расширение адресов составляют дисциплину верификации. В ней используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие или отсутствие указанного пользователя:
S: VRFY paul R: 250-Paul Khramtsov<paul@quest.polyn.kiae.su>
Используя команду EXPN можно получить список местных пользователей:
S: EXPN Example-People R: 250-Paul Khramtsov<paul@quest.polyn.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:JOE@host.domain> R: 250 Ok S: DATA R: 354 send the mail data, end with . S: Date 23 Oct 95 11:23:30 S: From: SMTP@remote.domain S: To: <JOE@host.domain> 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 и может посмотреть реакцию удаленной машины на его действия.
Назад | Содержание | Вперед
Режимы обмена данными
В протоколе большое внимание уделяется различным способам обмена данными между машинами различных архитектур. Действительно, чего только нет в Internet, от персоналок и Mac'ов до суперкомпьютеров. Все они имеют различную длину слова и многие различный порядок битов в слове. Кроме этого, различные файловые системы работают с разной организацией данных, которая выражается в понятии метода доступа.
В общем случае, с точки зрения FTP, обмен может быть поточный или блоковый, с кодировкой в промежуточные форматы или без нее, текстовый или двоичный. При текстовом обмене все данные преобразуются в ASCII и в этом виде передаются по сети. Исключение составляют только данные IBM mainframe, которые по умолчанию передаются в EBCDIC, если обе взаимодействующие машины IBM. Двоичные данные передаются последовательностью битов или подвергаются определенным преобразованиям в процессе сеанса управления. Обычно, при поточной передаче данных за одну сессию передается один файл данных, а при блоковом способе за одну сессию можно передать несколько файлов.
Описав в общих чертах протокол обмена, можно перейти к описанию средств обмена по протоколу FTP. Практически для любой платформы и операционной среды существуют как серверы, так и клиенты. Ниже описываются стандартные сервер и клиент Unix-подобных систем.
Назад | Содержание | Вперед
Сервер протокола - программа ftpd
Команда ftpd предназначена для обслуживания запросов на обмен информацией по протоколу FTP. Сервер обычно стартует в момент загрузки компьютера. Синтаксис запуска сервера следующий:
ftpd [-d] [-1] [-t timeout]
d - опция отладки;
1 - опция автоматической идентификации пользователя;
t - время пассивного ожидания команд пользователя.
Каждый сервер имеет свое описание команд, которое можно получить по команде help. Автоматическая идентификация пользователей осуществляется при помощи файла /etc/passwd. Пароль пользователя не должен быть пустым.
Существует специальный файл, в котором содержатся запрещенные пользователи, т.е. те, кому обслуживание по протоколу FTP запрещено. Возможен вход в архив по идентификатору пользователя anonimous
или ftp. В этом случае сервер принимает меры по ограничению доступа к ресурсам компьютера для данного пользователя. Обычно для таких пользователей создается специальная директория ftp, в которой размещают каталоги bin, etc и pub. В каталоге bin размещаются команды, разрешенные для использования, а в каталоге pub собственно сами файлы. Каталог etc закрыт для просмотра пользователем и в нем размещены файлы идентификации пользователей.
Назад | Содержание | Вперед
Спецификация 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). Остановимся подробнее на форме и назначении полей, определяемых стандартом.
Поле версии MIME (MIME-Version)
Поле версии указывается в заголовке почтового сообщения и позволяет определить программе рассылки почты, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как:
MIME-Version: 1.0
Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.
Поле типа содержания тела почтового сообщения (Content-Type)
Поле типа используется для описания типа данных, которые содержатся в теле почтового сообщения. Это поле сообщает программе чтения почты какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании/декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудио информация (audio); фильм или видео (video); приложение (application). Общая форма записи поля выглядит в записи Бекуса-Наура как:
Content-Type:= type "/" subtype *[";" parameter] type := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / x-token x-token := <Два символа "X-", за которыми без пробела следует последовательность любых символов> subtype := token parameter:= attribute "=" value attribute:= token value := token / quoted-string token := 1*<любой символ кроме пробела и управляющего символа, или tspecials> tspecials:= "(" /")" / "<" / ">" / "@" ; Обязательно / "," / ";" / ":" / "\" / <"> ; должны быть, / "/" / "[" / "]" / "?" / "." ; заключены в / "=" ; кавычки.
Остановимся подробнее на каждом из типов, разрешенных стандартом MIME.
Text. Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа "text" является "plain", что обозначает так называемый планарный текст. Понятие планарного текста появилось в связи с тем, что существует еще размеченный текст, т.е. текст со встроенными в него символами управления отображением, и гипертекст, т.е. текст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип "richtext", а для обозначения гипертекста подтип "html". Вообще говоря, "html" - это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World Wide Web, которая получила в последнее время широкое распространение в Internet. Понятие размеченного текста требует более подробного обсуждения, так как его передача и интерпретация являются одной из причин появления стандарта MIME.
"Richtext" определяет текст со встроенными в него специальными управляющими последовательностями, которые в соответствии со стандартом языка разметки документов SGML называются тагами. Таги представляют из себя последовательность символов типа "<строка-символов>". "Строка-символов" определяет управляющее действие. Таги делятся на таги начала элемента текста ("<......>") и таги конца элемента текста ("</......>"). В качестве примера такой разметки можно привести следующий фрагмент текста:
<bold>Now</bold> is the time for <italic>all</italic> good men <smaller>(and <lt>women>)</smaller> to <ignoreme></ignoreme> come to the aid of their <nl>
В этом фрагменте <bold> означает выделение "жирным" шрифтом, <italic> - курсив, <smaller> - мелкий шрифт, <lt> - знак "<", игнорирование обозначено как <ignoreme>, новая строка как <nl>.
Специальный тип разметки задается подтипом "html". Это так называемый гипертекст. Разметка гипертекста строится по тому же принципу как и в тексте типа "richtext". Однако применяются таги, позволяющие описать гипертекстовые ссылки. К таким тагам относятся "<A HREF="......">.....</A>", <IMG ....>, <A NAME="...."></A>. Таг "<A HREF="......"> .......</A> определяет следующий фрагмент текста, который будет просматриваться. При этом текст между тагом начала и тагом конца будет выделен в программе просмотра цветом или другим способом и используется как контекстная гипертекстовая ссылка. Таг <IMG .....> задет встроенный в текст документа графический образ. В некотором смысле этот таг аналогичен "multipart", который разрешает комбинировать сообщение из нескольких фрагментов разного типа. Таг <A NAME...> определяет "якорь", т.е. место внутри документа, на которое можно сослаться как на метку. В качестве примера такой разметки текста можно привести следующий фрагмент:
Это пример разметки документа в формате HTML. <H1>Это заголовок документа</H1> <P> - Это параграф. <A HREF="test.html#mark1"> Это пример гипертекстовой ссылки.</A> <IMG SRC="test.gif" ALIGN=Bottom> Это встроенный image. <A NAME="mark1"></A> Это "якорь" внутри текста документа.
"Multipart". Этот тип содержания тела почтового сообщения определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов.
Подтип "mixed" - задает сообщение, состоящее из нескольких фрагментов, которые разделены между собой границей, задаваемой в качестве параметра подтипа. Приведем простой пример:
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" This is the preamble. It is to be ignored, though it is a handy place for mail composers to include an explanatory note to non-MIME compliant readers. --simple boundary This is implicitly typed plain ASCII text. It does NOT end with a linebreak. --simple boundary Content-type: text/plain; charset=us-ascii This is explicitly typed plain ASCII text. It DOES end with a linebreak. --simple boundary-- This is the epilogue. It is also to be ignored.
В данном примере поле "Content-Type" определяет подтип "mixed" и границу между фрагментами, как строку "--simple boundary--". В начале каждого фрагмента может быть задана своя строка с полем "Content-Type". Как видно из примера, существует два фрагмента, которые не отображаются: преамбула и эпилог, в которые можно поместить комментарии.
Другим подтипом может быть подтип "alternative". Данный подтип позволяет организовать вариабельный просмотр почтового сообщения в зависимости от типа программы просмотра. Приведем пример:
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 1 фрагмент
Content-Type: text/plain; charset=us-ascii ...plain text version of message goes here.... --boundary42 2 фрагмент
Content-Type: text/richtext .... richtext version of same message goes here ... --boundary42 3 фрагмент
Content-Type: text/x-whatever .... fanciest formatted version of same message goes here ... --boundary42--
В этом примере для работы с планарным текстом при использовании алфавитно-цифровых программ просмотра предназначен первый фрагмент текста. Для просмотра размеченного текста используется второй фрагмент, для специальной программы просмотра может быть подготовлен специальный вариант (фрагмент 3).
Подтип "digest"
предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип:
From: Moderator-Address MIME-Version: 1.0 Subject: Internet Digest, volume 42 Content-Type: multipart/digest; boundary="---- next message ----" ------ next message ---- From: someone-else Subject: my opinion ...body goes here ... ------ next message ---- From: someone-else-again Subject: my different opinion ... another body goes here... ------ next message ------
Приведенный пример показывает как можно воспользоваться подтипом "digest" для рассылки почты разным пользователям и по-разному поводу, используя поля "From:"
и "Subject" в качестве частных заголовков.
Подтип "parallel"
предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра. Синтаксис такого сообщения аналогичен рассмотренным выше.
Тип "message". Данный тип предназначен для работы с обычными почтовыми сообщениями, которые однако не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа.
Подтип "partial"
предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя. Приведем пример передачи аудио сообщения разбитого на части:
X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: id1@host.com MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: anotherid@foo.com Content-type: audio/basic Content-transfer-encoding: base64 ... first half of encoded audio data goes here... and the second half might look something like this: From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: id2@host.com Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... second half of encoded audio data goes here...
Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number)
и общее число порций (total). Следует обратить внимание на то, что каждая часть имеет свое поле "Content-Type". Это означает, что все сообщение может состоять из частей разных типов.
Другим подтипом является "External-Body",
который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Этот подтип похож на гипертекстовую ссылку из типа "text".
Приведем конкретный пример:
From: Whomever Subject: whatever MIME-Version: 1.0 Message-ID: id1@host.com Content-Type: multipart/alternative; boundary=42 --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; access-type=ANON-FTP; directory="pub"; mode="image"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript --42 Content-Type: message/external-body; name="/u/nsb/writing/rfcs/RFC-XXXX.ps"; site="thumper.bellcore.com"; access-type=AFS expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript get rfc-xxxx doc --42--
В данном примере приведено использование "External-Body" и "multipart/alternative". Все сообщение разбито на несколько фрагментов. В каждом из фрагментов находится ссылка на внешний файл. Реально тела почтового сообщения нет (границы программами просмотра не отображаются). Однако если программа просмотра способна работать с внешними протоколами, то можно ссылки разрешить автоматически, запуская соответствующий сервис.
Стандартным подтипом типа "message" является "rfc822".
Данный подтип определяет сообщения стандарта RFC822.
Типы описания нетекстовой информации. Таких типов имеется четыре:
"image" для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG.
"audio" для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.
"video" для передачи фильмов. Наиболее популярным является формат MPEG.
"application" для передачи данных любого другого формата, обычно используется для передачи двоичных данных для последующего промежуточного преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип "application". Основной подтип данного типа - "octet-stream", но существуют "ODA" и "Postscript".
Назначение данных типов ясно из названия - обозначение данных для последующей обработки как данных в форматах, определяемых подтипом.
Поле типа кодирования почтового сообщения (Content-Transfer-Encoding). Многие данные передаются по почте в их исходном виде. Это могут быть 7bit символы, 8bit символы, 64base символы и т.п. Однако при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде - US-ASCII. Для этого существуют процедуры кодирования такого сорта данных. Наиболее широко применяемая - uuencode. Для того, чтобы при получении данные были бы правильно распакованы и введено в стандарт поле "Сontent-Transfer-Encoding". Синтаксис этого поля следующий:
Content-Transfer-Encoding:= "BASE64" / "QUOTED-PRINTABLE" / "8BIT" / "7BIT" / "BINARY" / x-token
Каждая из альтернатив применяется в своем подходящем случае. Альтернативы "8bit", "7bit", "BINARY" реально никакого преобразования не требуют, так как почта передается байтами и SMTP не делает различия между ними. Однако они введены для строгости описания типов. "BASE64" обычно используется в связке с типом "text/ISO-8859-1", "x-token" позволяет пользователю описать свою процедуру преобразования.
Дополнительные необязательные поля. Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "Content-ID"
и "Content-Description". Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария содержания. Ни то, ни другое программами просмотра обычно не отображаются.
В заключении обсуждения стандарта MIME комплексный пример без комментариев:
MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@bellcore.com> Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 ...Some text appears here... [Note that the preceding blank line means no header fields were given and this is text, with charset US ASCII. It could have been done with explicit typing as in the next part.] --unique-boundary-1 Content-type: text/plain; charset=US-ASCII This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts. --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... base64-encoded 8000 Hz single-channel u-law-format audio data goes here.... --unique-boundary-2 Content-Type: image/gif Content-Transfer-Encoding: Base64 ... base64-encoded image data goes here.... --unique-boundary-2-- --unique-boundary-1 Content-type: text/richtext This is <bold><italic>richtext.</italic></bold> <nl><nl>Isn't it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (name in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Additional text in ISO-8859-1 goes here ... --unique-boundary-1--
Подводя итоги обсуждения, еще раз следует отметить, что стандарт MIME позволяет расширить область применения электронной почты, обеспечить доступ к другим информационным ресурсам сети в стандартных форматах.
Назад | Содержание | Вперед
Тестирование обслуживания по протоколу SMTP
Для проверки сервиса SMTP применяют программу telnet, запущенную по порту 25:
citmgu> telnet server.citmgu.ru 25
В этом случае система отвечает строкой приглашения протокола SMTP, после чего можно вводить команды SMTP и проверять реакцию системы на них:
# telnet citmgu.ru 25 Trying 194.85.135.66... Connected to citmgu.ru. Escape character is '^]'. 220 cit-u.citmgu.ru ESMTP Sendmail 8.8.5/8.8.5; Mon, 30 Jun 1997 09:45:55 GMT help 214-This is Sendmail version 8.8.5 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214- sendmail-bugs@sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info MAIL FROM: paul 250 paul... Sender ok RCPT TO: paul 250 paul... Recipient ok DATA 354 Enter mail, end with "." on a line by itself This is a test message . 250 JAA24836 Message accepted for delivery quit 221 cit-u.citmgu.ru closing connection Connection closed by foreign host. You have new mail. #
В приведенном здесь сеансе сначала пользователь выдал команду help и получил список команд, которые можно использовать при взаимодействии по протоколу SMTP. Затем пользователь выдал команду MAIL FROM: для указания адреса отправителя почтового сообщения. После этого выдана команда RCPT TO:, и указан адрес получателя почтового сообщения. Команда DATA
открывает возможность ввода почтового сообщения, т.е. клиент из режима командной строки переходит в режим редактирования сообщения. Редактировать можно только в пределах одной строки путем затирания символом забоя предварительно набитых символов. Вернуться на строку выше нельзя. Конец режима редактирования обозначается символом "." в первой позиции строки. После этого клиент возвращается в режим командной строки, а сообщение отсылается. Совершенно очевидно: что за один сеанс можно отправить несколько сообщений как одному и тому же адресату, так и разным адресатам на одном и том же компьютере. Посылать сообщения можно через другую машину, если в качестве адреса получателя указать что-либо подобное ниже приведенному:
paul%quest.polyn.kiae.su@citmgu.ru
В этом случае сообщение отправляется на citmgu.ru, а затем оно будет переправлено на quest.polyn.kiae.su.
Назад | Содержание | Вперед
Тестирование отправки почты программой Sendmail - флаг "-v"
Для того чтобы убедится, что почта уходит туда куда вы предполагаете можно, запустить sendmail из командной строки в так называемом verbowse режиме, т.е. когда диалог между транспортными агентами (двумя программами sendmail) трассируется на экране монитора или записывается в файл. Некоторые грубые ошибки в настройке sendmail можно таким образом установить, например зацикливание при локальной рассылке.
% sendmail -v paul@citmgu.ru Test . paul@citmgu.ru... Connecting to local... paul@citmgu.ru... Sent % sendmail -v paul@quest.net.kiae.su Test . paul@quest.net.kiae.su... Connecting to quest.net.kiae.su. via esmtp... 220 quest.net.kiae.su ESMTP Sendmail 8.7.5/8.7.3; Mon, 30 Jun 1997 11:36:31 +040 0 (MSD) >>> EHLO cit-u.citmgu.ru 250-quest.net.kiae.su Hello [194.85.135.66], pleased to meet you 250-EXPN 250-8BITMIME 250-SIZE 250-DSN 250-VERB 250-ONEX 250 HELP >>> MAIL From:<paul@cit-u.citmgu.ru> SIZE=5 250 <paul@cit-u.citmgu.ru>... Sender ok >>> RCPT To:<paul@quest.net.kiae.su> 250 Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 LAA07168 Message accepted for delivery paul@quest.net.kiae.su... Sent (LAA07168 Message accepted for delivery) Closing connection to quest.net.kiae.su. >>> QUIT 221 quest.net.kiae.su closing connection %
В этом примере сначала тестируется локальная рассылка, а затем проверяется удаленная рассылка почты. Если бы на локальной машине существовал скрытый цикл, то программа выдала бы предупреждение о возможных ошибках в файле конфигурации sendmail. Однако чаще всего эти ошибки связаны с настройками named, а не sendmail.
Назад | Содержание | Вперед
взаимодействие по протоколу POP3 можно
ормально, взаимодействие по протоколу POP3 можно разделить на две фазы: фазу аутентификации и фазу обмена данными. В фазе аутентификации пользователь должен сообщить свой идентификатор и пароль. Если аутентификация была произведена успешно, то система позволяет работать с домашним ящиком пользователя. Сам протокол POP3 очень похож на SMTP с той только разницей, что сообщения можно принимать но нельзя отправлять.
Приведем пример взаимодействия по протоколу POP3:
quest> telnet quest.net.kiae.su Trying 144.206.130.138... Connected to quest.net.kiae.su. Escape character is '^]'. +OK QPOP (version 2.2) at quest.net.kiae.su starting. <10124.867839706@quest.net.kiae.su> user paul +OK Password required for paul. pass Kukuru23432 +OK paul has 6 messages (12576 octets). stat +OK 6 12576 list +OK 6 messages (12576 octets) 1 1447 2 2640 3 2296 4 1100 5 3025 6 2068 . noop +OK last +OK 4 is the last read message. retr 4 +OK 1100 octets Received: from mail1.relcom.ru (mail1.relcom.ru [193.125.152.4]) by quest.net.kiae.su (8.7.5/8.7.3) with ESMTP id CAA09628 for <paul@quest.net.kiae.su>; Wed, 2 Jul 1997 02:51:43 +0400 (MSD) Received: from thevni (uucp@localhost) by mail1.relcom.ru (8.7.5.R.ML.S/Relcom-2A) with UUCP id BAA03544 for paul;Wed, 2 Jul 1997 01:34:45 +0400 (MSD) Received: by Relay1.relcom.ru (UUMAIL/2.0); Wed, 2 Jul 97 01:34:44 +0300 Received: by theor.vniinm.msk.su (UUPC/@ v5.06gamma, 07Feb93); Wed, 2 Jul 1997 01:24:57 +0400 To: paul@kiae.su References: <33B92C6B.9FA2C1A4@kiae.su> Message-Id: <AAeMNkpiq1@theor.vniinm.msk.su> Organization: A.A. Bochvar Institute for Inorganic Materials, Theoret From: "Alexander Z. Solontsov" <sol@theor.vniinm.msk.su> Date: Wed, 2 Jul 97 01:24:56 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: life Lines: 9 X-UIDL: 2313051b98ef908dceefe8b801d9e60d Status: RO
To: N.M.Sergeeva
Dear H.M.,
I am still alive, publishing a lot, and this year applied to RAN. Would be pleased to hear from you in a more derect way. Alexander
. dele 4 +OK Message 4 has been deleted. rset 4 -ERR Too many arguments for the rset command. rset +OK Maildrop has 6 messages (12576 octets) list +OK 6 messages (12576 octets) 1 1447 2 2640 3 2296 4 1100 5 3025 6 2068 . quit +OK Pop server at quest.net.kiae.su signing off. Connection closed by foreign host.
В данном примере используется все тот же прием доступа к серверу через программу Telnet по 110 порту TCP. В начале выдаются команды фазы аутентификации user и pass. Затем выдается команда stat, которя сообщает статус почтового ящика пользователя paul. По команде list система сообщает число сообщений и их размер в байтах. По команде retr можно получить текст сообщения. По команде dele пометить сообщение к удалению. Удаляются сообщения только в момент окончания сеанса, а во время сеанса они только помечаются как удаленные, поэтому по команде rset эти пометки можно снять. Команда Quit завершает сеанс работы с сервером.
Назад | Содержание | Вперед
Тестирование правил преобразования адресов
Для тестирования правил преобразования адресов sendmail запускают с флагом "-bt" для того, чтобы тестирование было более детальным, можно применять и ряд других флагов.
Пример тестирования набора правил 0 и его подправил.
% sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 paul@polyn.kiae.su rewrite: ruleset 0 input: paul @ polyn . kiae . su rewrite: ruleset 98 input: paul @ polyn . kiae . su rewrite: ruleset 98 returns: paul @ polyn . kiae . su rewrite: ruleset 97 input: paul @ polyn . kiae . su rewrite: ruleset 3 input: paul @ polyn . kiae . su rewrite: ruleset 96 input: paul < @ polyn . kiae . su > rewrite: ruleset 96 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 3 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 0 input: paul < @ polyn . kiae . su . > rewrite: ruleset 98 input: paul < @ polyn . kiae . su . > rewrite: ruleset 98 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 90 input: < polyn . kiae . su > paul < @ polyn . kiae . su . > rewrite: ruleset 90 input: polyn . < kiae . su > paul < @ polyn . kiae . su . > rewrite: ruleset 90 input: polyn . kiae . < su > paul < @ polyn . kiae . su . > rewrite: ruleset 90 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 90 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 90 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 95 input: < > paul < @ polyn . kiae . su . > rewrite: ruleset 95 returns: paul < @ polyn . kiae . su . > rewrite: ruleset 0 returns: $# esmtp $@ polyn . kiae . su . $: paul < @ polyn . kiae . su . > rewrite: ruleset 97 returns: $# esmtp $@ polyn . kiae . su . $: paul < @ polyn . kiae . su . > rewrite: ruleset 0 returns: $# esmtp $@ polyn . kiae . su . $: paul < @ polyn . kiae . su . > >
В этом примере четко виден порядок преобразования. Сначала производится канонизация имени, а затем его преобразование в соответствии с рассылкой. Набор правил 0 - это набор преобразования адресов получателей. После него принимается решение о рассылке почты.
Правила в данном случае указываются по их левой части и для правильного понимания необходимо иметь и тот фрагмент файла конфигурации sendmail, который тестируется.
Интерфейс mail
Самая простая и самая распространенная программа подготовки и отправки почты - это программа mail или ее аналог mailx. Для большинства современных пользователей mail покажется архаизмом времен, когда полноэкранные и графические интерфейсы еще не были даже задуманы. Однако, попробовать mail имеет смысл, т.к. ограничения mail на размер файлов не столь жесткие как в полноэкранных интерфейсах типа bml и принцип работы программы более прозрачен, чем принципы работы ее современных аналогов. Для отправки почты самому себе следует набрать следующую строку:
mail paul
В качестве paul укажите свой почтовый адрес. В ответ программа выдаст предложение ввести сообщение:
Subject:
Если это тестовое сообщение, лучше всего ввести слово "test". Теперь программа перейдет на следующую строку и будет ждать текста сообщения. Следует учесть, что при редактировании в mail можно использовать только стирание стоящей перед курсором буквы и только в пределах текущей строки. Если пользователь нажал клавишу Enter, то весь текст выше текущей строки недоступен для редактирования. Пусть сообщение будет состоять из одной фразы:
This is a test message.
Для завершения ввода сообщения следует нажать Cntrl+D, что означает конец ввода. После этого сообщение будет отправлено. Окончить ввод сообщения можно и другим способом - ввести строку, которая содержит только символ "." в первой позиции.
Прочитать его можно выполнив программу mail без аргумента:
В этом случае на экране появится что-то вроде:
Mail version 5.5 6/1/90. Type ? for help "/var/mail/paul": 1 message 1 new >N 1 paul Sun Feb 5 15:21 11/246 &
Первая строка указывает на версию программы, вторая строка показывает место почтового ящика пользователя и количество сообщений в нем, при этом указывается отдельно число новых сообщений. Третья строка - это начало списка полученных почтовых сообщений. Буква "N" в начале строки указывает на то, что это новое сообщение, "1" - номер по порядку в почтовом ящике, paul - адрес отправителя, "Sun Feb 5 15:21" - дата и время отправки сообщения, "11/246" - указывает на число строк в сообщении и число байтов, которые составляют сообщение. Для просмотра сообщения следует просто нажать Enter. На экране появится:
Message 1: From paul Sun Feb 5 15:21:57 1995 Date: Sun, 5 Feb 95 15:21:57 -0700 From: paul To: paul Subject: test This is a test message. &
Как можно заметить, текст сообщения содержит дополнительную информацию, которая была добавлена программами рассылки и называется заголовком почтового сообщения. Заголовок отделен от сообщения пустой строкой. Из заголовка можно понять, кто и когда отправил сообщение.
Фактически, mail без аргументов просматривает почтовый ящик пользователя. Если в нем находятся другие сообщения, отличные от тестового сообщения пользователя, то это значит, что к пользователю пришла почта от других пользователей сети, или программ. Для прекращения просмотра сообщений, следует после знака "&" ввести символ "q".
Для отправки файла программой mail следует указать этот файл в качестве файла стандартного ввода:
mail paul < file.in
В этом случае файл будет немедленно отправлен адресату.
Следует заметить, что от системы к системе синтаксис команды mail может незначительно меняться. Так, в системе HP/UX 9.0, mail не предлагает ввести тему сообщения, аналогично ведет себя mail и системе BSDI/386 0.9. Однако mailx из HP/UX 9.0 практически аналогична mail из BSDI/386 0.9. В любом случае имеет смысл обратиться к руководству по командам операционной системы.
Важным моментом при использовании mail является его использование в качестве фильтра:
uuencode test.exe test.exe | mail paul@quest.polyn.kiae.su
В приведенном выше примере бинарный файл test.exe предварительно кодируется программой uuencode в файл ASCII, а затем отправляется пользователю paul на машине quest.polyn.kiae.su.
Рассмотрим теперь более современные интерфейсы подготовки почтовых сообщений bml и elm. Обе эти программы подготовки почты работают в режиме полноэкранных интерфейсов.
Интерфейс bml
Программа bml является стандартной для абонентов сети Relcom. Она входит в комплект версии для пользователей MS-DOS и имеется во многих Unix-системах сети. Для лучшей наглядности лучше обратиться к рисунку 3.4.
Рис. 3.4.
Экран в bml делится на три части:
верхняя часть экрана занята падающими меню, позволяющими редактировать, просматривать и отправлять почту;
в средней части экрана расположено рабочее поле программы, в котором отображается список полученных сообщений и осуществляется редактирование посылаемых сообщений;
в нижней части экрана расположено вспомогательное меню функциональных клавиш.
При запуске программы в рабочем поле отображаются полученные сообщения, первое из которых выделено цветом. Выделенное цветом сообщение - это текущее сообщение. При этом рабочее поле разбито на четыре столбца. В первом столбце указывается адрес отправителя, во втором - дата и время получения, в третьем - число строк и символов в сообщении, четвертый столбец - тема сообщения. Для просмотра сообщения надо при помощи клавиш-стрелок сделать интересующее пользователя сообщение текущим и нажать Enter. В рабочем поле экрана появится текст сообщения (рисунок 3.5).
Рис. 3.5.
Для редактирования и подготовки сообщений следует воспользоваться режимами Create Mail и Edit mail из падающего меню Mail (рисунок 3.6).
Рис. 3.6.
Для перехода в падающее меню используется функциональная клавиша F9. Для отправки сообщения из режима редактирования следует нажать ALT+T или выйти в меню Post. При отправке почты следует заполнить специальную форму (рисунок 3.7).
Bml предоставляет еще ряд возможностей, облегчающих прием, просмотр и отправку почты (поддерживает список часто используемых адресов, посылку сообщений в телеконференции Usenet, автоматическую вставку двоичных файлов в формате uuencode и их автоматическое извлечение из полученных сообщений и ряд других). В целом, следует признать, что bml является достаточно удобным персональным средством работы с почтой.
Рис. 3.7.
Интерфейс elm
Наиболее распространенной программой работы с почтой в Unix-системах является программа elm. Elm также, как и bml, является полноэкранным почтовым интерфейсом. Запуск программы осуществляется по команде elm:
elm
На экране появляется сообщение о версии системы, список полученных сообщений и список команд, которыми может воспользоваться пользователь. Следует обратить внимание на то, что некоторые версии elm способны подстраиваться под размер экрана автоматически. Пример экрана elm представлен на рисунке 3.8.
Рис. 3.8.
Нажимая клавиши "j" и "k", можно перемещаться вверх и вниз по списку полученных сообщений, а при нажатии клавиши Enter пользователь переходит к просмотру полученного сообщения. Для реализации других возможностей elm пользователь вводит в командной строке после слова "Command:" соответствующую букву, например, для отправки сообщения следует ввести букву "М". Вслед за этим появится приглашение ввести адрес получателя, тему письма и возможных дополнительных адресатов. Затем elm вызовет внешний редактор (обычно vi). После того, как пользователь завершил редактирование письма и вышел из редактора, elm еще раз удостоверяется в том, что письмо следует отправить по указанному адресу и, если получает подтверждение, то отправляет его.
При работе c elm следует обратить внимание на тот факт, что при выполнении команды delete, письма реально не удаляются, а только помечаются как удаленные. Реальная очистка почтового ящика происходит только при выходе из программы и только по подтверждению пользователя.
Интерфейс Eudora
Интерфейс Eudora является одним из множества почтовых интерфейсов, ориентированных на работу с почтой Internet из системы MS-Windows. На примере этого интерфейса мы рассмотрим типичные проблемы, которые возникают у пользователей персональных компьютеров при подключении к почтовому сервису Internet, и пути их решения.
Первой проблемой является тот факт, что компьютер выключается из сети на время отсутствия пользователя. Это значит, что в это время прием почтовых сообщений не производится. Следовательно, вся почта должна хранится на почтовом сервере и получаться пользователем по его запросу. При работе с Unix об этом заботится программа sendmail, в MS-Windows такой программы нет (точнее есть, но она не ориентирована на Internet). Поэтому обычно применяется следующая схема (рисунок 3.9):
Рис. 3.9. Схема работы с почтовым сервером из-под MS-Windows и MS-DOS
Такая схема предполагает, что пользователь имеет почтовый ящик на машине-сервере, которая не выключается круглосуточно. Все почтовые сообщения складываются в этот почтовый ящик. По мере необходимости, пользователь из своего почтового клиента обращается к почтовому ящику и забирает из него пришедшую на его имя почту. При отправке программа-клиент обращается непосредственно к серверу рассылки почты и передает отправляемые сообщения на этот сервер для дальнейшей рассылки.
На рисунке 3.10 приведен экран Eudora, на котором представлено меню настройки и два почтовых ящика: принятых писем и отправленных писем.
На этом рисунке в меню настроек хорошо виден POP Account - адрес пользователя на машине-сервере, SMTP-сервер и POP (Ph) сервер. Как видно из настроек, Eudora каждые 30 минут проверяет почтовый ящик пользователя и сообщает о получении новых писем. Кроме того, что Eudora позволяет читать просто письма в обычном почтовом формате Internet (RFC822), о котором пойдет речь в следующем параграфе, она распознает и новый формат, ориентированный на отображение мультимедийных почтовых сообщений MIME, который последнее время становится все более популярен в Internet.
Рис. 3.10. Интерфейс Eudora для MS-Windows
Для установки этого интерфейса требуются определенные знания и доступ к информации, которой располагает только системный администратор, поэтому предпочтительней обратиться именно к нему с просьбой об установке программы или за необходимой информацией (адреса машин серверов). Работа с Eudora чрезвычайно проста: надо выбирать при помощи мыши или клавиатуры интересующие вас сообщения и отправлять в "корзину" то, что бесполезно.
И последнее замечание относительно работы из под MS-Windows с почтой в Internet. Если пользователь пишет только по-английски, то у него нет проблем с кодировкой и набором текста, но если он пишет по-русски и получает такие же сообщения, то сразу же возникают проблемы. Дело в том, что большинство почтовых сетей для обмена данными между серверами используют кодировку KOI8. Эта кодировка отличается как от кодировки для MS-DOS, так и от кодировки MS-Windows. Поэтому, возвращаясь к иллюстрации с настройками интерфейса Eudora, хочется обратить внимание читателя на поля "Send Font" и "Printer Font". В этих полях указан шрифт "Arial-Relcom", который разложен по кодировке KOI8, и используется для отображения и печати почтовых сообщений. Для того, чтобы правильно набирать сообщения, следует к стандартным раскладкам клавиатуры в драйвере клавиатуры (cyrwin, например) добавить раскладку для KOI8.
При этом драйвер должен уметь менять раскладку по мере необходимости. В противном случае у пользователя будет возможность читать сообщения, но не набирать их.
Назад | Содержание | Вперед
В сознании большинства пользователей глобальной
В сознании большинства пользователей глобальной компьютерной сети 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 все равно обязаны знать, как все это спрятанное от пользователей "хозяйство" функционирует.
Содержание | Вперед
