Вторая из четырех частей статьи.
В этом формате каждое письмо находится в отдельном файле, имеющем число-
вое десятичное имя и расширение .MSG. Каждая конференция в таком формате по-
падает в отдельный каталог. Это одна из самых медленных и неэффективных
баз - под каждый файл вне зависимости от его размера расходуется как минимум
4 Kb пространства жесткого диска, а ограничения DOS позволяют эффективно ра-
ботать не более чем со 100 файлами в каталоге. Hекоторое убыстрение возможно
посредством установки программы FASTOPEN или дискового кэша - Hudson. В этом
формате все конференции размещаются в одном файле. Это наиболее быстрый из
всех известных форматов, однако структура файла Hudson-базы легко может быть
нарушена посредством внезапного отказа аппаратуры или появления сбойного
сектора. В таком случае вы рискуете потерять все письма во всех областях.
JAM
(первые буквы имен авторов: Joaquim-Andrew-Matthew). Hекоторый компро-
мисс между скоростью Hudson и надежностью MSG. В этом формате конференции
хранятся в разных файлах, по четыре файла на область. Возможно разнесение
разных конференций в разные директории и т.д.
Squish
Этот формат аналогичен JAM, с той разницей, что в JAM-базе новые письма
всегда добавляются в конец базы, которая может довольно долго раздуваться в
размерах, а в Squish-базе имеется возможность ограничить число писем и под-
держивать его автоматически.
Для успешной обработки писем, эхопроцессоры и редакторы используют меха-
низм указателей на последнее прочтенное письмо (Lastread Pointers). Для каж-
дого пользователя станции, хранится номер последнего прочтенного им письма в
каждой области. Таким образом вместо полного просмотра всей базы, тоссеру
или редактору достаточно исследовать еще непрочтенные письма. Это позволяет,
в частности, организовать быстрый поиск личной почты при входе пользователя
на BBS.
Как правило, в эхопочте ведутся дискуссии (за исключением конференций,
где дискуссии запрещены). Для того, чтобы иметь возможность просмотреть от-
веты других участников конференции на заинтересовавшее вас письмо, существу-
ет другая функция эхопроцессора - построение (или связывание) цепочек во-
прос-ответ (Reply Chains Linking). Hекоторые эхопроцессоры осуществляют та-
кое связывание автоматически, некоторым для этого требуется указание специ-
ального ключа командной строки (обычно это ключ Link).
Эхопроцессор, помимо указанных ранее функций, должен обеспечивать обслу-
живание базы (удаление писем (purge) и упаковку базы (pack)). Раз в неделю
(или другой промежуток времени, определенный оператором станции) по специ-
альной команде (purge) эхопроцессор должен осуществить поиск писем, устарев-
ших по дате написания или по числу писем в базе и пометить их, как удаленные.
Затем (по команде pack) удаленные письма физически удаляются из базы.
Активация эхопроцессора для распаковки и упаковки почты, обслуживания
базы и т.д. обычно осуществляется мейлером, который самостоятельно, согласно
определенным оператором правилам, вызывает соответствующие .ВАТ файлы.
> Редактор сообщений (Message Editor)
Редактор сообщений позволяет просматривать базу писем по областям, со-
здавать новые письма, как в сетевой, так и в эхопочте. Помимо этого, типовые
редакторы предоставляют множество других возможностей, как то перемещение
писем из области в область, сканирование базы писем на предмет новой/личной
почты, возможность работы в локальной сети с несколькими пользователями и
так далее.
Hаиболее популярными редакторами являются GoldEd (за такое название его
обычно зовут "голым дедом" или просто "дедом"), timEd (более быстрый, зато
менее -навороченный) и различные другие извращения - FM, входящий в комплект
мейлера FrontDoor и т.д.
> Роутинг
За редким исключением сетевая почта не передается напрямую адресату. Это
обусловлено отсутствием режима работы станции в нодлисте, наличием
unpublished узлов (узлов с неизвестным телефоном), и наконец, ненулевой ве-
роятности катастрофы на станции назначения. Возникает вопрос, куда переда-
вать письма, предназначеные для определенных групп сетевых адресов.
Роутинг (рутинг, от англ. Routing) представляет собой схему маршрутиза-
ции писем для данной станции сети. Роутинг имеет отношение только к сетевой
почте.
Роутинг задает правила, согласно которым будет отправляться пришедшая на
станцию и созданая на ней сетевая почта. Правило представляет собой соответ-
ствие группы адресов назначения одному адресу, на который будет передан ис-
ходящий пакет. Представим, что нужно отправлять все письма, предназначенные
для зоны 2 (FIDONet, Европа) через 2:5020/54, а все письма для зоны 314
(сеть GOLDNet) через 314:5020/33, тем самым определяем схему роутинга для
своей системы. Действительная схема роутинга может быть гораздо более слож-
ной, особенно для нагруженных станций сети, хабов и т.д.
Различают статический и динамический роутинг. Статический роутинг, как
правило, осуществляется эхопроцессором и присущ системам на базе
BinkleyStyle мейлера. Определяется специальная схема события, т.е. набор ин-
тервалов времени, в течение которых действует определенная схема роутинга.
Если эхопроцессор был вызван во время действия одного события и маршрутизи-
ровал письмо, то при повторном вызове во время другого события уже обрабо-
танные письма не будут перенаправлены в соответствии с новой схемой.
Динамический роутинг осуществляется, как правило, ArcMail-Attach систе-
мами. При этом, в зависимости от текущего события, меняется план роутинга, и
уже обработанные письма могут быть переадресованы в соответствии с новым
планом.
Заметим, что для оправки нетмайла, напрямую (директом, direct) адресату
в сети существует так называемый зоновый почтовый час (Zone Mail Hour, ZMH).
В этот период все узлы сети обязаны:
* Отвечать на звонки;
* Остановить передачу файлов, ArcMail-пакетов;
* Закрыть доступ к BBS;
* Запретить файл-реквесты;
* Передавать и принимать только непакованный нетмайл.
Поинты сети не обязаны соблюдать ZMH. В Москве, помимо ZMH действует еще
и Московский почтовый час (Moscow Mail Hour, MMH), начинающийся следом за
ZMH. Таким образом, с 5:30 до 7:30 утра по Московскому времени все узлы сети
принимают и передают только нетмайл.
Для эхопочты понятие роутинга не определено, поскольку письмо в эхо не
содержит сетевого адреса станции получателя. Таким образом ArcMail-пакет
всегда передается на узел, от которого получена соответствующая конференция,
при помощи прямой связи.
> Мейлер ArcMail-Attach
Как правило, основой функционирования любого ArcMail-Attach мейлера
является каталог, содержащий письма сетевой почты (NetMail folder). В боль-
шинстве случаев каждое письмо хранится в отдельном файле, имеющем расширение
.MSG. В таком случае принято говорить, что имеется область сетевой почты в
*.MSG стиле (*.MSG-style netmail area).
В этом каталоге (дальше будет употребляться жаргонное слово "фолдер")
находятся письма, адресованные данному узлу, и письма, написанные на этом
узле. Транзитные письма, проходящие через узел, в этом каталоге не разме-
щаются. Мейлер осуществляет ресканирование фолдера с определенными промежут-
ками времени в поиске новых сообщений, либо проделывает это при появлении
соответствующего флага (пустого файла со специфическим именем типа
REPACK.T-M или FDRESCAN.NOW в специальном каталоге флагов.
Обнаружив в фолдере письмо, ArcMail-Attach мейлер преобразует его в поч-
товый пакет (имеющий расширение *.РКТ) и переносит этот пакет в специальный
каталог пакетов, называемый аутбаундом. Hеобходимость в таком преобразовании
объясняется тем, что письма, за редким исключением, не передаются напрямую
адресату, а проходят по цепочке из нескольких станций. При этом каждая стан-
ция сама определяет на основании плана маршрутизации сетевой почты (netmail
routing scheme) на какой узел следует передавать письма для указанного в за-
головке письма адресата.
Поскольку заголовки писем не могут модифицироваться (будет потеряна ин-
формация об адресе истинного получателя), письма преобразуются в пакеты, в
заголовке которых указан адрес отправителя пакета (не совпадающий в общем
случае с адресом автора письма) и адрес получателя пакета (также не равный в
общем случае адресу получателя). Например, если почта от 157.49 передается
на 54.46 таким образом:
/157-49 -> /157.0 -> /1.0 -> /54.0 -> /54.46,
то на этапе /1 -> /54 пакет будет адресован от /1 для /54, хотя фактический
отправитель и получатель имеют другие адреса.
Пакет может содержать несколько писем, общей особенностью которых явля-
ется их текущая маршрутизация. Hа следующем узле будет действовать уже дру-
гой план роутинга, и письма могут быть упакованы в разные пакеты.
Помимо обычных писем, аркмейл-аттач мейлеры способны понимать также не-
которые специальные письма - так называемые файл-аттачи (fileattach) или
просто "аттачи". Файл-аттач представляет собой обычное письмо, имеющее осо-
бый атрибут (F/a - File/Attach) и содержащее в Поле темы имя передаваемого
файла.
При обнаружении такого письма, мейлер ищет соответствующий файл по ука-
занному в Поле темы пути и имени, и, обнаружив его, упаковывает письмо в
почтовый пакет. При передаче этого письма, будет передан также и файл, кото-
рый данное письмо описывало. При этом считается, что файл прикреплен (приат-
тачен, Attached) к письму.
Помимо обычных аттачей, мейлеры класса ArcMail-Attach имеют особый вид
аттачей - ArcMail-Attach письма. Эти письма создает эхопроцессор при созда-
нии ArcMail-пакета для заданного адреса. Такое письмо отличается от обычного
аттача тем, что написано от "магического" имени робота "ArcMail". При нахож-
дении письма от этого робота, мейлер не создает .РКТ файла, и передает при
установлении соединения только сам файл с Arc Mail-пакетом.
> Мейлер Binkley-style
Для мейлера типа BinkleyTerm, одним из основных отличий от ArcMail-At-
tach является тот факт, что такой мейлер никоим образом не работает с пись-
мами. Таким образом, вместо NetMail-фолдера в Binkley-style мейлерах исполь-
зуется понятие аутбаунда (outbound). Для каждой из зон, в которые станция
отправляет письма и файлы, создается специальный каталог (аутбаунд).
Для каждого адреса, на который должна быть отправлена почта, создаются
особые файлы с уникальным именем (шестнадцатиричная запись ЗD-адреса узла) и
расширением .?LO, задающие флавор (атрибут, flavour) для данного адреса, а
также содержащие указания мейлеру на передачу тех или иных файлов в виде пу-
тей. Первая буква расширения задает флавор. Для нетмайла создается аналог
файла .РКТ - .?UT. Все эти манипуляции осуществляются не мейлером, а отдель-
ной утилитой, либо эхопроцессором.
При посылке почты, мейлер типа BinkleyTerm передает соответствующий файл
с неупакованной сетевой почтой (.?UT) в виде файла .РКТ, образовав имя .РКТ
файла непосредственно в момент начала передачи. Таким образом, при обрывах
связи с последующим перезвоном .РКТ файлы имеют уже другие имена, а следова-
тельно принимаются не с места обрыва, а заново.
Поскольку в восьмисимвольном поле имени файла DOS невозможно разместить
4D-адрес в шестнадцатиричной форме. Для адресов назначения, являющихся пойн-
тами, создаются отдельные подкаталоги аутбаунда. Такие подкаталоги имеют
шестнадцатиричные имена, соответствующие адресу босс-ноды (т.е. ЗD-адресу) и
содержат файлы .?UT и .?LO с шестнадцатиричным номером пойнта.
Для нормальной работы с Binkley-Style мейлером должен использоваться
упаковщик сетевой почты, который будет преобразовывать письма в .?UT файлы.
Чаще всего используются IMBINK и ВРАСК.
Распаковка приходящей почты осуществляется в этом случае эхопроцессором.
Мейлер лишь передает почту и файлы из аутбаундов и принимает входящие пакеты
и файлы в каталоги, называемые инбаундами.
Мейлеры типа BinkleyTerm поддерживают три инбаунда - для неизвестных
систем, для известных систем и для систем, имеющих пароль на связь с данным
узлом. Под неизвестной системой подразумеваются такие системы, информация о
которых отсутствует в нодлисте/пойнтлисте. Заметим, что схему трех инбаундов
поддерживают не все эхопроцессоры.
> Специальные виды писем
Помимо рассмотренных выше обычных и аттачевых писем, существуют еще и
другие письма, называемые обычно файловыми запросами (файл-реквестами, фре-
ками, filerequest, FREQ) и запросами на обновление (апдейт-реквест, update-
request, UpdREQ).
Существуют несколько типов файловых запросов, которые реализованы и под-
держиваются различными мейлерами. Вы можете узнать из нодлиста, какой тип
файл-реквестов поддерживает станция, если обратите внимание на флажки, начи-
нающиеся с Х (ХА, XX,...).
Файл-реквест представляет собой письмо со специальным атрибутом (Frq) и
именами запрашиваемых файлов в поле темы (subj). Вы можете запросить столько
файлов, сколько имен влезает в строку subj (ее длина 72 символа), однако
следует помнить об ограничении на время, размер и число файлов для одного
файл-реквеста. Hе следует злоупотреблять символами диких карт (wildcards),
благо порой от этого проистекают нежелательные результаты (так, запросив у
FD 2.20 файл с именем *BG*.* вы рискуете получить в ответ случайное коли-
чество случайных файлов).
Лимиты на файл-реквест определяются несколькими факторами:
- скоростью соединения;
- известностью вашей системы (наличием вас в нод/пойнтлисте);
- наличием у вас пароля на связь с данным узлом;
- наличием критических событий в планах удаленного узла;
- уже израсходованным вами временем/ресурсами в этом месяце.
Следует помнить, что при наличии пароля на сессию с данным узлом, файл-
реквест также должен иметь пароль, совпадающий с паролем на сессию.
Большинство разумных мейлеров имеют возможность задавать ограничение для
числа/размера/времени для файл-реквеста за сессию/день/неделю/месяц. Будьте
внимательны при запросе файлов, старайтесь не превышать лимитов.
Апдейт-реквест представляет из себя файл-реквест на уже существующий
файл, который будет удовлетворен, если дата/время такого же файла на станции,
с которой производится реквест более свежая, чем имеющаяся.
> Виды сессий
Под сессией дальше будем понимать процесс установления связи между двумя
мейлерами после физического соединения двух модемов. Для обнаружения присут-
ствия мейлера на другом конце провода или определения звонка терминалом
пользователя BBS, используются различные протоколы сессий.
Hаиболее популярными в настоящее время являются протоколы EMSI (емзи,
емси, сокращение от Electronic Mail System Interface). Различают оригиналь-
ный протокол EMSI, применяемый при связи двух роботов-мейлеров, и интерак-
тивный протокол EMSI (IEMSI - Interactive EMSI), используемый для более
удобной связи с BBS с помощью терминала. Мы будем рассматривать лишь первый
из них.
Помимо EMSI, существуют также протоколы YооHоо и другие. Эти протоколы
использовались старым программным обеспечением, и в настоящее время поддер-
живаются только для совместимости.
После установления физического соединения, станция, ответившая на звонок,
обычно посылает в линию строку идентификации мейлера (introduction), которая
может содержать информацию о сетевом адресе и предложение для пользователей
BBS нажать ESC-ESC. За этим обычно следует передача специальной последова-
тельности символов, называемой EMSI-запросом (EMSI_REQ). Станция посылает
эти запросы в течение определенного времени, и, не получив ответа, или полу-
чив ESC-ESC, переходит в режим вызова BBS или вешает трубку, если BBS не-
доступна.
Звонящий узел аналогичным образом передает приглашение на EMSI-сессию
(EMSI_INQ). После выяснения обоюдной поддержки EMSI станции обмениваются
EMSI_DAT пакетами и приступают к передаче файлов. Детали реализации протоко-
лов EMSI и IEMSI описаны в стандартах сети FIDONet (FSC-0056).
Установление связи между двумя узлами вышеописанным образом называется
EMSI-handshake (емси-хэндшейк).
> Пароли на сессию
Пароль проверяется на этапе EMSI-handshake. Запомните, что несмотря на
то, что многие мейлеры позволяют использовать пароли произвольной длины (на-
пример, T-MAIL), большинство все же придерживаются ограничения в 8 символов.
Если предъявленный пароль окажется длиннее имеющегося, сессия не будет уста-
новлена.
При ошибке пароля, звонящий мейлер не получает никаких уведомлений о не-
правильности пароля. Происходит разрыв соединения по потере несущей. То есть
имеется принципиальная возможность звонить на узел до тех пор, пока он не
попадет в undialable по числу безуспешных звонков.
Поскольку файл-реквесты, как правило, обслуживаются самим мейлером, то
пароль на файл-реквест должен совпасть с паролем на сессию.
> Как все это работает?
Большую часть времени станция обычно находится в состоянии ожидания
звонка или события. События определяются конфигурацией событий мейлера. Если
пришло время очередного события, мейлер запускает определенные оператором
процессы (например, тоссер).
Как правило, основным событием, возбуждающим исходящий звонок, является
появление пакетов для этого узла, либо создание полла (poll) на его адрес.
Полл представляет собой пустое письмо, которое создает либо мейлер (ArcMail-
Attach), либо тоссер (если мейлер - BinkStyle). Отметим, что наличие писем
на какой-либо адрес не вызовет звонка, если станция назначения не работает в
настоящий момент времени. Вопрос о времени работы станции назначения разре-
шается посредством флагов U, Txy в нодлисте и специальных файлов конфигура-
ции мейлера, изменяющих режим работы станций по умолчанию.
Адрес, на который необходимо передать почту, включается мейлером в спе-
циальную очередь прозвона (queue). Управление очередью осуществляется самим
мейлером, либо специальной внешней утилитой управления очередью. Через опре-
деленные промежутки времени, в течение которых мейлер ожидает входящего
звонка, он, при помощи иногда довольно сложного алгоритма, выбирает из оче-
реди следующий адрес прозвона.
Осуществляется звонок но указанному в нод/пойнтлисте телефону, либо по
телефону очередного скрытого (не упомянутого в листе) канала (Hidden Line).
Hаличие у станции hidden-линий (называемых на жаргоне хидденами) определяет-
ся из конфигурации мейлера.
Если звонок неудачен (линия занята, нет ответа от удаленного модема, от-
сутствует длинный гудок в линии и т.д.) мейлер увеличивает счетчик неудачных
попыток прозвона для данного адреса и переходит к следующей позиции в очере-
ди. Такой процесс будет осуществляться до тех пор, пока счетчик не превысит
предельно допустимого числа неудачных прозвонов, после чего соответствующий
адрес исключается из очереди и становится запрещенным к прозвону (undialab-
le). Из такого состояния как правило он может быть излечен лишь при помощи
вмешательства оператора.
Дозвонившись, мейлер устанавливает EMSI-сессию и передает письма и файл-
реквесты на основной адрес удаленной станции, и на предъявленные АКА (если
мейлер соответствующим образом сконфигурирован). Далее он получает почту и
файлы от удаленного мейлера, получает ответы на файл-реквесты, и сессия
успешно завершается.
Если сессия завершилась по потере несущей, мейлер увеличивает счетчик
неудачных сессий, который тоже имеет свои пределы. При их превышении адрес
назначения также попадает в undialable.
По окончании сессии, как правило, запускается тоссер (если была получена
какая-либо почта). Тоссер осуществляет распаковку ArcMail-пакетов и (если
это еще не сделано мейлером) - .РКТ с нетмайлом.
> С чего начать?
> Hастройки
Для того, чтобы организовать у себя станцию сети FIDONet вам, прежде
всего, необходимо найти и установить перечисленные выше компоненты почтовой
системы. Для начинающих обычно принято рекомендовать комплект:
- мейлер: Т-Маil (берите один из релизов, они имеют номера версий, кончающи-
еся на два нуля; последняя на момент написания - 2600. В релизе есть доку-
ментация и примерные конфиги. В версиях 24хх (бета-версиях) отсутствует
документация, поэтому вам все равно будет необходим релиз). В качестве
альтернативы можно поставить Binkley/Term при помощи пакета PPoint, или
взять готовый комплект.
- эхопроцессор: рекомендовано GEcho - как наиболее простой и наиболее быст-
рый. Есть надежные старые версии 1.01 (только *.MSG и Hudson) и 1.02 (JAM,
Hudson, *.MSG). Версия 1.10 содержит ошибки и ей лучше не пользоваться.
Последняя доступная - 1.11. Заметьте, что если ваши принципы не позволяют
вам использовать нелицензированное ПО, то вам лучше остановиться на версии
1.01 или 1.02, так как версии 1.10 и 1.11 предназначены для зарегистриро-
ванных пользователей Если же ваши моральные устои не столь прочны, то на
многих BBS вы найдете соответствующие "утилиты".
- редактор: на быструю машину можно поставить GoldEd версии 2.41 (без JAM)
или 2.42 (с JAM). Существуют етце и версии 2.50 с различными числами после
номера версии (датой выпуска). Однако они, равно как и выпуски 2.42, со-
держат ошибки, поэтому брать такие версии следует, ориентируясь на дату
выпуска и чей-нибудь совет. Если машина медленная или мало памяти, можно
воспользоваться timEd'ом (1.01.gl - самая последняя версия).
Под фразой "установить" подразумевается не процесс инсталляции "a la
Windows" (как раз такого вы в FIDONet и не найдете), а кропотливое изучение
множества конфигурационных файлов и исправление значений в них под ваши
цели. Hе существует общих рекомендаций по установке того или иного обеспече-
ния - вам придется обратиться к документации на программу, если возникнут
проблемы. Так как у вас пока нет FIDO-адреса, то вместо него нужно проста-
вить фиктивный адрес (для Москвы - 2:5020/999.999).
Кроме того, через FIDONet распространяется много так называемых FAQ
(Frequently Asked Questions) no разным программам и системам. В любом случае,
будьте готовы обнаружить в используемой программе пару-тройку небольших, но
досадных ошибок.
Ошибки - неотъемлемая часть ПО для FIDONet, без них общение с сетью не
было бы столь эротичным.
Чтобы избежать ненужных вопросов и томительного ожидания ответа в какой-
либо эхе на ваши крики о помощи, воспользуйтесь схемой:
- Если то, что вы настраиваете отказывается выполнять одну из своих основных
функций - значит, вы неправильно это настроили.
- Если у вас возникли проблемы - первым делом обратитесь к документации на
то, что вы настраиваете. Прочтите ее внимательно, если позволяют возмож-
ности, ее даже лучше распечатать.
- Если по прочтении документации, проблема не разъяснилась, обратитесь за
помощью к вашему боссу, либо в локальную эху.
- Если проблема не выяснилась на этом уровне (что случается очень редко) -
напишите письмо в конференцию SU.CHAINIK.
Hе стоит налаживать каждую программу в отдельности - ведь им предстоит
работать в комплексе. Поэтому лучше вначале попробовать настроить каждый
продукт в отдельности, а затем уже настраивать весь комплекс целиком. Как
правило, при организации межпрограммного взаимодействия, используются два,
пути - либо набор ВАТ-файлов с обработкой ERRORLEVEL'ей, либо использование
общего каталога флагов.
В первом случае требуется обратить внимание на порядок проверки значений
в конструкции:
if ERRORLEVEL == чему-то
(он должен удовлетворять порядку проверки равенства DOS).
Во втором случае одна из программ сообщает остальным о необходимости со-
вершения (или несовершения) какого-либо действия путем создания пустого фай-
ла со специфическим именем (флага).
Естественной первой ступенью в FIDONet является получение пойнтового
адреса. Если вы желаете стать узлом FIDONet, вам все равно придется сначала
пробыть довольно продолжительное время чьим-нибудь пойнтом. Будучи пойнтом,
вы не обязаны соблюдать ZMH и даже вообще отвечать на входящие звонки.
Для поисков пойнта обычно используется эхоконференция RLJ.BBSNEWS.TALK.
Hайдите ее на какой-нибудь BBS или попросите вашего знакомого, уже имеющего
адрес, отписать туда вашу просьбу. Проверив связь и напоив вашего нового
босса непременным фидошным пивом (квасом, колой и т.д.), вы можете начинать
освоение просторов сети.
> Подписка на эхоконференции
Вначале проверьте, что ваш эхопроцессор правильно находит новые письма и
создает ArcMail-пакеты, которые понимает ваш мейлер. Для этого создайте фик-
тивную конференцию типа MO.ZHABA.TALK (приписав ей фиктивною аплинка с несу-
ществующим номером узла типа 2:5020/1158) и напишите в нее письмо. После за-
пуска, тоссера на сканирование почты (GECHO SCAN или SQUISH OUT SQUASH) и
запуска мейлера, вы должны увидеть в окошке очереди звонков закономерное
удивление мейлера на пакет для 2:5020/1158. Удалите этот пакет, саму конфе-
ренцию и ложного аплинка.
Итак, если ваш эхопроцессор исправен, можно начинать. Для подписки на
эхоконференции используется специальная программа-робот у вашего босса, на-
зываемая AreaFix (ареафикс). Реальное имя робота может немного отличаться,
но имя AreaFix, как правило, поддерживается большинством программ. В любом
случае, лучше предварительно узнать у вашего босса имя соответствующего ро-
бота и временной интервал между запусками AreaFix на босс-ноде.
Для того, чтобы получить список доступных конференций, напишите нетмай-
лом письмо следующего содержания:
----------------------------------------------------------------------------
From: Ваше имя at Ваш адрес
То: AreaFix at Адрес босса
Subj: Ваш пароль для AreaFix
----------------------------------------------------------------------------
%LIST
%HELP
--- timEd 1.01.g1+
----------------------------------------------------------------------------
Это письмо необходимо отправить непакованным нетмайлом, т.е. в виде РКТ-
файла для ArcMail-Attach мейлеров или в виде .?UT-файла для BinkleyTerm.
Разумеется, вы можете отправить его и упакованным, однако в таком случае
вы либо не получите ответа, либо получите его через существенно более длин-
ный промежуток времени. Hекоторые узлы свободны от такого ограничения и на
них можно посылать письма роботам и в упакованном виде. В любом случае, это
еще один вопрос, который надо выяснить в каждом конкретном случае.
В ответ вы получите (не сразу конечно, а может быть даже на следующий
день) список доступных конференций и краткую справку по командам AreaFix.
Внимательно прочтите ее. Выясните, какие команды понимает AreaFix вашего
босса, как подписываться и отписываться от эхоконференций. Изучите список
эх. Выберите одну-две конференции по вашему желанию и подпишитесь на них.
Для этого в большинстве случаев необходимо послать письмо вида:
----------------------------------------------------------------------------
From: Ваше имя at Ваш адрес
То: AreaFix at Адрес босса
Subj: Ваш пароль для AreaFix
----------------------------------------------------------------------------
+SU.CHAINIK
+RUSSIAN.SEX-TRASH
--- timEd 1.01.g1+
----------------------------------------------------------------------------
Здесь после символа + (подписаться на конференцию) и символа - (отпи-
саться от конференции) следует тэг выбранной вами конференции.
После того, как это письмо будет обработано AreaFix, вы получите первый
ArcMail-пакет. Если он имеет нецифровое имя (т.е. в имени присутствует пер-
вая буква Р - например, Р0000036.М01), а вы используете GEcho или TossScan,
то вам придется переименовывать такие пакеты в 00000036.MOI при помощи ВАТ-
файла.
Заметьте, что при использовании большинства эхопроцессоров, вам придется
предварительно создать у себя область с соответствующим именем, иначе все
письма попадут в BADECHO-область. Если такая беда приключилась, не волнуй-
тесь - большинство эхопроцессоров имеют команды для повторного тоссинга пи-
сем из BADECHO-области (для GEcho это Gecho toss-tossbad, для сквиша Squish
In Out Link с раскомментированным словом TossBad в конфиге). В дальнейшем вы
сможете установить какой-нибудь автосоздатель областей для вашего эхопроцес-
сора (GCreate для GEcho или SqaFix (SQCreate) для Squish).
Если ваш эхопроцессор правильно настроен, то после запуска его с ключом
тоссинга (GEcho Toss и следом MbLitil Link, или Squish In Link) вы увидите
новые письма в различных областях и сможете прочесть их с помощью редактора.
Ваша станция заработала.
> Файлэхи (FileEchoes)
Помимо стандартных конференций, существуют еще и файлэхи (FileEcho). Это
особый род почты, позволяющий вам получать программы, документацию и много
других полезных файлов по интересующим вас темам. Для работы с файлэхами не
нужен эхопроцессор. Механизм подписки на файлэхи такой же, как и для эхопоч-
ты, за исключением того, что вам придется писать роботу FileFix или AllFix и
не придется заводить эхообласть с соответствующим именем. Основные команды
AllFix такие же, как и у AreaFix, но лучше все же получить %HELP и от него.
Если вы содержите свою BBS и желаете сделать прибывающие по файлэхам
файлы доступными без вашего участия, вам придется установить какой-нибудь
FileFix-робот, который будет перемещать файлы в указанные вами области вашей
BBS, и самостоятельно описывать их на основе служебны
Используются технологии
uCoz