оперативно сменить провайдера, сменить адрес, писать от чужого или выдуманного
имени;
- Взаимная ответственность существует, например, в виде отключения клиента
провайдером, блокирования почты от провайдера, который не отключает спамера и
т.п. Однако поскольку единой структуры не существуют, эти действия не являются
ни для кого обязательными и не слишком эффективны;
Подводя итог, можно сказать, что в Интернет нет механизма, который позволял бы
эффективно и на длительное время пресекать чьи-либо некорректные действия.
Причем отсутствие такого механизма обусловлено самими принципами организации и
развития сети.
Поскольку в FidoNet такой механизм есть, гейтование часто воспринимается как
явление, его разрушающее или ослабляющее (и как следствие - снижающее
конструктивность и комфортность общения).
Наилучший выход - способствовать развитию FTN over IP, улучшать программное
обеспечение для такого доступа. Роль полного гейтования в развитии FidoNet
должна быть снижена, достаточно использовать R/O гейтование, чтобы показать
потенциальным пользователям содержимое эх.
# - в эхе начинают смешиваться
разные темы, важные сообщения теряются среди прочих и т.д.
Разделение может происходить по двум признакам:
- По тематике;
- По степени важности публикуемых писем;
Пример первого варианта - известное разделение эхи SU.HARD&SOFT на SU.HARDW и
SU.SOFTW, а затем разделение SU.HARDW на множество эх SU.HARDW.*
Второй вариант можно проиллюстрировать на примерах:
SPB.SYSOP -> SPB.SYSOP + SPB.SYSOP.INFO
(и позднее появившихся SPB.SYSOP.TALK , SPB.SYSOP.IMHO, SPB.SYSOP.FILTERED)
R50.SYSOP -> R50.SYSOP + R50.SYSOP.TALK
(и позднее появившихся R50.SYSOP.CLUB, R50.SYSOP.DRUNK, R50.SYSOP.INFO)
Рассмотрим одно интересное отличие - так называемый (условно) "питерский" и
"московский" подход к разделению сисопской эхи. На определенном этапе с эхами
R50.SYSOP и SPB.SYSOP возникла проблема - слишком большой трафик, в котором
трудно было находить важные для функционирования сети сообщения. Стало ясно, что
должна появиться эха, где будут публиковаться только важные сообщения, чтобы
сисопы, у которых нет времени на чтение всего трафика, были в курсе основных
событий.
Эта задача решалась по-разному:
Дополнительно к R50.SYSOP была создана R50.SYSOP.TALK , причем в .TALK были
вынесены совсем общие разговоры, а в R50.SYSOP введены ограничения ("московский"
подход).
Дополнительно к SPB.SYSOP была создана SPB.SYSOP.INFO, причем сам SPB.SYSOP
остался для общих разговоров, а в SPB.SYSOP.INFO были введены ограничения
("питерский" подход).
Представляется, что второй подход имеет то преимущество, что он не требует
специальных действий по подавлению разговоров, смене тематики в исходной эхе
(SPB.SYSOP) - просто создается новая (SPB.SYSOP.INFO).
С другой стороны ясно, что в случае с первым вариантом тем, кого интересует лишь
важная информация, нет необходимости специально подписываться на новую эху - они
получают все ту же старую, но "очищенную" (R50.SYSOP).
Позднее описанное здесь состояние эх частично изменилось, однако вопрос о
способе разделения возникал и в других случаях.
Похожая ситуация была с SPB.FILES, дополнительно к которой появилась
SPB.FILES.NEW
В SPB.FILES.NEW стали публиковаться анонсы о новых файлах доступных для FREQ, а
в SPB.FILES запросы (ранее и то и другое происходило в одной SPB.FILES)
Позднее появились также
SPB.FILES.TALK, SPB.FILES.ALLFIX, SPB.FILES.MP3.ROCK, SPB.FILES.VIDEO.
Более нейтральной ситуаций является добавление к уже существующей эхе
вспомогательных.
Например, DEMO.DESIGN -> DEMO.DESIGN + DEMO.DESIGN.UUE + DEMO.DESIGN.WANTED
В этом случае .UUE эха служила для публикации UUE файлов (небольшие intro,
исходники и т.п.) по тематике DEMO.DESIGN, а .WANTED - для поиска файлов.
Стоит добавить, что при разделении эхи желательно создавать новые
дополнительно к существующей, а не вместо нее. Это связано с трудностью
ликвидации эх.
#) запрещают обычным
подписчикам писать туда напрямую. Таким правом обладает только модератор и
назначенные им помощники. Именно им следует отсылать письма, предназначенные для
публикации в эхе. Если у модератора или его помощников нет возражений, то письмо
помещается (форвадится) ими в эху (при этом оно обычно адресовано к "All").
Иногда модератор с помощниками коллективно принимают решения об изменении своего
состава - исключении или принятии кого-либо на основании качества
присылаемых/публикуемых писем (RU.UFO.SCEPTIC
#).
На раздающих узлах такие эхи желательно поставить в Read Only.
В некоторых эхах по определенному признаку ограничен круг людей, имеющих право
туда писать. Например, N5020.HUBS
# - только эхохабы 5020, R50.COORD
# - только
координаторы региона R50.
Эхи ограниченного распространения допускают их раздачу только оговоренному кругу
подписчиков (к примеру, только сисопам данной сети). Возможна ситуация, когда
распространение не ограничено, но круг тех, кто может помещать в эху сообщения -
ограничен (например, в R50.SYSOP
#, N5020.SYSOP
# запрещено писать поинтам и
пользователям BBS).
Официальные эхи (некоторые *.SYSOP) обычно подразумевают, что их модератором
является не конкретный человек, а должностное лицо (например, текущий NC сети или RC
региона). Такая практика существует как минимум в 43 из всех 119 сетей
R50 (по 55 сетям данных нет.
Ноябрь 2003 года)
#.
Соответственно, при смене *C автоматически меняется и модератор.
Здесь необходимо отметить недопустимость ситуации, когда *C лишь назначает
модератора. Человек, однажды назначенный модератором, в спорной ситуации
(например, при утрате *C авторитета) сможет изменить правила или заявить, что
поскольку модератор является хозяином эхи, то сместить его нельзя.
Соответственно, официальная эха окажется захваченной.
Если у *C нет времени, чтобы непосредственно модерировать эху, лучшее решение -
назначение комодератора.
Информационные эхи:
Помимо уже упомянутой ситуации, когда в эху могут писать не все, существует
другой вариант - когда писать могут все, но отвечать/обсуждать не имеет права
никто. Это относится к эхам, которые предназначены исключительно для публикации
текстов, объявлений или новостей - SU.MUSIC.NEWS, SU.TOLKIEN.TEXTS, MO.JOB,
RU.INTERNET.FILTERED, RU.FIDONET.DIGEST и т.п.
Немодерируемые эхи:
В настоящее время, в связи с действиями провокаторов, отсутствие модератора -
как правило временное состояние. Такие эхи не поднимаются на бон либо снимаются
оттуда в случае длительного отсутствия модератора.
Локалки:
Обычно так называют эхи, которые узел раздает только своим поинтам и
непосредственным даунлинкам (и, возможно, их поинтам). Однако дальнейшее
распространение локалок редко ограничивается.
Модератором является узел - создатель эхи. Жестких правил или тематики обычно
нет.
#. При этом наиболее важные пункты должны быть видны на экране без прокрутки
(вероятно, стоит исходить из чтения в GoldEd'e при размерах окна 80x25).
За счет чего можно сократить правила? Не являются важными те моменты, которые
боссы и так должны объяснять поинтам, а также очевидные вещи. К примеру:
пересказ официальных документов FIdoNet, подробное описание флейма, о
недопустимости overquoting'a, offtopic'a, о необходимости указания в Subj
настоящей темы письма.
Однако некоторые очевидные вещи нужно указать в том случае, если именно для
вашей эхи они являются ключевыми. Например, если эха о политике, то нужно
особенно подчеркнуть недопустимость флейма, разжигания межнациональной розни.
Если эха о какой-либо конкретной операционной системе или платформе - нужно
подчеркнуть недопустимость обсуждения преимуществ других ОС или платформ, и т.д.
Для многих эх следует специально упомянуть о запрете рекламы и коммерции.
Можно предложить следующую структуру правил:
Правила <...название эхи...>
...о чем эта эха (тематика)...
...что в эхе запрещено (по пунктам)...
...другие важные моменты...
...технические требования к письмам (языки, ...)...
...ограничения области распространения (гейтование, ...)...
...информация о FAQ (если он есть)...
...принципы модерирования (наказания, сроки действия, ...)...
...кто модератор (комодераторы) и как с ними связаться....
...предыдущие модераторы эхи (если были)...
...список отключенных подписчиков (если есть)...
Частота публикации правил зависит от эхи. В общем случае рекомендуется делать
это раз в две недели, однако, если трафик небольшой и круг подписчиков почти
постоянный, можно увеличить срок до месяца (при этом и отношение к нарушениям
новых подписчиков должно стать более терпимым).
Могут быть и промежуточные варианты - например, если вы не хотите уменьшать
правила, разбейте их на две части. Первая будет краткая, в ней самая суть (см.
выше). Вторая - все остальное. Первую можно публиковать часто, вторую - редко.
Если есть возможность, полезно опубликовать правила в Интернет, а в Origin ваших
писем поместить ссылку на сайт.
При изменении уже существующих правил нужно учитывать, что изменения станут
известны большинству подписчиков не сразу после их публикации. Обычно
модератором дается 24 или 48 часов, иногда - до недели.
Изменения не имеют обратной силы - по новым правилам наказания следуют только за
новые нарушения.
Публикуя измененные правила нужно предупредить (вверху, или отдельным письмом),
что правила изменились. Изменения или наиболее важные пункты бывает полезно
выделить цветом (квотингом), добавив знак ">" в начале строки.
В Subject'e должно присутствовать слово "rules",
для удобства поиска правил в эхе подписчиками (например:
"Rules of R46.SYSOP").
Русское слово "Правила" менее удобно при поиске.
# - структура, предназначенная для распространения эхопочты, принципы
работы (обязанности, ограничения) которой зафиксированы в каких-либо документах
(эхополиси) или неформальной договоренности между хабами, узлами входящими в
состав бэкбона. В наличии такой договоренности и эхокоординатора, следящего за
ее соблюдением, состоит отличие бэкбона от обычного распространения эх между
узлами сети.
Бэкбон может быть мировым, зональным, региональным и сетевым.
Региональный бэкбон предназначен для распространения эх между сетями.
Соответственно, на нем почти отсутствуют локальные эхи отдельных сетей -
распространяются только то, что интересно всему региону. На сетевом - напротив,
бывают эхи как локальные, так и региональные. На данный момент (2003) в крупных
сетях количество эх на сетевых бэкбонах больше, чем на региональном (в 2-6 раз).
Говоря о R50 (и даже о Fido7 в целом) можно отметить наличие бэкбонов во многих
сетях, однако, как правило, сетевые эхополы отсутствуют - используется либо
R50EP
#, либо здравый смысл хабов.
Поскольку R50EP является наиболее известным документом, признанным (полностью
или частично) во многих сетях, далее основное внимание уделим ему.
R50EP подразумевает и включает следующие основные моменты:
- Выполнение R50EP хабами, входящими в состав бэкбона и модераторами, которые
изъявили желание распространять свою эху через бэкбон. В частности, хабы обязаны
распространять все эхи, поднятые на бэкбон;
- REC избирается
# *С, *EC, региональными эхохабами и координирует хождение эх на
бэкбоне, соблюдение R50EP. В том числе он ведет эхолист, определяет состав
бэкбона, решает, может ли эха быть принята на бэкбон, снимает эхи с бэкбона;
- Бэкбон и REC помогают модераторам обеспечивать отключения узлов, нарушающих
правила эх;
- Модераторы, если они хотят, чтобы их эха оставалась на бэкбоне, обязаны
выполнять требования REC;
- Бэкбонная эха не может существовать на бэкбоне без модератора;
По последнему пункту нужно заметить, что не существует эффективного способа
определять, есть ли еще в эхе действующий модератор. Для REC физически
невозможно регулярно читать столько эх, а автоматизации этот процесс вряд ли
поддается, поскольку, например, факты регулярной публикации в эхе правил или
писем от имени модератора не означают наличия там действительного модератора.
Поэтому предполагается, что в случае возникновения в эхе беспорядков,
возмущенные подписчики обратятся к REC самостоятельно, и тогда он будет изучать
вопрос уже по конкретной эхе.
Важно, что бэкбон формально является дополнительной услугой по распространению
эх. В принципе, прямой необходимости поднимать на бэкбон эху (и, таким образом,
соглашаться с действующими там правилами) у модераторов нет. Можно наладить
альтернативное хождение, в том числе и через хабы, из которых состоит бэкбон
(просто распространение эхи в таком случае будет персональным решением каждого
из хабов). Однако стабильное и качественное хождение, конечно, требует поднятия
эхи на бэкбон.
В случае с региональным бэкбоном важную роль играет тот факт, что его хабы
являются узлами сети 5020 (Москва).
Из этого следует частичное совпадение регионального бэкбона с московским.
Распространение эх для обоих бэкбонов иногда выполняют физически одни и те же
узлы.
При этом число эх на том и другом боне, естественно, отличается. Например, в
2002 году на R50BONE их было около 400, а на N5020BONE - примерно 1400 (кстати,
последнее число примерно совпадает с количеством правил в базе Григория
Зельднера
# на 2003 год).
Тот факт, что региональный бэкбон физически расположен в Москве, легко объясним,
поскольку в столице легче обеспечить доступ к хорошим каналам связи и
оборудованию и число узлов FidoNet больше, чем в других сетях. Однако такое
расположение бона подразумевает некий (как правило, неосознанный) диктат по
отношению к другим сетям, а также создает серьезную угрозу FidoNet в случае
каких-либо чрезвычайных ситуаций. Обмен почтой между регионами большей частью
осуществляется через 5020, региональные координаторы также, как правило, из
Москвы.
К сожалению, существенно повлиять на такое положение дел пока вряд ли возможно.
Другое дело - создание резервов. Единственным известным экспериментом в этой
области является так называемый PROVINCE бон, созданный для отработки именно
горизонтальных связей (уже упоминавшийся в разделе "История...").
Еще одной крайней ситуацией является концентрация большого количества линков из
различных сетей на одном из хабов бэкбона (иначе говоря, неравномерное
распределение линков между хабами). В случае проблем с этим хабом большая часть
сети может остаться без почты.
Представляется, что недопустимость такого перекоса следует закрепить в новой
версии R50EP, например, в виде максимально допустимой между хабами разницы в
числе линков. В качестве дополнительной меры - запрет сисопу наиболее крупного
(по числу линков) узла региона избираться в R50EC, чтобы не потерять возможность
внешнего контроля над подобными узлами.
Что касается принятия эхи на бэкбон, то этот процесс во многом аналогичен
обычному распространению эхи. Модератор должен отослать письмо соответствующему
*EC, в котором будут правила эхи и строчка для эхолиста. Более подробно правила
принятия на тот или иной бэкбон обычно доступны у *EC и иногда публикуются им в
эхах (например, в RU.MODERATOR, *.SYSOP).
Не рекомендуется поднимать эху одновременно на два бэкбона, поскольку в этом
случае неясно, какой из *EC будет разрешать спорные ситуации по ней.
Существование бэкбона дает возможность *EC применять к нарушителям такую меру,
как "отключение от бэкбона", что означает отключение узла (поинта) от всех эх
бэкбона. При этом реакцией на нарушение режима R/O может быть комплейн от *EC направленный *C.
#;
5.Осуществлять просмотр/поиск/работу с правилами эх;
Некоторых из такого рода программ перечислены в
приложении.
#.
Помимо трудностей с организационной точки зрения, этот подход не имеет пока
практической ценности, поскольку механизм выражения недоверия модератору уже
существует в косвенной форме (уход подписчиков, отказ транзитных узлов
распространять эху). Дублирование же его через регулярные перевыборы пока
представляется излишним (и создает дополнительные риски, свойственные любым