= Сообщение: 3042 из 46911 ================================ RU.FIDONET.TODAY =
От : Serguei E. Leontiev 2:5020/400 22 Nov 15 00:00:27
Кому : Alexey Vissarionov 22 Nov 15 00:00:27
Тема : Re: Очередное осеннее об острение (Fwd: 2:5020/400)
FGHI : area://RU.FIDONET.TODAY?msgid=<1187503154@ddt.demos.su>+a59e0c63
На : area://RU.FIDONET.TODAY?msgid=2:5020/545+564ef179
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
From: "Serguei E. Leontiev" <leo@sai.msu.ru>
Привет Алексей,
От 20 ноября 2015 г., 13:10:00 в fido7.ru.fidonet.today ты писал:
SEL>>>> Честно говоря, мои представления о FTN технологиях
SEL>>>> чисто теоретические, поэтому я не понимаю зачем им
SEL>>>> вообще знать друг о друге. Если несколько узлов
SEL>>>> выложат информационно идентичные сообщения с
SEL>>>> одинаковым MSGID это же не вызовет проблем и
SEL>>>> лишних пересылок, я ничего не путаю?
AV>>> MSGID содержит адрес узла, через который сообщение
AV>>> попало на FTN-сторону. Соответственно, этот адрес
AV>>> должен быть общим для всех гейтов (shared AKA).
SEL>> Я сейчас точно не помню номер документа ФИДО, который этому
SEL>> посвящён.
AV> http://ftsc.org/docs/fts-0009.001
SEL>> Hо клудж MSGID получается из заголовка Message-ID и
SEL>> наоборот.
AV> Увы...
SEL>> В моём предыдущем сообщении клудж:
SEL>> @MSGID:\xE2\x80\x82<1187503132@ddt.demos.su>\xE2\x80\
SEL>> x82ca8169ba Был получен из заголовка:
SEL>> Message-ID: <1187503132@ddt.demos.su>
AV> Последовательность \xE2\x80\x82 - это такой пробел?
Да, такой пробел вкрался.
$ printf "\xE2\x80\x82" | iconv -t C99
\u2002
XK_enspace называется, прошу прощения не доглядел при копировании.
AV> Этот MSGID не соответствует FTS-0009 и, соответственно,
М-м, почему не соответствует?
FTS-0009:
^AMSGID: origaddr serialno
The originating address should be specified in a form that constitutes a
valid return address for the originating network...The manner in which
this serial number is generated is left to the implementor.
Соответствует, грубо говоря, origaddr - <1187503132@ddt.demos.su> -
имеет структуру адреса в сети отправителя NNTP, а serialno
$ printf "<1187503132@ddt.demos.su>RU.FIDONET.TODAY" | crc32 /dev/stdin
ca8169ba
Конкретно этот метод получения serialno для MSGID описан MSGID.DOC
Version 4.2 of 01 May 1997 (Gatebau '97 standards).
AV> сообщение может восприниматься тоссерами как не имеющее MSGID.
Уже четверть века используется в разных странах, могу поставить ящик
водки, что существующие тоссеры не имеют с ним проблем.
AV> Одиночные дупы не сильно напрягают, но их поток с NNTP-гейта
AV> уже будет заметным. Другое дело, что, например, самый
AV> распространенный сейчас тоссер HPT умеет воспринимать в поле
AV> адреса вообще любую строку длиной не более 60 байтов.
SEL>>>> Конечно, если механизм "автомодерации" правильно
SEL>>>> устроен.
AV>>> Hасчет него я уже предложил решение с кучкой MX для
AV>>> fido7gate.example.net
SEL>> Под механизмом "автомодерации" имелось ввиду набор правила
SEL>> проверки допустимости сообщения, сейчас это соответствие,
SEL>> так сказать, "пароля" пользователя, его адреса и разрешения
SEL>> на группу.
AV> Аааа... Кстати, я бы сделал это на базе цифровых подписей.
Ага, и всех оснастить PGP или "КриптоПро CSP", а саму ЭЦП в новый клудж
положить :) Уверен, что существующий механизм - пароль в сообщении
достаточен.
SEL>>>> Мне видится, что все узлы закладывают
SEL>>>> информационно идентичные сообщения с одинаковым
SEL>>>> MSGID из FTN в NNTP сообщения с одинаковыми
SEL>>>> Message-ID. Другие NNTP сервера забирают сообщения
SEL>>>> с теми Message-ID, которых у них нет. Грубо
SEL>>>> говоря, кто первый сообщение выложил, того и
SEL>>>> тапки.
AV>>> Именно так - был MSGID: 2:5020/545.1 12345678, стал
AV>>> Message-ID: msgid-p1.f545.n5020.z2-12345678@fidonet.org
AV>>> Главное, чтобы на всех узлах это преобразование было
AV>>> одинаковым.
SEL>> Если мне не изменяет память, то был документ ФИДО
SEL>> описывающий это преобразование.
AV> Для адресов? http://ftsc.org/docs/fts-5004.001
AV> А для MSGID только FTS-0009.
Строго говоря, несколько FTS на эту тему существует.
AV> В общем случае я бы не рекомендовал закладываться на поведение
AV> конкретного тоссера, но раз уж оно как-то работает - можно
AV> оставить как есть, пока не появится способ лучше.
SEL>>>> Исходя из этого, я полагал бы, что надёжнее
SEL>>>> forward на все узлы, а не выбор MX. Ведь узел
SEL>>>> может быть доступным по SMTP, а сообщения, по тем
SEL>>>> или иным причинам, дальше проходить не могут.
AV>>> Вроде бы вышеописанный метод полностью исключает данную
AV>>> проблему.
SEL>> При чистом шлюзовании NNTP <-> конференции FTN этой
SEL>> проблемы, как очевидно, вообще нет. Каждое полученное и
SEL>> укладываемое в базу NNTP сообщение гейтируется в FTN, если
SEL>> срок его жизни ещё не истёк (не превысил времени хранения
SEL>> базы). И наоборот. Проблем отказоустойчивости не возникает.
AV> Зато возникают дупы.
С какого бы этим "дупам" появляться, если для одинаковых сообщений MSGID
идентичный получается у всех шлюзов?
SEL>> Проблема отказоустойчивости может возникнуть при
SEL>> "автомодерации", т.е. с момента когда шлюз получил по SMTP
SEL>> сообщение до момента когда он отдал его и в NNTP и в FTN,
SEL>> сообщение(я) могут быть задержаны на неопределённый срок
SEL>> или утеряны.
AV> В силу специфики работы я, конечно, многое видел, но такую
AV> рукожопость представляю себе с большим трудом.
Да легко, связь FTN и NNTP рубанули добрые люди и всё, кирдык. Что
встречается, к великому сожалению, иначе бы вопрос не возник бы.
SEL>> Если вероятность того, что SMTP принимает, а NNTP не
SEL>> отправляет, мала, то можно и не размножать сообщения.
AV> Hи про какое "размножение" (сознательное задупливание) речь и
AV> не идет - сообщение просто уходит на случайно выбранный MX.
Ладно, в общем, это уже детали.
--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)
|
