30 окт 23 12:55, Oleg Redut wrote to Vladimir Donskoy:
VD>>>> Все вы забываете в этом треде один момент: только из нетмайла, VD>>>> созданного на данном узле! И далее по тексту:
OR>>> Я не забываю. Я только этот вариант и рассматриваю. :-)
VD>> Согласно сабжу мы роутинг рассматриваем.
OR> Фидошники сабжей не меняют.
Фреки директом тривиальны, не предмет рассмотрения. Тут рассматривается ситуация транзитного узла, на которое паришло письмо с фреком. Ситуации узла, создавшего фрекписьмо - не рассматриваем, это дело его софта. А узел, получивший фрекписьмо - должен его обработать своим софтом и как-то отреагировать, файлом и письмом-квитком.
VD>>>> его атрибуты вы не имеете права. И обработка этого письма - VD>>>> дело того узла, которому оно предназначено (с которого VD>>>> фрекают)!
OR>>> Логично. Но можно послать квиток.
VD>> Если квиток запрошен соответствующим флагом в письме, иначе это VD>> спам...
OR> С чего бы спам? Так любое письмо от ареафикса может считаться OR> спамом.
Повторюсь, рассматриваем транзитный узел! И делать квитки о прохождении транзитного письмо можно толькео если они запрошены этим письмом (соответствующим флагом), иначе:
OR> Спам - это массовая рассылка.
Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное письмо является спамом.
OR> И на извещения флаги не OR> предусмотрены. Любой узел может на любой нетмайл настроить bounce, с OR> извещением, что письмо, скажем, получено, но когда будет прочтено - OR> неизвестно. Или отреагировать извещением на любой другой OR> флаг/сабж/текст.
Только на свои письма, но не на транзитные!
OR>>> А вот это уже далеко не факт. Дистанционно фрекнутые файлы OR>>> узел адресата может тупо положить на холд. И ждать директной OR>>> прозвонки с любой стороны.
VD>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая VD>> система не поддерживает роутинг фреков, нечего к ней обращаться.
OR> Логики не вижу. Если фрек по роутингу дошёл до конечного узла и OR> обраотался, с выкладываеним заказанного на холд - это не значит, что OR> он не поддерживает фреки. Это уже значит, что он не поддерживает OR> аттачи по роутингу. Вместо холда, узел может начать ломиться директом OR> на узел отправивший файловый запрос. :-)
Это будет описано в письме-квитке фрека, либо оно имеет флаг аттача, либо содержит информацию о местонахождении и условиях получения файла (кто сказал что нельзя выложить файл на FTP/иной_сайт и прислать ссылку?).
OR> Давай разделим эти понятия:
OR>>> Аттач - это активное действие по отправке файла. OR>>> Обработка фрека - пассивное: выкладывание запрощенного файла на OR>>> отправку и создание какой-либо лошки, согласно политики ноды. OR>>> Создание и отправка аттача по роутингу - это уже не относится к OR>>> процедуре фрека. Это уже отдельный наворот объединяющий два OR>>> понятия. Это как бы просто нетмайлом написали, отправь мне, OR>>> плиз, такой-то файл. И ему заттачили бы по роутингу. Просто OR>>> можно, конечно, это автоматизировать. Но это не будут фрек и OR>>> аттач в чистом виде этих понятий.
VD>> Так эта самая автоматизация и есть "поддержка фреканья по VD>> роутингу"! И у узла, не понимающего такого - фрекать по роутингу VD>> не получится, максимум обычный фрек выйдет.
OR> Фрек по роутингу: передача фрек-запроса транзитом до конечного OR> узла.
И получение некоего ответа, не требующего директной связи с узлом-хранителем файла. Всякие холды - в отказ: не поддерживается "фрек-роутинг".
С уважением, Vladimir Donskoy.
--- GoldED+/W64-MSVC 1.1.5-b20231025 * Origin: DVB Station (2:5020/2992)
