Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции ENET.SYSOP
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции ENET.SYSOP с датами от 10 Jul 13 21:42:12 до 03 May 24 12:02:39, всего сообщений: 12492
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9224 из 12492 ====================================== ENET.SYSOP =
От   : Michael Dukelsky                 2:5020/1042        03 Jan 20 20:32:42
Кому : Kees van Eeten                                      03 Jan 20 20:32:42
Тема : 2020
FGHI : area://ENET.SYSOP?msgid=2:5020/1042+5e0f7abd
На   : area://ENET.SYSOP?msgid=2:280/5003.4+5e0f7387
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://ENET.SYSOP?msgid=2:335/364.3+30c32ac0
==============================================================================
Hello Kees,

Friday January 03 2020, Kees van Eeten wrote to Michael Dukelsky:

MD>> I handle the loop messages differently. If a message comes to me
MD>> not for the first time, it is moved to the special area. Once a
MD>> day messages are released from the area. This is done in a hope
MD>> that the routing may be fixed during this delay. After the
MD>> message comes for the 7th time, it is clear that the routing has
MD>> not been fixed during the week and the message is bounced back to
MD>> the sender (if he is in the nodelist). And the last but not the
MD>> least: when the message comes for the second time and a loop is
MD>> detected, I receive a message from my robot about it. So I can
MD>> take some actions to help with fixing the routing.

KE> I do not know how my tosser handles loops,

This is the key phrase. Your tosser does not handle loops, it will do nothing if you do not develop a Perl script for it. All that I described above is a configuration in RNtrack.

KE> but in this case it was not
KE> routing failure. Du to some unfortunate handling the messages
KE> contained twoo INTL kludge lines. The first twoo systems in the loop
KE> processed the first line, causing the message to be delivered to the
KE> intended system. There and at the following system the second INTL
KE> line was processed, causing the message to be returned to the sender.

If you received a message that some mail came to your node a second time, you could investigate the problem and would not have to wait until the same mail came 15 times.

KE> Nobody cared to make his software safe, to messages structures, that
KE> should not exist.

That's true.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.070127 секунды