AF>>> Тоссеру не нужно ни для каких целей как минимум следующее: AF>>> - Проверять наличие отправителя или получателя в нод/поинтлисте. NA>> Не встречал, чтобы треккалка в поинтлист заглядывала. Даже когда NA>> поинт-листы были во всех сетках и по объёму больше нодлиста.
AF> "Если я не вижу монстра, монстр не видит меня"
AF> === Start of Windows Clipboard === AF> CheckPoints: <Mode> AF> ------------ AF> This keyword defines checking of points existence in pointlist AF> <Mode> : Never - Do not check AF> : Hard - To check "hardly". AF> : Soft - To check "softly". AF> This keyword is described in more details in chapters 10.1 and 10.2 AF> If the keyword is omitted then Checkpoints: is set to Never AF> === End of Windows Clipboard ===
Такая фильтрация правомочна только для собственных поинтов.
AF>>> - Уметь определять принадлежность адреса к хабу. NA>> Вмысле, являюсь лия сам хаб, тогда буду принимать почту на подхабник?
AF> В смысле, входит ли адресат в подхабник определённого хаба. Нужно для AF> того, чтобы роутить нетмейл без всяких *.rou/*.tru. Если у тебя в линках AF> несколько хабов, ты при помощи простого правила роутишь на них письма для AF> всех, кто в их подхабниках. Примерно так:
AF> === Start of Windows Clipboard === AF> Mask: * * * 2:50/1000.& * * AF> Mask: * * * 1:100/2000.& * * AF> Action: RouteHub Direct AF> === End of Windows Clipboard ===
И таблица роутинга в стиле hpt мне кажется более прозрачной.
AF> Затем, чтобы одним простым правилом роутить почту для своих даунлинков. AF> Как в примере выше, только в меньших масштабах.
Прекрасно. А на сколько легко реализуется "управляемый" роутинг? Ну, что бы я мог в своём сообщении написать что-то типа %RouteTo: 2:5020/570 2:460/58 и сообщение на узле 2:460/58 зароутилось на узел 2:5020/570.
AF>>> - Уметь распаковывать аутбаунд, проверять возраст писем оттуда и AF>>> возвращать письма отправителю, если они протухли, с AF>>> соответствующим уведомлением. NA>> Но это всё как фантазия у шизопа работает, такие всякие проверки, ибо NA>> документов регулирующих такие требования нет imho.
AF> Требований никто таких не предъявляет, но у всех, кто уважает своих AF> линков, это реализовано. И правила, опять же, очень простые и наглядные, AF> никаких на коленке писанных перловых скриптов.
Только на коленке писанные конфиги? ;)
AF> Бонус здесь ещё в том, что если письма запаковались на линка, который AF> внезапно перестал выходить на связь, то достаточно убрать его из AF> конфига, и в следующий раз, когда письма распакуются из аутбаунда, они AF> уже уйдут по другому маршруту (если ещё не протухли).
Ну, дык, в hpt тоже так будет, если линка из конфига убрать.
AF>>> - Уметь отлавливать лупы. NA>> Так бы и обычному ноду, не хабу, желательно это делать.
AF> Ну так делайте, кто мешает? В любом нормальном нетмейл трекере это базовый AF> функционал и очень легко реализуется. В документации RNtrack есть примеры.
Многие и делают.
AF> Вопрос в другом. Нахрена это всё пихать в hpt? Это совсем не AF> "чуть-чуть допилить" существующий функционал.
Если сообщение уже бывало у нас, то дальше по кругу оно не пойдёт, а все заинтересованные лица будут предупреждены об этом нетмейлом. RNtrack умеет так или только заворачивает сообщение обратно отправителю?
Have nice nights. Stas Mishchenkov.
--- Умные мысли приходят лишь тогда, когда херня уже сделана. * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
