VD> Тут рассматривается ситуация транзитного узла, на которое паришло VD> письмо с фреком.
Если отмотать тред, то там имеется такая фраза.
=== Вырезка из филе Windows Clipboard ===
NA>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,
=== Кончилась врезка === frq - флаг нетмайла. .req - расширение файла запроса. Поэтому я и спросил у автора: не перепутаны ли понятия. После чего ты начал что-то уточнять и увёл разговор в другую сторону.
VD> Ситуации узла, создавшего фрекписьмо - не VD> рассматриваем, это дело его софта. А узел, получивший фрекписьмо - VD> должен его обработать своим софтом и как-то отреагировать, файлом и VD> письмом-квитком.
И фрекписьмом является нетмайл с флагом frq.
OR>>>> Логично. Но можно послать квиток.
VD>>> Если квиток запрошен соответствующим флагом в письме, иначе это VD>>> спам...
Если мой узел получает письмо с флагом frq, то как ты выше утверждаешь: "должен его обработать своим софтом и как-то отреагировать".
OR>> С чего бы спам? Так любое письмо от ареафикса может считаться OR>> спамом.
"письмом-квитком" - если такого файла нет или вообще узел ничего пр отранзиные фреки не знает.
VD> Повторюсь, рассматриваем транзитный узел! И делать квитки о VD> прохождении транзитного письмо можно толькео если они запрошены этим VD> письмом (соответствующим флагом), иначе:
OR>> Спам - это массовая рассылка.
VD> Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное письмо VD> является спамом.
Тогда и письмо от сисопа, который лично, а не скриптом сообщит, что письмо завёрнуто/необработано, тоже будет незапрошенным. И вполне возможно предположение транзитнго узла, что если он пропустит письмо с фреком, то ему в ответ свалится аттач для транзита. :-\
VD>>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая VD>>> система не поддерживает роутинг фреков, нечего к ней обращаться.
Ещё раз хочется определится с понятиями. Что такое роутинг фреков. Каков стандарт последовательности действий узлов задействованных в нём. Для меня фрек - это запрос. Аттач - отправка. После прихода фрека - уже дело получателя, как ему аттачить файл. И аттачить ли вообще.
OR>> Давай разделим эти понятия:
OR>>>> Аттач - это активное действие по отправке файла. OR>>>> Обработка фрека - пассивное: выкладывание запрощенного файла на OR>>>> отправку и создание какой-либо лошки, согласно политики ноды. OR>>>> Создание и отправка аттача по роутингу - это уже не относится к OR>>>> процедуре фрека. Это уже отдельный наворот объединяющий два OR>>>> понятия. Это как бы просто нетмайлом написали, отправь мне, OR>>>> плиз, такой-то файл. И ему заттачили бы по роутингу. Просто OR>>>> можно, конечно, это автоматизировать. Но это не будут фрек и OR>>>> аттач в чистом виде этих понятий.
VD>>> Так эта самая автоматизация и есть "поддержка фреканья по VD>>> роутингу"! И у узла, не понимающего такого - фрекать по роутингу VD>>> не получится, максимум обычный фрек выйдет.
Почему же? Получатель фрека по роутингу может зааттачить файл с директным креш-полом на отправителя.
OR>> Фрек по роутингу: передача фрек-запроса транзитом до OR>> конечного узла.
VD> И получение некоего ответа, не требующего директной связи с VD> узлом-хранителем файла. Всякие холды - в отказ: не поддерживается VD> "фрек-роутинг".
Предположительно "получение некоего ответа". Ибо не холд - это уже отдельная сущность: аттач по роутингу.
Что я могу еще сказать?.. Oleg
... AKA oleg(&)redut.info AKA https://t.me/OVRnsk --- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает) * Origin: --- ...И все на наш редут... --- (2:5000/111)
