01 Jan 20 14:10, you wrote to Michiel van der Vlist:
Mv>> WD>> but I will be away Mv>> TK> And guess what... :D Mv>> Henk Wevers strikes again. ...
WD> Not that I know of,
Nornally the Nodelist are delivered between 00:00 and 01:00 MET. The files were available by HTTP. Delivery started at 20:28
Between 01:00 and 20:28 people were guessing what could be the cause of the delay, during the period before 20:28
Conclusions may have been unjustified, but there was a diversion from the normal and you had announced to be away from your system.
WD> but now that we're at it here are some Via-lines for WD> netmail destined to 2:280/2000 which has been bouncing and was taken WD> out WD> of circulation ...
WD> Via D'Bridge 3.99 2:292/854 12/31 21:56 WD> Via 2:280/5003.0 @20191231.210401.UTC FIDOGATE/ftntoss 4.4.14 WD> Via 2:280/2000 @20191231.210349.UTC SBBSecho 3.07-Win32 r3.114 WD> Via 2:280/5555 @20191231.210418.562.UTC FMail-W32(Toss) WD> 2.1.3.7-B20170919 WD> Via 2:280/5555 @20191231.210418.608.UTC FMail-W32(Pack) WD> 2.1.3.7-B20170919 WD> Via D'Bridge 3.99 2:292/854 12/31 22:06
WD> So ...
WD> 1) My system correctly routes the 2:280-destined netmail to the nethost WD> 2) The nethost instead of delivering it, erroneously sends it to the RC
I do not agree with this assumption, the nethost delivered the message to 2:280/2000. 2:280/2000 has bounced the message to the RC. It is not clear clear to me why it was bounced by SBBSecho and how it was mangled to cause FMAIL to forward the message back to 2:292/854.
The via lines above show that the messages passed 2:280/5003 at 22:04 local time. That was the fifth time, the message passed. It may have shown in the message, where the extract is from, but from the above example it looks like Via lines are stripped somewhere in the loop. With Via lines being stripped, tossers cannot detect message loops.
Not at 2:292/854, not at 2:280/5003 and not at 2:280/5555 None of the sysops of these three nodes, have knowledge of the software used at 2:290/2000.
In total the messages passed 2:280/5003 15 times, before it was quenched.
WD> 3) The RC28 instead of bouncing it back to the nethost, or delivering WD> it, WD> sends it back to "me"
WD> How difficult can it be to route netmail?
WD> Answer: Not very.
There may be more to it, than meets the eye, but the cause and solution must likely be found at 2:280/2000
According to my logs, it concerns a message from you to the sysop of 2:280/2000 If you are in a hurry, you could try direct mail.
Kees
--- GoldED+/LNX 1.1.5--b20180707 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
