Страница:
TruncFileSent TF/s Усечь после пересылки. Употребляется совместно с атрибутом F/a. Указывает, что после посылки описываемый файл должен быть усечен до размера 0 байт.
Атрибуты Pvt, Cra, F/a, K/s, KF/s, TF/s, Hld, Frq, Cfm устанавливаются пользователем, а атрибуты Rvd, Snt, Loc — автоматически.
Эхописьмо может иметь лишь атрибуты : Loc, Snt, Rvd и Pvt. Все прочие атрибуты не имеют смысла при использовании в эхопочте (хотя могут быть внедрены в письмо методом грубой силы).
Часть II Типы используемого ПО.
Мейлер (Mailer).
Эхопроцессор.
Редактор сообщений(Message Editor)
Роутинг
ArcMail-Attach мейлеры.
Binkley-style мейлеры.
Специальные виды писем.
Виды сессий.
Пароли на сессию.
Эхопроцессоры.
Как все это работает ?
Атрибуты Pvt, Cra, F/a, K/s, KF/s, TF/s, Hld, Frq, Cfm устанавливаются пользователем, а атрибуты Rvd, Snt, Loc — автоматически.
Эхописьмо может иметь лишь атрибуты : Loc, Snt, Rvd и Pvt. Все прочие атрибуты не имеют смысла при использовании в эхопочте (хотя могут быть внедрены в письмо методом грубой силы).
Часть II Типы используемого ПО.
Любая станция сети использует три основных компоненты сетевого ПО :
Мейлер (Mailer).
Мейлер — это специальная почтовая программа, предназначенная для отправки писем и файлов через модем на соответствующие сетевые адреса. Мейлер осуществляет дозвон по указанному адресу, установление соединения, передачу и прием писем и файлов, а также управление модемом и другие дополнительные функции. Как правило, участие человека при этом необязательно.
В зависимости от способа обработки писем мейлеры делятся на две группы: — ArcMail-Attach (Аркмейл-Аттач) и Binkley-style (бинклистайл) мейлеры. Основным отличием одной группы от другой является способ обработки почты, хотя есть и другие существенные отличия.
Мейлеры группы ArcMail-Attach обычно самостоятельно осуществляют преобразование файла с сетевым письмом в почтовый пакет (упаковку) и обратное пеобразование (распаковку). При этом на каждый ArcMail-пакет должен существовать так называемый аркмейл-аттач (attach) — специальное письмо, которое адресовано оператору узла от имени ArcMail, и в качестве темы содержит имя передаваемого файла. При передаче файла это письмо не передается адресату, а используется передающим мейлером для поиска и обработки ArcMail-пакетов.
Минусом таких мейлеров является потенциальная возможность захлебнуться в потоке сетевой почты на нагруженном узле (т.е. большую часть времени мейлер будет распаковывать пришедший нетмайл и перепаковывать его на другие адреса). Этот недостаток можно устранить, запретив мейлеру распаковывать нетмайл.
Мейлеры группы Binkley-Style не осуществляют никаких операций с письмами и файлами, предоставляя эту возможность внешним утилитам. Такие мейлеры просто передают все письма и файлы, предназначенные для соответствующего узла, не осуществляя упаковку и распаковку. Вместо процедуры поиска аркмейловых пакетов при помощи ArcMail-attach писем здесь применяется концепция аутбаунда (outbound).
Для каждой зоны создается зоновый аутбаунд — специальный каталог файловой системы. В этом каталоге находятся специальным образом поименованные файлы и подкаталоги, содержащие исходящую почту. Имя файла или подкаталога однозначно определяется адресом системы, которой адресован почтовый пакет. Расширение файла определяет его тип. Более подробно этот вопрос обсуждается ниже.
Из числа известных ArcMail-Attach мейлеров следует упомянуть FrontDoor и T-Mail, из числа bink-style — BinkleyTerm и Bink/+.
Как правило мейлер функционирует в режиме FrontEnd (отчего его иногда называют FrontEnd Mailer'ом). Это означает, что при звонке на узел сети вам отвечает именно мейлер, который затем, при необходимости вызывает внешнюю программу BBS или утилиту для приема факсов.
Существует еще и другой остроумный режим работы мейлера, применяемый некоторыми пакетами BBS — Shell to Mailer. В этом режиме вначале в память загружается пакет BBS, а уже из него запускается мейлер. Мейлер отвечает на звонок, и, если позвонил человек, завершает свою работу с определенным ErrorLevel'ом. Управление получает BBS.
В зависимости от способа обработки писем мейлеры делятся на две группы: — ArcMail-Attach (Аркмейл-Аттач) и Binkley-style (бинклистайл) мейлеры. Основным отличием одной группы от другой является способ обработки почты, хотя есть и другие существенные отличия.
Мейлеры группы ArcMail-Attach обычно самостоятельно осуществляют преобразование файла с сетевым письмом в почтовый пакет (упаковку) и обратное пеобразование (распаковку). При этом на каждый ArcMail-пакет должен существовать так называемый аркмейл-аттач (attach) — специальное письмо, которое адресовано оператору узла от имени ArcMail, и в качестве темы содержит имя передаваемого файла. При передаче файла это письмо не передается адресату, а используется передающим мейлером для поиска и обработки ArcMail-пакетов.
Минусом таких мейлеров является потенциальная возможность захлебнуться в потоке сетевой почты на нагруженном узле (т.е. большую часть времени мейлер будет распаковывать пришедший нетмайл и перепаковывать его на другие адреса). Этот недостаток можно устранить, запретив мейлеру распаковывать нетмайл.
Мейлеры группы Binkley-Style не осуществляют никаких операций с письмами и файлами, предоставляя эту возможность внешним утилитам. Такие мейлеры просто передают все письма и файлы, предназначенные для соответствующего узла, не осуществляя упаковку и распаковку. Вместо процедуры поиска аркмейловых пакетов при помощи ArcMail-attach писем здесь применяется концепция аутбаунда (outbound).
Для каждой зоны создается зоновый аутбаунд — специальный каталог файловой системы. В этом каталоге находятся специальным образом поименованные файлы и подкаталоги, содержащие исходящую почту. Имя файла или подкаталога однозначно определяется адресом системы, которой адресован почтовый пакет. Расширение файла определяет его тип. Более подробно этот вопрос обсуждается ниже.
Из числа известных ArcMail-Attach мейлеров следует упомянуть FrontDoor и T-Mail, из числа bink-style — BinkleyTerm и Bink/+.
Как правило мейлер функционирует в режиме FrontEnd (отчего его иногда называют FrontEnd Mailer'ом). Это означает, что при звонке на узел сети вам отвечает именно мейлер, который затем, при необходимости вызывает внешнюю программу BBS или утилиту для приема факсов.
Существует еще и другой остроумный режим работы мейлера, применяемый некоторыми пакетами BBS — Shell to Mailer. В этом режиме вначале в память загружается пакет BBS, а уже из него запускается мейлер. Мейлер отвечает на звонок, и, если позвонил человек, завершает свою работу с определенным ErrorLevel'ом. Управление получает BBS.
Эхопроцессор.
Эхопроцессор (EchoProcessor) это программа, предназначенная специально для распаковки и упаковки почтовых пакетов с сетевой почтой, ArcMail-пакетов, импорта и экспорта писем в базу писем, преобразований базы и т.д.
Каждая станция имеет свою базу писем (message base), которая разделена на области (конференции). Письма из соответствующих эхоконференций копируются эхопроцессором в области базы писем для их последующего прочтения.
Процесс преобразования ArcMailовых и почтовых пакетов в письма называется тоссингом (tossing), а процесс поиска новых писем в базе и преобразования их в пакеты — сканнингом (scanning). Иногда оба процесса отождествляются и вместе именуются тоссингом. От этого эхопроцессоры иногда называют тоссерами (tosser).
При использовании ArcMail-Attach мейлера алгоритм действий тоссера таков :
1. Произвести поиск ArcMail-пакетов в специальных входных каталогах файлов (инбаундах, inbound).
2. Распаковать все найденные пакеты утилитой декомпрессии.
3. Преобразовать полученные почтовые пакеты в письма и разместить письма по областям базы писем.
4. Создать почтовые пакеты с письмами для всех станций сети, подписанных на эти конференции у данной станции.
5. Просканировать базу писем на предмет новых писем, написанных оператором узла или пользователями.
6. Упаковать эти пакеты утилитой компрессии.
7. Создать ArcMail-Attach письма в соответствующем каталоге
мейлера.
При использовании Binkley-style мейлера алгоритм действий тоссера тот же, за исключением того, что :
1. Кроме ArcMail-пакетов обрабатываются и пакеты с сетевой почтой.
2. Hе создается ArcMail-Attach писем. Вместо них создаются специальные файлы, о которых речь ниже.
Hаиболее известными эхопроцессорами являются : Squish, GEcho, FastEcho, и т.д.
Каждая станция имеет свою базу писем (message base), которая разделена на области (конференции). Письма из соответствующих эхоконференций копируются эхопроцессором в области базы писем для их последующего прочтения.
Процесс преобразования ArcMailовых и почтовых пакетов в письма называется тоссингом (tossing), а процесс поиска новых писем в базе и преобразования их в пакеты — сканнингом (scanning). Иногда оба процесса отождествляются и вместе именуются тоссингом. От этого эхопроцессоры иногда называют тоссерами (tosser).
При использовании ArcMail-Attach мейлера алгоритм действий тоссера таков :
1. Произвести поиск ArcMail-пакетов в специальных входных каталогах файлов (инбаундах, inbound).
2. Распаковать все найденные пакеты утилитой декомпрессии.
3. Преобразовать полученные почтовые пакеты в письма и разместить письма по областям базы писем.
4. Создать почтовые пакеты с письмами для всех станций сети, подписанных на эти конференции у данной станции.
5. Просканировать базу писем на предмет новых писем, написанных оператором узла или пользователями.
6. Упаковать эти пакеты утилитой компрессии.
7. Создать ArcMail-Attach письма в соответствующем каталоге
мейлера.
При использовании Binkley-style мейлера алгоритм действий тоссера тот же, за исключением того, что :
1. Кроме ArcMail-пакетов обрабатываются и пакеты с сетевой почтой.
2. Hе создается ArcMail-Attach писем. Вместо них создаются специальные файлы, о которых речь ниже.
Hаиболее известными эхопроцессорами являются : Squish, GEcho, FastEcho, и т.д.
Редактор сообщений(Message Editor)
Редактор сообщений позволяет просматривать базу писем по областям, создавать новые письма, как в сетевой, так и в эхопочте. Помимо этого, типовые редакторы предоставляют множество других возможностей, как то перемещение писем из области в область, сканирование базы писем на предмет новой/личной почты, возможность работы в локальной сети с несколькими пользователями и так далее.
Hаиболее популярными редакторами являются GoldEd (за такое название его обычно зовут «голым дедом» или просто «дедом»), timEd (более быстрый, зато менее навороченный), и различные другие извращения — FM, входящий в комплект мейлера FrontDoor и т.д.
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 действует еще и MMH (Moscow Mail Hour), начинающийся сразу следом за ZMH. Таким образом с 5:30 до 7:30 утра по Московскому времени все узлы сети принимают и передают только нетмайл.
Для эхопочты понятие роутинга не определено, поскольку письмо в эхо не содержит сетевого адреса станции получателя. Таким образом ArcMail-пакет всегда передается на узел, от которого получена соответствующая конференция, при помощи прямой связи.
Роутинг (рутинг, от англ Routing) представляет собой схему маршрутизации писем для данной станции сети. Роутинг имеет отношение только к сетевой почте.
Роутинг задает правила, согласно которым будет отправляться пришедшая на станцию и созданная на ней сетевая почта. Правило представляет собой соответствие группы адресов назначения одному адресу, на который будет передан исходящий пакет. Представим, что я хочу отправлять все письма, предназначенные для зоны 2 (FIDONet, Европа) через 2:5020/54, а все письма для зоны 314 (сеть GOLDNet) через 314:5020/33. Тем самым я определил схему роутинга для своей системы. Действительная схема роутинга может быть гораздо более сложной, особенно для нагруженных станций сети, хабов и т.д.
Различают статический и динамический роутинг. Статический роутинг как правило осуществляется эхопроцессором, и присущ системам на базе BinkleyStyle мейлера. Определяется специальная схема событий, т.е. набор интервалов времени, во течение которых действует определенная схема роутинга. Если эхопроцессор был вызван во время действия одного события и маршрутизировал письмо, то при повторном вызове во время другого события уже обработанные письма не будут перенаправлены в соответствии с новой схемой.
Динамический роутинг осуществляется исключительно ArcMail-Attach системами. При этом в зависимости от текущего события меняется план роутинга, и уже обработанные письма могут быть переадресованы в соответствии с новым планом.
Заметим, что для отправки нетмайла напрямую (директом, direct) адресату в сети существует так называемый зоновый почтовый час (Zone Mail Hour, ZMH). В этот период все *узлы* сети обязаны :
— отвечать на звонки
— остановить передачу файлов, ArcMail-пакетов
— закрыть доступ к BBS
— запретить файл-реквесты
— передавать и принимать только непакованный нетмайл.
Поинты сети не обязаны соблюдать ZMH. В Москве, помимо ZMH действует еще и MMH (Moscow Mail Hour), начинающийся сразу следом за 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 мейлер преобразует его в почтовый пакет (имеющий расширение .PKT) и переносит этот пакет в специальный каталог пакетов, называемый аутбаундом. Hеобходимость в таком преобразовании обьясняется тем, что письма, за редким исключением, не передаются напрямую адресату, а проходят по цепочке из нескольких станций. При этом каждая станция сама определяет на основании плана маршрутизации сетевой почты (netmail routing scheme) на какой узел следует передавать письма для указанного в заголовке письма адресата.
Поскольку заголовки писем не могут модифицироваться (будет потеряна информация об адресе истинного получателя), письма преобразуются в пакеты, в заголовке которых указан адрес отправителя пакета (не совпадающий в общем случае с адресом автора письма) и адрес получателя пакета (также не равный в общем случае адресу получателя). Hапример, если почта от 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». При нахождении письма от этого робота мейлер не создает .PKT файла, и передает при установлении соединения только сам файл с ArcMail-пакетом.
В этом каталоге (дальше я буду употреблять жаргонное слово «фолдер») находятся письма, адресованные данному узлу, и письма, написанные на этом узле. Транзитные письма, проходящие через узел, в этом каталоге не размещаются. Мейлер осуществляет ресканирование фолдера с определенными промежутками времени в поиске новых сообщений, либо проделывает это при появлении соответствующего флага (пустого файла со специфическим именем типа REPACK.T-M или FDRESCAN.NOW в специальном каталоге флагов).
Обнаружив в фолдере письмо, ArcMail-Attach мейлер преобразует его в почтовый пакет (имеющий расширение .PKT) и переносит этот пакет в специальный каталог пакетов, называемый аутбаундом. Hеобходимость в таком преобразовании обьясняется тем, что письма, за редким исключением, не передаются напрямую адресату, а проходят по цепочке из нескольких станций. При этом каждая станция сама определяет на основании плана маршрутизации сетевой почты (netmail routing scheme) на какой узел следует передавать письма для указанного в заголовке письма адресата.
Поскольку заголовки писем не могут модифицироваться (будет потеряна информация об адресе истинного получателя), письма преобразуются в пакеты, в заголовке которых указан адрес отправителя пакета (не совпадающий в общем случае с адресом автора письма) и адрес получателя пакета (также не равный в общем случае адресу получателя). Hапример, если почта от 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». При нахождении письма от этого робота мейлер не создает .PKT файла, и передает при установлении соединения только сам файл с ArcMail-пакетом.
Binkley-style мейлеры.
Для мейлера типа BinkleyTerm одним из основных отличий от ArcMail-Attach является тот факт, что такой мейлер никоим образом не работает с письмами. Таким образом, вместо NetMail-фолдера в Binkley-style мейлерах используется понятие аутбаунда (outbound). Для каждой из зон, в которые станция отправляет письма и файлы, создается специальный каталог (аутбаунд).
Для каждого адреса, на который должна быть отправлена почта создаются особые файлы с уникальным именем (шестнадцатиричная запись 3D-адреса узла) и расширением .?LO, задающие флавор (атрибут, flavour) для данного адреса, а также содержащие указания мейлеру на передачу тех или иных файлов в виде путей. Первая буква расширения задает флавор. Для нетмайла создается аналог файла .PKT — ?UT. Все эти манипуляции осуществляются не мейлером, а отдельной утилитой, либо эхопроцессором.
При посылке почты мейлер типа BinkleyTerm передает соответствующий файл с неупакованной сетевой почтой (.?UT), в виде файла .PKT, образовав имя .PKT файла непосредственно в момент начала передачи. Таким образом, при обрывах связи с последующим перезвоном .PKT файлы имеют уже другие имена, а следовательно принимаются не с места обрыва, а заново.
Поскольку в восьмисимвольном поле имени файла DOS невозможно разместить 4D-адрес в шестнадцатиричной форме, для адресов назначения, являющихся поинтами создаются отдельные подкаталоги аутбаунда. Такие подкаталоги имеют шестнадцатиричные имена соответствующие адресу босс-ноды (т.е. 3D-адресу) и содержат файлы .?UT и .?LO с шестнадцатиричным номером поинта.
Для нормальной работы с Binkley-Style мейлером должен использоваться упаковщик сетевой почты, который будет преобразовывать письма в .?UT файлы. Чаще всего используются IMBINK и BPACK.
Распаковка приходящей почты осуществляется в этом случае эхопроцессором. Мейлер лишь передает почту и файлы из аутбаундов и принимает входящие пакеты и файлы в каталоги, называемые инбаундами.
Мейлеры типа BinkleyTerm поддерживают три инбаунда — для неизвестных систем, для известных систем и для систем, имеющих пароль на связь с данным узлом. Под неизвестной системой здесь и далее подразумеваются такие системы, информация о которых отсутствует в нодлисте/поинтлисте. Заметим, что схему трех инбаундов поддерживают не все эхопроцессоры.
Для каждого адреса, на который должна быть отправлена почта создаются особые файлы с уникальным именем (шестнадцатиричная запись 3D-адреса узла) и расширением .?LO, задающие флавор (атрибут, flavour) для данного адреса, а также содержащие указания мейлеру на передачу тех или иных файлов в виде путей. Первая буква расширения задает флавор. Для нетмайла создается аналог файла .PKT — ?UT. Все эти манипуляции осуществляются не мейлером, а отдельной утилитой, либо эхопроцессором.
При посылке почты мейлер типа BinkleyTerm передает соответствующий файл с неупакованной сетевой почтой (.?UT), в виде файла .PKT, образовав имя .PKT файла непосредственно в момент начала передачи. Таким образом, при обрывах связи с последующим перезвоном .PKT файлы имеют уже другие имена, а следовательно принимаются не с места обрыва, а заново.
Поскольку в восьмисимвольном поле имени файла DOS невозможно разместить 4D-адрес в шестнадцатиричной форме, для адресов назначения, являющихся поинтами создаются отдельные подкаталоги аутбаунда. Такие подкаталоги имеют шестнадцатиричные имена соответствующие адресу босс-ноды (т.е. 3D-адресу) и содержат файлы .?UT и .?LO с шестнадцатиричным номером поинта.
Для нормальной работы с Binkley-Style мейлером должен использоваться упаковщик сетевой почты, который будет преобразовывать письма в .?UT файлы. Чаще всего используются IMBINK и BPACK.
Распаковка приходящей почты осуществляется в этом случае эхопроцессором. Мейлер лишь передает почту и файлы из аутбаундов и принимает входящие пакеты и файлы в каталоги, называемые инбаундами.
Мейлеры типа BinkleyTerm поддерживают три инбаунда — для неизвестных систем, для известных систем и для систем, имеющих пароль на связь с данным узлом. Под неизвестной системой здесь и далее подразумеваются такие системы, информация о которых отсутствует в нодлисте/поинтлисте. Заметим, что схему трех инбаундов поддерживают не все эхопроцессоры.
Специальные виды писем.
Помимо рассмотренных выше обычных и аттачевых писем, существуют еще и другие письма, называемые обычно файловыми запросами (файл-реквестами, фреками filerequest, FREQ) и запросами на обновление (апдейт-реквест, update-request, UpdREQ).
Существуют несколько типов файловых запросов, которые реализованы и поддерживаются различными мейлерами. Вы можете узнать из нодлиста, какой тип файл-реквестов поддерживает станция, если обратите внимание на флажки, начинающиеся с X (XA, XX, …). Подробная информация о том, какие мейлеры поддерживают те или иные типы файл-реквестов Вы можете узнать из Приложения, или поглядев на таблички в конце полного ноделиста. Подробная разница между Bark и WaZoo файл-реквестами лежит за пределами данного руководства. Каждый может получить эту информацию из стандартов сети FIDONet, список которых приведен в приложении.
Файл-реквест представляет собой письмо, со специальным атрибутом (Frq) и именами запрашиваемых файлов в поле темы (subj). Вы можете запросить столько файлов, сколько имен влезает в строку subj (ее длина 72 символа), однако следует помнить об ограничениях на время, размер и число файлов для одного файлреквеста. Hе следует злоупотреблять символами диких карт (wildcards), благо порой от этого проистекают нежелательные результаты (так, запросив у FD 2.20 файл с именем *BG*.* вы рискуете получить в ответ случайное количество случайных файлов).
Лимиты на файл-реквест определяются несколькими факторами :
— скоростью соединения
— известностью Вашей системы (наличием Вас в нод/поинтлисте)
— наличием у Вас пароля на связь с данным узлом
— наличием критических событий в планах удаленного узла
— уже израсходованным Вами временем/ресурсами в этом месяце
Следует помнить, что при наличии пароля на сессию с данным узлом, файл-реквест также должен иметь пароль, совпадающий с паролем на сессию.
Большинство разумных мейлеров имеют возможность задавать ограничение для числа/размера/времени для файлреквеста за сессию/день/неделю/месяц. Будьте внимательны при запросе файлов, старайтесь не превышать лимитов.
Апдейт-реквест представляет из себя файлреквест на уже существующий файл, который будет удовлетворен, если дата/время такого же файла на станции с которой производится реквест более свежая, чем имеющаяся.
Существуют несколько типов файловых запросов, которые реализованы и поддерживаются различными мейлерами. Вы можете узнать из нодлиста, какой тип файл-реквестов поддерживает станция, если обратите внимание на флажки, начинающиеся с X (XA, XX, …). Подробная информация о том, какие мейлеры поддерживают те или иные типы файл-реквестов Вы можете узнать из Приложения, или поглядев на таблички в конце полного ноделиста. Подробная разница между Bark и WaZoo файл-реквестами лежит за пределами данного руководства. Каждый может получить эту информацию из стандартов сети FIDONet, список которых приведен в приложении.
Файл-реквест представляет собой письмо, со специальным атрибутом (Frq) и именами запрашиваемых файлов в поле темы (subj). Вы можете запросить столько файлов, сколько имен влезает в строку subj (ее длина 72 символа), однако следует помнить об ограничениях на время, размер и число файлов для одного файлреквеста. Hе следует злоупотреблять символами диких карт (wildcards), благо порой от этого проистекают нежелательные результаты (так, запросив у FD 2.20 файл с именем *BG*.* вы рискуете получить в ответ случайное количество случайных файлов).
Лимиты на файл-реквест определяются несколькими факторами :
— скоростью соединения
— известностью Вашей системы (наличием Вас в нод/поинтлисте)
— наличием у Вас пароля на связь с данным узлом
— наличием критических событий в планах удаленного узла
— уже израсходованным Вами временем/ресурсами в этом месяце
Следует помнить, что при наличии пароля на сессию с данным узлом, файл-реквест также должен иметь пароль, совпадающий с паролем на сессию.
Большинство разумных мейлеров имеют возможность задавать ограничение для числа/размера/времени для файлреквеста за сессию/день/неделю/месяц. Будьте внимательны при запросе файлов, старайтесь не превышать лимитов.
Апдейт-реквест представляет из себя файлреквест на уже существующий файл, который будет удовлетворен, если дата/время такого же файла на станции с которой производится реквест более свежая, чем имеющаяся.
Виды сессий.
Под сессией дальше будем понимать процесс установления связи между двумя мейлерами после физического соединения двух модемов. Для обнаружения присутствия мейлера на другом конце провода или определения звонка терминалом пользователя ББС используются различные протоколы сессий.
Hаиболее популярными в настоящее время являются протоколы EMSI (емзи, емси, сокр. от Electronic Mail System Interface). Различают оригинальный протокол EMSI, применяемый при связи двух роботов-мейлеров, и интерактивный протокол EMSI (IEMSI — Interactive EMSI), используемый для более удобной связи с ББС с помощью терминала. Мы будем рассматривать лишь первый из них.
Помимо EMSI, существуют также протоколы YooHoo и другие. Эти протоколы использовались старым программным обеспечением, и в настоящее время поддерживаются только для совместимости.
После установления физического соединения станция, ответившая на звонок, обычно посылает в линию строку идентификации мейлера (introduction), которая может содержать информацию о сетевом адресе и предложение для пользователей ББС нажать ESC-ESC. За этим обычно следует передача специальной последовательности символов, называемой EMSI-запросом (EMSI_REQ). Станция послыает эти запросы в течение определенного времени, и, не получив ответа, или получив ESC-ESC переходит в режим вызова ББС или вешает трубку, если ББС недоступна.
Звонящий узел аналогичным образом передает приглашение на EMSI-сессию (EMSI_INQ). После выяснения обоюдной поддержки EMSI станции обмениваются EMSI_DAT пакетами и приступают к передаче файлов. Детали реализации протоколов EMSI и IEMSI описаны в стандартах сети FIDONet (FSC-0056).
Установление связи между двумя узлами вышеописанным образом называется EMSI-handshake (емси-хэндшейк)
Hаиболее популярными в настоящее время являются протоколы EMSI (емзи, емси, сокр. от Electronic Mail System Interface). Различают оригинальный протокол EMSI, применяемый при связи двух роботов-мейлеров, и интерактивный протокол EMSI (IEMSI — Interactive EMSI), используемый для более удобной связи с ББС с помощью терминала. Мы будем рассматривать лишь первый из них.
Помимо EMSI, существуют также протоколы YooHoo и другие. Эти протоколы использовались старым программным обеспечением, и в настоящее время поддерживаются только для совместимости.
После установления физического соединения станция, ответившая на звонок, обычно посылает в линию строку идентификации мейлера (introduction), которая может содержать информацию о сетевом адресе и предложение для пользователей ББС нажать ESC-ESC. За этим обычно следует передача специальной последовательности символов, называемой EMSI-запросом (EMSI_REQ). Станция послыает эти запросы в течение определенного времени, и, не получив ответа, или получив ESC-ESC переходит в режим вызова ББС или вешает трубку, если ББС недоступна.
Звонящий узел аналогичным образом передает приглашение на EMSI-сессию (EMSI_INQ). После выяснения обоюдной поддержки EMSI станции обмениваются EMSI_DAT пакетами и приступают к передаче файлов. Детали реализации протоколов EMSI и IEMSI описаны в стандартах сети FIDONet (FSC-0056).
Установление связи между двумя узлами вышеописанным образом называется EMSI-handshake (емси-хэндшейк)
Пароли на сессию.
Этот вопрос включен в рассмотрение ввиду распространенности проблем с соединением при ошибках в задании паролей.
Прежде всего, имеет место следующая таблица :
Звонящий узел | Отвечающий Узел | Сессия
пароль | вид сессии пароль | вид сессии
нет непарольная нет непарольная +
есть парольная нет непарольная ? *)
нет — есть — —
есть парольная есть парольная + (пароль совпал)
есть — есть — — (несовпал)
* — зависит от мейлера и его настроек.
Пароль проверяется на этапе EMSI-handshake. Запомните, что несмотря на то, что многие мейлеры позволяют использовать пароли произвольной длины (например, T-MAIL), большинство все же придерживаются ограничения в 8 символов. Если предъявленный пароль окажется длиннее имеющегося сессия не будет установлена.
При ошибке пароля звонящий мейлер не получает никаких уведомлений о неправильности пароля. Происходит разрыв соединения по потере несущей. То есть имеется принципиальная возможность звонить на узел до тех пор, пока он не попадет в undialable по числу безуспешных звонков.
Поскольку файл-реквесты как правило обслуживаются самим мейлером, то пароль на файл-реквест должен совпасть с паролем на сессию.
Прежде всего, имеет место следующая таблица :
Звонящий узел | Отвечающий Узел | Сессия
пароль | вид сессии пароль | вид сессии
нет непарольная нет непарольная +
есть парольная нет непарольная ? *)
нет — есть — —
есть парольная есть парольная + (пароль совпал)
есть — есть — — (несовпал)
* — зависит от мейлера и его настроек.
Пароль проверяется на этапе EMSI-handshake. Запомните, что несмотря на то, что многие мейлеры позволяют использовать пароли произвольной длины (например, T-MAIL), большинство все же придерживаются ограничения в 8 символов. Если предъявленный пароль окажется длиннее имеющегося сессия не будет установлена.
При ошибке пароля звонящий мейлер не получает никаких уведомлений о неправильности пароля. Происходит разрыв соединения по потере несущей. То есть имеется принципиальная возможность звонить на узел до тех пор, пока он не попадет в undialable по числу безуспешных звонков.
Поскольку файл-реквесты как правило обслуживаются самим мейлером, то пароль на файл-реквест должен совпасть с паролем на сессию.
Эхопроцессоры.
Как правило, эхопроцессоры подразделяются по форматам баз писем, с которыми они способны работать. Существуют следующие форматы баз :
— *.MSG. В этом формате каждое письмо находится в отдельном файле, имеющем числовое десятичное имя и расширение 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) удаленные письма физически удаляются из базы.
Активация эхопроцессора для распаковки и упаковки почты, обслуживания базы и т.д. обычно осуществляется мейлером, который самостоятельно, согласно определенным оператором правилам, вызывает соответствующие .BAT файлы.
Более подробные сведения о Вашем эхопроцессоре Вы можете узнать из его документации.
— *.MSG. В этом формате каждое письмо находится в отдельном файле, имеющем числовое десятичное имя и расширение 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) удаленные письма физически удаляются из базы.
Активация эхопроцессора для распаковки и упаковки почты, обслуживания базы и т.д. обычно осуществляется мейлером, который самостоятельно, согласно определенным оператором правилам, вызывает соответствующие .BAT файлы.
Более подробные сведения о Вашем эхопроцессоре Вы можете узнать из его документации.
Как все это работает ?
Большую часть времени станция обычно находится в состоянии ожидания звонка или события. События определяются конфигурацией событий мейлера. Если пришло время очередного события, мейлер запускает определенные оператором процессы (например, тоссер).
Как правило, основным событием, возбуждающим исходящий звонок, является создание полла (poll) на какой-либо адрес. Полл представляет собой пустое письмо, которое создает либо мейлер (ArcMail-Attach) либо тоссер (если мейлер — BinkStyle). Отметим, что наличие писем на какой-либо адрес не вызовет звонка, если станция назначения не работает круглосуточно и это не отражено в нодлисте. Исключением из этого правила являются письма с атрибутом Cra.
Адрес, на который необходимо передать почту, включается мейлером в специальную очередь прозвона (queue). Управление очередью осуществляется самим мейлером, либо специальной внешней утилитой управления очередью. Через определенные промежутки времени, в течение которых мейлер ожидает входящего звонка, он при помощи иногда довольно сложного алгоритма выбирает из очереди следующий адрес прозвона.
Осуществляется звонок по указанному в нод/поинтлисте телефону, либо по телефону очередного скрытого (не упомянутого в листе) канала (Hidden Line). Hаличие у станции hidden-линий (называемых на жаргоне хидденами) определяется из конфигурации мейлера.
Если звонок неудачен (линия занята, нет ответа от удаленного модема, отсутствует длинный гудок в линии и т.д.) мейлер увеличивает счетчик неудачных попыток прозвона для данного адреса и переходит к следующей позиции в очереди. Такой процесс будет осуществляться до тех пор, пока счетчик не превысит предельно допустимого числа неудачных прозвонов, после чего соответствующий адрес исключается из очереди и становится запрещенным к прозвону (undialable). Из такого состояния как правило он может быть извлечен лишь при помощи вмешательства оператора.
Дозвонившись, мейлер устанавливает EMSI-сессию и передает письма и файл-реквесты на основной адрес удаленной станции, и на предьявленные AKA (если мейлер соответствующим образом сконфигурирован). Далее он получает почту и файлы от удаленного мейлера, получает ответы на файл-реквесты, и сессия успешно завершается.
Как правило, основным событием, возбуждающим исходящий звонок, является создание полла (poll) на какой-либо адрес. Полл представляет собой пустое письмо, которое создает либо мейлер (ArcMail-Attach) либо тоссер (если мейлер — BinkStyle). Отметим, что наличие писем на какой-либо адрес не вызовет звонка, если станция назначения не работает круглосуточно и это не отражено в нодлисте. Исключением из этого правила являются письма с атрибутом Cra.
Адрес, на который необходимо передать почту, включается мейлером в специальную очередь прозвона (queue). Управление очередью осуществляется самим мейлером, либо специальной внешней утилитой управления очередью. Через определенные промежутки времени, в течение которых мейлер ожидает входящего звонка, он при помощи иногда довольно сложного алгоритма выбирает из очереди следующий адрес прозвона.
Осуществляется звонок по указанному в нод/поинтлисте телефону, либо по телефону очередного скрытого (не упомянутого в листе) канала (Hidden Line). Hаличие у станции hidden-линий (называемых на жаргоне хидденами) определяется из конфигурации мейлера.
Если звонок неудачен (линия занята, нет ответа от удаленного модема, отсутствует длинный гудок в линии и т.д.) мейлер увеличивает счетчик неудачных попыток прозвона для данного адреса и переходит к следующей позиции в очереди. Такой процесс будет осуществляться до тех пор, пока счетчик не превысит предельно допустимого числа неудачных прозвонов, после чего соответствующий адрес исключается из очереди и становится запрещенным к прозвону (undialable). Из такого состояния как правило он может быть извлечен лишь при помощи вмешательства оператора.
Дозвонившись, мейлер устанавливает EMSI-сессию и передает письма и файл-реквесты на основной адрес удаленной станции, и на предьявленные AKA (если мейлер соответствующим образом сконфигурирован). Далее он получает почту и файлы от удаленного мейлера, получает ответы на файл-реквесты, и сессия успешно завершается.