= Сообщение: 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) |