= Сообщение: 2139 из 2735 =================================== RU.FTN.DEVELOP = От : Alexey Vissarionov 2:5020/545 02 May 23 07:15:00 Кому : Alexey Khromov 02 May 23 07:15:00 Тема : Inbound/ProtInbound/LocalInbound и что-то среднее FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/545+64508f5c На : area://RU.FTN.DEVELOP?msgid=2:5030/722.143+64474caf = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5015/46+64509c2e ============================================================================== Доброго времени суток, Alexey! 25 Apr 2023 06:32:04, ты -> Nil A:
NA>> И тут, вуаля, мы готовы изобрести новый энтити, типа инбаунд такой NA>> полу секьюрный, полу-не-очень. А мы проверяем, если к нам пришла бинк NA>> сессия, и IP из нодлиста (после всех этапов резолва и CNAME резолюции, NA>> разумеется), и таким мы верим чуть больше, чем пид@расам, которые NA>> просто вбили первый попавшийся адрес в мейлер и фрекают там чего могут NA>> нафрекать. AK> Зачем изобретать новый entity? Если binkd с помощью плагина определит, AK> что адрес из нодлиста - пусть кидает в Protected (т.к. сисоп верит AK> нодлисту). Если непарольная сессия с адресом не из нодлиста (например, AK> заявка на узел и другие прописанные случаи) - кидаем в Insecure AK> Inbound.
А еще можно использовать binkp over ssh - в этом случае все совсем просто.
AK> Так дойдем до использования нейросетей и еще конкретнее определим, AK> куда кидать pkt. А у тоссера количество инбаундов при одинаковой AK> обработке увеличивать смысла нет.
Нью-Васюковщина...
AK> И все вышесказанное касается только раздельной файловой обработки AK> почты, и неприменимо для интегрированных пакетов, hotdoged-а и AK> прочих комбайнов.
Вы за все время обсуждения еще даже задачу не сформулировали.
-- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Мое мнение может меняться, но моя правота - непоколебимый факт --- /bin/vi * Origin: ::1 (2:5020/545)
