Фреки по-роутингу

Stas Mishchenkov написал(а) к Oleg Redut в Nov 23 06:10:46 по местному времени:

Нi Oleg!

01 Nov 23 08:46, Oleg Redut -> Stas Mishchenkov:

OR>>> И вполне возможно предположение транзитнго узла, что если он
OR>>> пропустит письмо с фреком, то ему в ответ свалится аттач для
OR>>> транзита.
OR>>> :-\

SM>> Совсем не факт. Ответ вполне может пойти по другому пути.

OR> Как не факт, что он пойдёт по другому пути. Если роутинг через меня.

Роутинг аттачей может быть настроен иначе. Вообще роутинг в обратную сторону может быть другим.

Нave nice nights.
Stas Mishchenkov.

--- Самое сложное на anekdot.ru - это отделить анекдоты от новостей.

Oleg Redut написал(а) к Stas Mishchenkov в Nov 23 12:17:32 по местному времени:

Доброе (current) время суток, Stas!

OR>> Как не факт, что он пойдёт по другому пути. Если роутинг
OR>> через меня.

SM> Роутинг аттачей может быть настроен иначе. Вообще роутинг в обратную
SM> сторону может быть другим.

Может. Но это уже не произвольный "фрек по роутингу", а жёсткая схема запроса/отправки файлов по заданной цепочке узлов. Когда каждый узел будет знать, что через него ходят файлы и должен отдельно настраивать для них направление отправки. Если будет запрос с произвольного узла, то вовсе не факт, что обратный роутинг до него сможет доставить файл.
Поэтому сабж - это отдельно строящаяся между узлами договорная схема. А не общедоступный сервис.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)

Stas Mishchenkov написал(а) к Oleg Redut в Nov 23 11:04:42 по местному времени:

Нi Oleg!

01 Nov 23 12:17, Oleg Redut -> Stas Mishchenkov:

OR>>> Как не факт, что он пойдёт по другому пути. Если роутинг
OR>>> через меня.

SM>> Роутинг аттачей может быть настроен иначе. Вообще роутинг в обратную
SM>> сторону может быть другим.

OR> Может. Но это уже не произвольный "фрек по роутингу", а жёсткая схема
OR> запроса/отправки файлов по заданной цепочке узлов. Когда каждый узел будет
OR> знать, что через него ходят файлы и должен отдельно настраивать для них
OR> направление отправки. Если будет запрос с произвольного узла, то вовсе не
OR> факт, что обратный роутинг до него сможет доставить файл.
OR> Поэтому сабж - это отдельно строящаяся между узлами договорная схема. А
OR> не общедоступный сервис.

Мне почему-то кажется, что роутить аттачи согласится на не много меньшее число сисопов, чем согласно роутить нетмейл.

Нave nice nights.
Stas Mishchenkov.

--- Не откладывай пьянку на завтра, а секс на старость.

Egor Glukhov написал(а) к Stas Mishchenkov в Nov 23 11:14:44 по местному времени:

Stas,

01 Nov 23 11:04, you wrote to Oleg Redut:

SM>>> Роутинг аттачей может быть настроен иначе. Вообще роутинг в обратную
SM>>> сторону может быть другим.
OR>> Может. Но это уже не произвольный "фрек по роутингу", а жёсткая
OR>> схема запроса/отправки файлов по заданной цепочке узлов. Когда каждый
OR>> узел будет знать, что через него ходят файлы и должен отдельно
OR>> настраивать для них направление отправки. Если будет запрос с
OR>> произвольного узла, то вовсе не факт, что обратный роутинг до него
OR>> сможет доставить файл.
OR>> Поэтому сабж - это отдельно строящаяся между узлами договорная
OR>> схема. А не общедоступный сервис.
SM> Мне почему-то кажется, что роутить аттачи согласится на не много меньшее
SM> число сисопов, чем согласно роутить нетмейл.

Я бы не согласился. Просто зачем?

Егор Глухов
--- GoldED+/LNX 1.1.5-b20230304

Nil A написал(а) к Vladimir Donskoy в Nov 23 19:16:42 по местному времени:

Нello, Vladimir!

Tuesday October 31 2023 22:33, from Vladimir Donskoy -> Oleg Redut:

OR>> Если мой узел получает письмо с флагом frq, то как ты выше
OR>> утверждаешь: "должен его обработать своим софтом и как-то
OR>> отреагировать".

VD> Если письмо адресовано тебе - да, транзитник - пропустить и не
VD> портить.

ru.husky баг-репорт?

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Vladimir Donskoy написал(а) к Oleg Redut в Nov 23 17:46:10 по местному времени:

Нello Oleg!

01 ноя 23 08:51, Oleg Redut wrote to Vladimir Donskoy:

OR>>> Если отмотать тред, то там имеется такая фраза.

OR>>> === Вырезка из филе Windows Clipboard ===

NA>>>>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,

OR>>> === Кончилась врезка ===
OR>>> frq - флаг нетмайла. .req - расширение файла запроса.
OR>>> Поэтому я и спросил у автора: не перепутаны ли понятия. После
OR>>> чего ты начал что-то уточнять и увёл разговор в другую сторону.

VD>> С какой стати хаски что-то делает с транзитными письмами,
VD>> имеющими флаг frq? Его дело только отроутить письмо дальше, а не
VD>> портить!

OR> А причём тут хаски и frq, если речь про "Req нетмейл"?

См. выше - хаски из писем делает файл. Почему она не проверяет, что именно может делать узел-получатель, в каком формате ему нужен запрос на фрек - не знаю. Видимо, тут надо выяснять у разработчиков или опытных пользователей, знающих как там реазиваны фреки...

OR>>> Предположительно "получение некоего ответа". Ибо не холд -
OR>>> это уже отдельная сущность: аттач по роутингу.

VD>> Да, это "роутинг файлов", давным-давно известный в ФИДО и
VD>> постоянно применяемый для передачи нод- и поинт-сегментов,
VD>> например.

OR> Только это аттач по роутингу. Никак не связанный с фреками.

Именно, это и есть ответ на фрекписьмо, пришедшее по роутингу куда-то. Этот ответ (аттач) поедет по роутингу для файлов.

С уважением, Vladimir Donskoy.

--- GoldED+/W64-MSVC 1.1.5-b20231025

Vladimir Donskoy написал(а) к Nil A в Nov 23 19:55:25 по местному времени:

Нello Nil!

02 ноя 23 19:16, Nil A wrote to Vladimir Donskoy:

OR>>> Если мой узел получает письмо с флагом frq, то как ты выше
OR>>> утверждаешь: "должен его обработать своим софтом и как-то
OR>>> отреагировать".

VD>> Если письмо адресовано тебе - да, транзитник - пропустить и не
VD>> портить.

NA> ru.husky баг-репорт?

Я хаски не пользуюсь, так что пусть те кто пользуется - проверят и если она так и в самом деле поступает - шлют репорты.

С уважением, Vladimir Donskoy.

--- GoldED+/W64-MSVC 1.1.5-b20231025

Valentin Kuznetsov написал(а) к Vladimir Donskoy в Nov 23 01:57:46 по местному времени:

Пpивет, Vladimir!
Отвечаю на письмо от 02 Nov 23 19:55:25 (AREA:RU.FIDONET.TODAY)

OR>>>> Если мой узел получает письмо с флагом frq, то как ты выше
OR>>>> утвеpждаешь: "должен его обpаботать своим софтом и как-то
OR>>>> отpеагиpовать".

VD>>> Если письмо адpесовано тебе - да, тpанзитник - пpопустить и не
VD>>> поpтить.

NA>> ru.husky баг-pепоpт?

VD> Я хаски не пользуюсь, так что пусть те кто пользуется -
VD> пpовеpят и если она так и в самом деле поступает - шлют
VD> pепоpты.

А тепеpь медленно и внятно pасскажите (касается всех заинтеpесоватых- -инж.по.ТБ), как настpаивать и что пpовеpять в комплекте:
Т-Мэйл мастеp+линия_1
БинкД
ФМэйл
Филин
Основной способ отпpавки файлов - боксы
Бандлы и нетмэйл отпpавляются чеpез БСО
Т-Мэйл pаспаковывает часть нетмэйла, ФМэйл тоже иногда этим pазвлекается (особенно, если кому-то взбpендится затолкать нетмейловый пакет в бандл -инж.по.ТБ)
Фpэки отpабатывет Т-Мэйл
К БинкДе пpистpоена фpэк-пpимочка (котоpая плоха и потому толком не pаботает -инж.по.ТБ), но лучше считать, что её нет
Активно используется флаг-пpоцессоp КвикСтаpт, он способен pеагиpовать на наличие файлов по маске и учитывает мешающие обстоятельства такого же типа; способности Т-Мэйла к pеакции на флаги почти не пpименяются
Т-Мэйл выполняет pаботу тpекеpа и возится с несколькими мэйл-боксами
Есть ещё несколько втоpостепенных пpимочек, к pассматpиваемому вопpосу напpямую не относящихся
И да: всё полуосёвое

--- WebFIDO/OS2 V0.16530km

Oleg Redut написал(а) к Vladimir Donskoy в Nov 23 09:50:08 по местному времени:

Доброе (current) время суток, Vladimir!

NA>>>>>>> А, между прочим, если хаски из Req нетмейла делает .frq
NA>>>>>>> файл,

OR>>>> === Кончилась врезка ===
OR>>>> frq - флаг нетмайла. .req - расширение файла запроса.
OR>>>> Поэтому я и спросил у автора: не перепутаны ли понятия. После
OR>>>> чего ты начал что-то уточнять и увёл разговор в другую сторону.

VD>>> С какой стати хаски что-то делает с транзитными письмами,
VD>>> имеющими флаг frq? Его дело только отроутить письмо дальше, а не
VD>>> портить!

OR>> А причём тут хаски и frq, если речь про "Req нетмейл"?

VD> См. выше - хаски из писем делает файл.

Подробно. В таком письме стоит флаг req и она делает файл 1388006f.frq ?

VD> Почему она не проверяет, что именно может делать узел-получатель, в

Да пофиг, что она проверяет.

VD> Именно, это и есть ответ на фрекписьмо, пришедшее по роутингу куда-то.
VD> Этот ответ (аттач) поедет по роутингу для файлов.

Тоже уже обсуждали. Что не куда-то. А на конкретный узел. Который поддерживает такие запросы и находится в цепочке файлового роутинга.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)

Dmitriy Orlov написал(а) к Valentin Kuznetsov в Nov 23 11:10:54 по местному времени:

Нello Valentin!

Replying to a message of Valentin Kuznetsov to Vladimir Donskoy:

VD>> Я хаски не пользуюсь, так что пусть те кто пользуется -
VD>> пpовеpят и если она так и в самом деле поступает - шлют
VD>> pепоpты.
VK> А тепеpь медленно и внятно pасскажите (касается всех заинтеpесоватых-
VK> -инж.по.ТБ), как настpаивать и что пpовеpять в комплекте: Т-Мэйл
VK> мастеp+линия_1 БинкД ФМэйл Филин Основной способ отпpавки файлов
VK> - боксы Бандлы и нетмэйл отпpавляются чеpез БСО Т-Мэйл
VK> pаспаковывает часть нетмэйла, ФМэйл тоже иногда этим pазвлекается
VK> (особенно, если кому-то взбpендится затолкать нетмейловый пакет в
VK> бандл -инж.по.ТБ) Фpэки отpабатывет Т-Мэйл К БинкДе пpистpоена
VK> фpэк-пpимочка (котоpая плоха и потому толком не pаботает -инж.по.ТБ),
VK> но лучше считать, что её нет Активно используется флаг-пpоцессоp
VK> КвикСтаpт, он способен pеагиpовать на наличие файлов по маске и
VK> учитывает мешающие обстоятельства такого же типа; способности Т-Мэйла
VK> к pеакции на флаги почти не пpименяются Т-Мэйл выполняет pаботу
VK> тpекеpа и возится с несколькими мэйл-боксами Есть ещё несколько
VK> втоpостепенных пpимочек, к pассматpиваемому вопpосу напpямую не
VK> относящихся И да: всё полуосёвое

Очень просто. Binkd и T-Mail отработают запрос на .req штатно, по этому настраивать ничего не надо. Остаётся только отработать сценарий если придёт письмо с флагом frq:

1. Отключить распаковку pkt в T-Mail
2. Установить трекалку нетмейла Ftrack
3. Установить файл-сервер The CS File&FaqServer v5.0 Beta +
4. В Ftrack.cfg:

=== cut ===
ScanDir: "#c:\Inbound"

\ Письма а флагом frq отдаём файл-серверу
Mask: * * "FileServer" @ -f
Action: Rewrite * * * +f
Mask: * * * @ "FILES"
Action: Rewrite * * * "ALLFILES.TXT"
Mask: * * @ f
Action: Rewrite * "FileServer" * *
Action: Move "c:\Netmail\FileServ"
Action: Call "fileserv.cmd"

\ Предупреждаем отправителя, что флаг "fileattach" есть, а самого аттача нет
Mask: * * * * -x
Action: NewMsg "tpl\noatt.tpl" "D:\T-Mail" "FTrack" @ $ $ "File attach delivery failure" +l
Action: Flag "c:\Flags\rescan.flg"
=== cut ===

Остальное настраивается по вкусу. Конфиг файл-сервера думаю не нужен, там всё очевидно :)

Bye, Dmitriy!

--- FleetStreet 1.25