= Сообщение: 40581 из 47152 =============================== RU.FIDONET.TODAY =
От : Stas Mishchenkov 2:460/5858 14 Jan 24 10:04:52
Кому : Nil A 14 Jan 24 10:04:52
Тема : Ftrack, RNTrack, ..
FGHI : area://RU.FIDONET.TODAY?msgid=2:460/5858+65a38e14
На : area://RU.FIDONET.TODAY?msgid=2:5015/46+65a19364
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5015/46+65a3ed49
==============================================================================
Hi Nil!
12 Jan 24 22:15, Nil A -> Alexey Fayans:
NA>>> Не встречал, чтобы треккалка в поинтлист заглядывала.
AF>> "Если я не вижу монстра, монстр не видит меня"
AF>> CheckPoints: <Mode>
NA> Прикольно. Я только начал читать доку по RNTrack.
NA> По гибкости написания правил я уже польщен, чтобы не обращаться к хукам.
А в чём разница? Что в конфиге правило написать, что в перлхуке.
AF>> В смысле, входит ли адресат в подхабник определённого хаба. Нужно для
AF>> того, чтобы роутить нетмейл без всяких *.rou/*.tru. Если у тебя в
AF>> линках несколько хабов, ты при помощи простого правила роутишь на них
AF>> письма для всех, кто в их подхабниках.
NA> Удобно. Надо чтобы fidoroute, плюс к *.rou/*.tru, умела находить, если
NA> возможно, короче маршруты через линков-хабов.
А зачем? Если у тебя парольный линк, то ты знаешь и так, что на него короче роутить.
NA> Или даже так, чекалку написать отдельную, на входе *.rou/*.tru и
NA> nodelist, на выходе ворнинги, что не все подхабовые линки указаны.
Если бы Ping/Trace поддерживало достаточное количество узлов, то это можно было бы выяснять экспериментальным путём и даже автоматически.
AF>> Бонус здесь ещё в том, что если письма запаковались на линка, который
AF>> внезапно перестал выходить на связь, то достаточно убрать его из
AF>> конфига, и в следующий раз, когда письма распакуются из аутбаунда, они
AF>> уже уйдут по другому маршруту (если ещё не протухли).
NA> Охохо, трекалка умеет смотреть в аутбаунд, чтобы от туда протоссить? Т.е.
NA> она постоянно "перетоссивает" всё по-новому?
Да. Если ей сказать так делать. У hpt для этого есть bsopack, если я не ошибаюсь.
NA>>> Так бы и обычному ноду, не хабу, желательно это делать.
AF>> Ну так делайте, кто мешает? В любом нормальном нетмейл трекере это
AF>> базовый функционал и очень легко реализуется. В документации RNtrack
AF>> есть примеры.
NA> hpt только ловит в эхах PATH закольцованный, или не ловит.
Не ловит.
NA> Но hpt ловит дупы в эхах.
Ловит и этого достаточно.
NA> С нетмейлом она крайне просто работает.
Там есть для этого filter.pl, который, по сути, является ещё одним конфигурационным файлом для написания правил и всяческих проверок. Гибче некуда.
AF>> Вопрос в другом. Нахрена это всё пихать в hpt? Это совсем не
AF>> "чуть-чуть допилить" существующий функционал.
NA> Чтобы можно было писать mask и action правила и для эх. Например, если
NA> FromAddr в эхе не из нодлиста.
Это не сложно, но зачем?
NA> Вот ещё мысли, просто воздух сотрясаю, но всё же. Есть формат BSO,
NA> стандарт http://ftsc.org/docs/fts-5005.003 но это аутбаунд, ну чтобы
NA> мейлер знал, откуда что брать после упаковщика. На инбаунд стандарт
NA> только что есть каталог, куда наваливаются файлы, и типа protected,
NA> unsecure, local, так?
NA> Вот если изобрести стандарт на инбаунд, который сохраняет информацию о
NA> принятых файлах, не просто из парольной/непарольной сессии, но и с какого
NA> линка пришло (а то и время, ip, ..), то можно было бы писать правила ещё
NA> круче.
Как ты себе представляешь приход pkt от одного парольного линка, в котором pktfrom будет соответствовать другому твоему парольному линку? В не парольном инбаунде можно конечно проверять pktfrom на наличие в нодлисте, но это не приемлемо для NC. Если ты-таки не хочешь принимать непарольную почту от unlisted узлов, то выставляешь в нодлисте флаг LO и сообщаешь об этом мейлеру.
NA> Например, почта с моих пойнтовых линков может только
NA> соответствовать from именно поинт.
В hpt у пакетов это проверяется. У сообщений это проверять не самая удачная идея. Проверять fromname, опять же, не есть хорошая мысль, т.к. у поинта может быть BBS.
NA> И вообще, писать правила FromAddr этож From в письме, а тут у нас как
NA> минимум ещё есть 3 координаты: FromLink (физически принятый),
NA> FromAddrPkt (хедер самого .pkt),
Обычно они соответствуют. А если и нет, то и что? Главное, что бы FromAddrPkt (хедер самого .pkt) соответствовал твоему парольному линку.
NA> FromAddr (фром письма).
FromAddr (фром письма) вполе может быть любой. Даже поинту не запрещено подставить свой aka, для того, что бы ответ пришел через другой узел.
Have nice nights.
Stas Mishchenkov.
--- Перестань пытаться сделать каждого счастливым, ты не текила.
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
|
