Subj : Re: Path... To : mark lewis From : Bill McGarrity Date : Tue Nov 07 2017 07:36:56 -=> On 01-08-15 05:29, mark lewis wrote to Bill McGarrity <=- Hiya mark... ml> On Wed, 07 Jan 2015, Bill McGarrity wrote to mark lewis: BM> OK, I toggled another switch to see if it will add my node to the BM> Path... let me know please... BM> BM> @PATH: 266/404 261/38 712/848 280/464 203/0 320/119 123/500 3634/12 ml> you mean like that? damn that went the long way around to get here... BM> Yes... I toggled zone blind and now it's there. I know you're on BM> the FTSC so does it need to be there? ml> the original FTS-0004 (which was cribbed from the confmail docs) says ml> this... ml> [quote] ml> 5. PATH Lines ml> These are the last lines in a Conference Mail message and ml> are a new addition, and therefore is not supported by all ml> Echomail processors. It appears as follows: ml> ^aPATH: 132/101 1014/1 ml> Where the ^a stands for Control-A (ASCII character 1) and ml> the net/nodes listed correspond to those systems having ml> processed the message before it reached the current system. ml> This is not the same as the seen-by lines, because those ml> lines list all systems the message has been sent to, while ml> the path line contains all systems having actually processed ml> the message. This is not a required field, and few echomail ml> processors currently support it, however it can be used ml> safely with any other system, since the line(s) will be ml> ignored. For a discussion on how the path line can be ml> helpful, see the "Advanced Features" section of this manual. ml> [/quote] OK... so it's an option... as of now.. :) ml> there is no "Advanced Features" section but at the end of the document ml> there is also this section... ml> [quote] ml> Why a PATH line? ml> As was previously mentioned, the PATH line is a new concept in ml> Echomail. It stores the net/node numbers of each system having ml> actually processed a message. This information is useful in ml> correcting the biggest problem encountered by nodes running an ml> Echomail compatible system - the problem of finding the cause of ml> duplicate messages. How does the PATH line help solve this ml> problem? Take the following path line as an example: ml> ^aPATH: 107/6 107/312 132/101 ml> This shows the message was processed by system 107/6 and ml> transferred to system 107/312. It further shows system 107/312 ml> transferred the message to 132/101, and 132/101 processed it ml> again. Now take the following path line as the example: ml> ^aPATH: 107/6 107/312 107/528 107/312 132/101 ml> This shows the message having been processed by node 107/312 on ml> more than one occasion. Based upon the earlier description of the ml> 'information control' fields in Echomail messages, this clearly ml> is an error in processing (see the section entitled "How it ml> Works"). This further shows node 107/528 as the node which ml> apparently processed the message incorrectly. In this case the ml> path line can be used to quickly locate the source of duplicate ml> messages. ml> In a conference with many participants it becomes almost ml> impossible to determine the exact topology used. In these cases ml> the use of the path line can help a coordinator of the conference ml> track any possible breakdowns in the overall topology, while not ml> substantially increasing the amount of information transmitted. ml> Having this small amount of information added to the end of each ml> message pays for itself very quickly when it can be used to help ml> detect a topology problem causing duplicate messages to be ml> transmitted to each system. ml> [/quote] ml> so it comes down to "what is the definition of 'systems having ml> processed the message'?"... does the originating system count as having ml> processed the message or not? it only scanned out and prepped it for ml> disposal^Wdistribution before puking^Wsending it to all the systems ml> connected to it... More doubletalk so to speak. lol!! ml> honestly, this is one of those like the seenbys and an originating ml> system adding themselves to the seenby or not... some do and some ml> don't... the originating system should be able to be determined by the ml> origin line address... if it appears in the seenbys and path, ok... ml> otherwise, we still know where it originated... ml> at least, that's the way it is supposed to work but folks didn't think ml> about regurges and situations where that information is removed for ml> some reason... OK.. as of now the ZONE_BLIND 4 option is in. I can monitor it and see if there is an issue later on down the road... :) Thanks Bill Telnet: tequilamockingbirdonline.net Web: bbs.tequilamockingbirdonline.net FTP: ftp.tequilamockingbirdonline.net:2121 IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697 Radio: radio.tequilamockingbirdonline.net:8010/live .... Look Twice... Save a Life!!! Motorcycles are Everywhere!! --- MultiMail/Win32 v0.50 * Origin: TequilaMockingbird Online - Toms River, NJ (1:266/404) .