AF>>>>> "Hе директный" - тут лишнее:) CO>>>> Запутали окончательно! :) NA>>> А, между прочим, если хаски из Req нетмейла делает .frq файл, то NA>>> и ответ он должен уметь так же вернуть обратно по-роутингу, а он NA>>> этого делать вряд ли умеет. Спрашивается, зачем Req нетмейл NA>>> трогал. CO>> Вдохнул... Выдохнул...
OR> Ничего не перепутал? Как раз из нетмайла с флагом frq тоссер
Все вы забываете в этом треде один момент: только из нетмайла, созданного на данном узле! И далее по тексту:
OR> создаёт фрек (файл-реквест) АКА .req на адресата, внутри которого OR> будет имя(имена) запрашиваемого файла(ов), которые в редакторе, после OR> установки флага frq, были написали в сабже. А имя файла будет типа OR> 13880100.req. OR> Кроме этого можно поставить флаг imm, чтобы создался файл OR> 13880100.ilo, который должен объяснить мейлеру, что надо "звонить" и OR> отправлять прямо сейчас. Иначе создасться файл-флаг .flo (normal). OR> Далее мейлер, согласно своим настройкам, согласно файл-флагов и OR> указанного в них [директного] адреса будет в нужное время OR> прозваниваться (или не прозваниваться, а ждать входящего) для отправки OR> .req файла.
А если письмо не создано на этом узле/тоссере, то всё вышенаписанное побоку и _чужое_ письмо едет по роутингу! Менять его атрибуты вы не имеете права. И обработка этого письма - дело того узла, которому оно предназначено (с которого фрекают)!
CO>> А ничерта я и не понял.:) OR> И вообще тоссер, если и делает запрос, то почему он же должен OR> уметь возвращать? Хоть по роутингу, хоть директом? Он же передаёт OR> дальнейшее на откуп мейлерам и другой стороне. Обработают с той OR> стороны сделанный запрос, значит придёт файло при очередной сессии с OR> любой из сторон.
Причём файл придёт вместе с письмом, с флагом "атт" и предназначенным тому узлу, который сделал фрек. И опять, если это не тот же узел, работу которого мы рассматриваем, - письмо с файлом идёт далее транзитом.
С уважением, Vladimir Donskoy.
--- GoldED+/W64-MSVC 1.1.5-b20230214 * Origin: DVB Station (2:5020/2992)
