31 окт 23 11:03, Oleg Redut wrote to Vladimir Donskoy:
VD>> Тут рассматривается ситуация транзитного узла, на которое паришло VD>> письмо с фреком.
OR> Если отмотать тред, то там имеется такая фраза.
OR> === Вырезка из филе Windows Clipboard ===
NA>>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,
OR> === Кончилась врезка === OR> frq - флаг нетмайла. .req - расширение файла запроса. OR> Поэтому я и спросил у автора: не перепутаны ли понятия. После чего ты OR> начал что-то уточнять и увёл разговор в другую сторону.
С какой стати хаски что-то делает с транзитными письмами, имеющими флаг frq? Его дело только отроутить письмо дальше, а не портить!
VD>> Ситуации узла, создавшего фрекписьмо - не VD>> рассматриваем, это дело его софта. А узел, получивший фрекписьмо VD>> - должен его обработать своим софтом и как-то отреагировать, VD>> файлом и письмом-квитком.
OR> И фрекписьмом является нетмайл с флагом frq.
Да
OR>>>>> Логично. Но можно послать квиток.
VD>>>> Если квиток запрошен соответствующим флагом в письме, иначе это VD>>>> спам...
OR> Если мой узел получает письмо с флагом frq, то как ты выше OR> утверждаешь: "должен его обработать своим софтом и как-то OR> отреагировать".
Если письмо адресовано тебе - да, транзитник - пропустить и не портить.
OR>>> С чего бы спам? Так любое письмо от ареафикса может OR>>> считаться спамом.
OR> "письмом-квитком" - если такого файла нет или вообще узел ничего OR> пр отранзиные фреки не знает.
Да.
VD>> Повторюсь, рассматриваем транзитный узел! И делать квитки о VD>> прохождении транзитного письмо можно толькео если они запрошены VD>> этим письмом (соответствующим флагом), иначе:
OR>>> Спам - это массовая рассылка.
VD>> Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное VD>> письмо является спамом.
OR> Тогда и письмо от сисопа, который лично, а не скриптом сообщит, OR> что письмо завёрнуто/необработано, тоже будет незапрошенным. OR> И вполне возможно предположение транзитнго узла, что если он OR> пропустит письмо с фреком, то ему в ответ свалится аттач для транзита. OR> :-\
Повторюсь: письмо от получателя фрекписьма - да, требует реакции. Транзитное письмо - не требует.
Если сисоп при установлении линка указал что по нему могут ходить файлы - он будет получать файлы, в том числе для транзита. Если линк только для писем - результат (аттач) пойдёт иным путём. Смотри например рнтрак или иные трекеры нетмайла, понимающие такую разницу в описаниях линков.
VD>>>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая VD>>>> система не поддерживает роутинг фреков, нечего к ней VD>>>> обращаться.
OR> Ещё раз хочется определится с понятиями. Что такое роутинг фреков. OR> Каков стандарт последовательности действий узлов задействованных в OR> нём. OR> Для меня фрек - это запрос. Аттач - отправка. После прихода фрека OR> - уже дело получателя, как ему аттачить файл. И аттачить ли вообще.
Если у получателя фрекписьма нет линка с отправителем, то холд становится бессмысленным: может не быть общих протоколов или времени работы! Потому запрос и шёл по роутингу...
OR>>> Давай разделим эти понятия:
OR>>>>> Аттач - это активное действие по отправке файла. OR>>>>> Обработка фрека - пассивное: выкладывание запрощенного файла OR>>>>> на отправку и создание какой-либо лошки, согласно политики OR>>>>> ноды. Создание и отправка аттача по роутингу - это уже не OR>>>>> относится к процедуре фрека. Это уже отдельный наворот OR>>>>> объединяющий два понятия. Это как бы просто нетмайлом OR>>>>> написали, отправь мне, плиз, такой-то файл. И ему заттачили бы OR>>>>> по роутингу. Просто можно, конечно, это автоматизировать. Но OR>>>>> это не будут фрек и аттач в чистом виде этих понятий.
VD>>>> Так эта самая автоматизация и есть "поддержка фреканья по VD>>>> роутингу"! И у узла, не понимающего такого - фрекать по VD>>>> роутингу не получится, максимум обычный фрек выйдет.
OR> Почему же? Получатель фрека по роутингу может зааттачить файл с OR> директным креш-полом на отправителя.
Ага, Матюку на телефон с ИП-ноды... Или на узел без СМ-времени работы. Да мало ли причин было у того, кто слал письмо по роутингу!
OR>>> Фрек по роутингу: передача фрек-запроса транзитом до OR>>> конечного узла.
VD>> И получение некоего ответа, не требующего директной связи с VD>> узлом-хранителем файла. Всякие холды - в отказ: не поддерживается VD>> "фрек-роутинг".
OR> Предположительно "получение некоего ответа". Ибо не холд - это уже OR> отдельная сущность: аттач по роутингу.
Да, это "роутинг файлов", давным-давно известный в ФИДО и постоянно применяемый для передачи нод- и поинт-сегментов, например.
С уважением, Vladimir Donskoy.
--- GoldED+/W64-MSVC 1.1.5-b20231025 * Origin: DVB Station (2:5020/2992)
