= Сообщение: 3039 из 46911 ================================ RU.FIDONET.TODAY =
От : Alexey Vissarionov 2:5020/545 20 Nov 15 13:10:00
Кому : Serguei E. Leontiev 20 Nov 15 13:10:00
Тема : Очередное осеннее об острение (Fwd: 2:5020/400)
FGHI : area://RU.FIDONET.TODAY?msgid=2:5020/545+564ef179
На : area://RU.FIDONET.TODAY?msgid=<1187503135@ddt.demos.su>+e236f38d
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=<1187503154@ddt.demos.su>+a59e0c63
==============================================================================
Доброго времени суток, Serguei!
20 Nov 2015 09:53:42, ты -> мне:
SEL>>> Честно говоря, мои представления о FTN технологиях чисто
SEL>>> теоретические, поэтому я не понимаю зачем им вообще знать
SEL>>> друг о друге. Если несколько узлов выложат информационно
SEL>>> идентичные сообщения с одинаковым MSGID это же не вызовет
SEL>>> проблем и лишних пересылок, я ничего не путаю?
AV>> MSGID содержит адрес узла, через который сообщение попало на
AV>> FTN-сторону. Соответственно, этот адрес должен быть общим для
AV>> всех гейтов (shared AKA).
SEL> Я сейчас точно не помню номер документа ФИДО, который этому
SEL> посвящён.
http://ftsc.org/docs/fts-0009.001
SEL> Hо клудж MSGID получается из заголовка Message-ID и наоборот.
Увы...
SEL> В моём предыдущем сообщении клудж:
SEL> @MSGID:\xE2\x80\x82<1187503132@ddt.demos.su>\xE2\x80\x82ca8169ba
SEL> Был получен из заголовка:
SEL> Message-ID: <1187503132@ddt.demos.su>
Последовательность \xE2\x80\x82 - это такой пробел?
Этот MSGID не соответствует FTS-0009 и, соответственно, сообщение может восприниматься тоссерами как не имеющее MSGID. Одиночные дупы не сильно напрягают, но их поток с NNTP-гейта уже будет заметным.
Другое дело, что, например, самый распространенный сейчас тоссер HPT умеет воспринимать в поле адреса вообще любую строку длиной не более 60 байтов.
SEL>>> Конечно, если механизм "автомодерации" правильно устроен.
AV>> Hасчет него я уже предложил решение с кучкой MX для
AV>> fido7gate.example.net
SEL> Под механизмом "автомодерации" имелось ввиду набор правила
SEL> проверки допустимости сообщения, сейчас это соответствие,
SEL> так сказать, "пароля" пользователя, его адреса и разрешения
SEL> на группу.
Аааа... Кстати, я бы сделал это на базе цифровых подписей.
SEL>>> Мне видится, что все узлы закладывают информационно идентичные
SEL>>> сообщения с одинаковым MSGID из FTN в NNTP сообщения с одинаковыми
SEL>>> Message-ID. Другие NNTP сервера забирают сообщения с теми
SEL>>> Message-ID, которых у них нет. Грубо говоря, кто первый
SEL>>> сообщение выложил, того и тапки.
AV>> Именно так - был MSGID: 2:5020/545.1 12345678, стал Message-ID:
AV>> msgid-p1.f545.n5020.z2-12345678@fidonet.org
AV>> Главное, чтобы на всех узлах это преобразование было одинаковым.
SEL> Если мне не изменяет память, то был документ ФИДО описывающий это
SEL> преобразование.
Для адресов? http://ftsc.org/docs/fts-5004.001
А для MSGID только FTS-0009.
SEL>>> И в сторону FTN, полагаю, может быть аналогично. Все
SEL>>> выкладывают сообщения, а остальные узлы как-нибудь уж
SEL>>> заберут только то, чего у них нет.
AV>> Для этого точно так же нужно, чтобы преобразование Message-ID в
AV>> MSGID было одинаковым на всех серверах.
SEL> Всё это конечно хорошо, но клудж MSGID не обязан зависеть от FTN
SEL> адреса шлюза, но должен быть однозначно связан с заголовком
SEL> Message-ID исходного NNTP или SMTP сообщения. Пойду найду документ,
SEL> который это описывает. По-моему, здесь придумывать ничего особо не
SEL> надо.
В общем случае я бы не рекомендовал закладываться на поведение конкретного тоссера, но раз уж оно как-то работает - можно оставить как есть, пока не появится способ лучше.
SEL>>> Исходя из этого, я полагал бы, что надёжнее forward на все
SEL>>> узлы, а не выбор MX. Ведь узел может быть доступным по
SEL>>> SMTP, а сообщения, по тем или иным причинам, дальше
SEL>>> проходить не могут.
AV>> Вроде бы вышеописанный метод полностью исключает данную
AV>> проблему.
SEL> При чистом шлюзовании NNTP <-> конференции FTN этой проблемы,
SEL> как очевидно, вообще нет. Каждое полученное и укладываемое в базу
SEL> NNTP сообщение гейтируется в FTN, если срок его жизни ещё не истёк
SEL> (не превысил времени хранения базы). И наоборот. Проблем
SEL> отказоустойчивости не возникает.
Зато возникают дупы.
SEL> Проблема отказоустойчивости может возникнуть при "автомодерации",
SEL> т.е. с момента когда шлюз получил по SMTP сообщение до момента
SEL> когда он отдал его и в NNTP и в FTN, сообщение(я) могут быть
SEL> задержаны на неопределённый срок или утеряны.
В силу специфики работы я, конечно, многое видел, но такую рукожопость представляю себе с большим трудом.
SEL> Если вероятность того, что SMTP принимает, а NNTP не отправляет,
SEL> мала, то можно и не размножать сообщения.
Ни про какое "размножение" (сознательное задупливание) речь и не идет - сообщение просто уходит на случайно выбранный MX.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Рожденный ползать, уйдите со взлетной полосы!
--- /bin/vi
* Origin: http://openwall.com/Owl/ru (2:5020/545)
|
