= Сообщение: 40525 из 47141 =============================== RU.FIDONET.TODAY =
От : Nil A 2:5015/46 12 Jan 24 22:15:58
Кому : Alexey Fayans 12 Jan 24 22:15:58
Тема : Ftrack, RNTrack, ..
FGHI : area://RU.FIDONET.TODAY?msgid=2:5015/46+65a19364
На : area://RU.FIDONET.TODAY?msgid=2:5030/1997@fidonet+65a16851
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5030/1997@fidonet+65a1a178
Ответ: area://RU.FIDONET.TODAY?msgid=2:460/5858+65a38e14
==============================================================================
Hello, Alexey!
Friday January 12 2024 18:32, from Alexey Fayans -> Nil A:
NA>> Не встречал, чтобы треккалка в поинтлист заглядывала.
AF> "Если я не вижу монстра, монстр не видит меня"
AF> CheckPoints: <Mode>
Прикольно. Я только начал читать доку по RNTrack.
По гибкости написания правил я уже польщен, чтобы не обращаться к хукам.
AF> В смысле, входит ли адресат в подхабник определённого хаба. Нужно для
AF> того, чтобы роутить нетмейл без всяких *.rou/*.tru. Если у тебя в
AF> линках несколько хабов, ты при помощи простого правила роутишь на них
AF> письма для всех, кто в их подхабниках.
Удобно. Надо чтобы fidoroute, плюс к *.rou/*.tru, умела находить, если возможно, короче маршруты через линков-хабов.
Или даже так, чекалку написать отдельную, на входе *.rou/*.tru и nodelist, на выходе ворнинги, что не все подхабовые линки указаны.
AF>>> - Уметь распаковывать аутбаунд, проверять возраст писем оттуда и
AF>>> возвращать письма отправителю, если они протухли, с
AF>>> соответствующим уведомлением.
NA>> Но это всё как фантазия у шизопа работает, такие всякие проверки,
NA>> ибо документов регулирующих такие требования нет imho.
AF> Бонус здесь ещё в том, что если письма запаковались на линка, который
AF> внезапно перестал выходить на связь, то достаточно убрать его из
AF> конфига, и в следующий раз, когда письма распакуются из аутбаунда, они
AF> уже уйдут по другому маршруту (если ещё не протухли).
Охохо, трекалка умеет смотреть в аутбаунд, чтобы от туда протоссить? Т.е. она постоянно "перетоссивает" всё по-новому?
NA>> Так бы и обычному ноду, не хабу, желательно это делать.
AF> Ну так делайте, кто мешает? В любом нормальном нетмейл трекере это
AF> базовый функционал и очень легко реализуется. В документации RNtrack
AF> есть примеры.
hpt только ловит в эхах PATH закольцованный, или не ловит. Но hpt ловит дупы в эхах. С нетмейлом она крайне просто работает.
AF> Вопрос в другом. Нахрена это всё пихать в hpt? Это совсем не
AF> "чуть-чуть допилить" существующий функционал.
Чтобы можно было писать mask и action правила и для эх. Например, если FromAddr в эхе не из нодлиста.
Вот ещё мысли, просто воздух сотрясаю, но всё же. Есть формат BSO, стандарт http://ftsc.org/docs/fts-5005.003 но это аутбаунд, ну чтобы мейлер знал, откуда что брать после упаковщика. На инбаунд стандарт только что есть каталог, куда наваливаются файлы, и типа protected, unsecure, local, так?
Вот если изобрести стандарт на инбаунд, который сохраняет информацию о принятых файлах, не просто из парольной/непарольной сессии, но и с какого линка пришло (а то и время, ip, ..), то можно было бы писать правила ещё круче. Например, почта с моих пойнтовых линков может только соответствовать from именно поинт.
И вообще, писать правила FromAddr этож From в письме, а тут у нас как минимум ещё есть 3 координаты: FromLink (физически принятый), FromAddrPkt (хедер самого .pkt), FromAddr (фром письма).
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
|
