@MSGID: 3628.fido_ftscpubl@1:135/115 2c2eefb0
@REPLY: 1:320/219@fidonet 67c9336b
@TZUTC: -0600
@PID: Synchronet 3.20c-Linux master/1f5447a39 Feb 21
2025 GCC 14.2.0
@TID: SBBSecho 3.23-Linux master/1f5447a39 Feb 21
2025 GCC 14.2.0
@BBSID: PALANTIR
@CHRS: CP437 2
-=> Andrew Leary wrote to Dan Clough <=-

 DC> So this is the crux of my (original) question.  If it arrives without
 DC> a CRC, then one can assume that MakeNL was not used to produce the
 DC>  segment.  To repeat my original question, is MakeNL really needed?  A
 DC>  segment is just a text file that gets "processed" by MakeNL, and it
 DC>  sounds like all that MakeNL is actually doing is calculating a CRC.
 DC> Is that serving any valid purpose, especially now that we know the
 DC> validity of the CRC is ignored anyway?

 AL> MakeNL does more than just compute a CRC for the segment file.  It does
 AL> some basic error checking of segments, to include insuring there are no
 AL> duplicate node numbers in the segment, checking that any phone numbers
 AL> have the correct number of parts, making sure that there are no invalid
 AL> keywords, etc.

Okay, yes.

 DC> In other words, can`t the *C`s just edit their segments with their
 DC> text editor of choice, and then get it to the upstream *C via whatever
 DC> method they like (netmail or email)?  What role does MakeNL perform in
 DC> this process that actually matters?

 AL> MakeNL was designed to automate the submission process.  If you email
 AL> or netmail the segment, the upstream coordinator most likely has to
 AL> manually save it on their system in the proper place for MakeNL to find
 AL> and process it. Sending it as a file attach to your coordinator is the
 AL> best way to allow it to be processed automatically.   In fact, MakeNL`s
 AL> SUBmit directive in the .CTL file automates the creation of a file
 AL> attach netmail to get the file where it needs to go.

Understood, and that is all very useful.  I use it that way myself 
(automated file attach / netmail to RC).  

I guess what got me down this path was how Ward is describing that he 
receives garbage segments, and then "fixes" them, which I understand is 
needed and not "wrong".  The value of the CRC function seems to be 
compromised (useless, in fact) in that scenario, and if a *C is going to 
edit a segment (or even a whole nodelist) as they see fit, what`s the 
point of the CRC or even MakeNL?  Seems like it would be more correct 
for upstream *Cs to hold the segment submitter accountable for doing it 
correctly, and fire them if they`re unable or unwilling to do so.

 AL> It is certainly possible to edit a segment in a text editor, save it as
 AL> an ASCII text file, and manually send it to your upstream coordinator
 AL> by creating a file attach or copying it into a filebox directory, as
 AL> appropriate for the mailer you are using.  In this case, you would lose
 AL> the benefits of MakeNL error-checking your segment prior to submission.
 AL>  Potentially this could cause your updates to be delayed if there is a
 AL> typo or other error in your submission.

Agreed.  Thanks for your explanation and information.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
 * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
SEEN-BY: 1/120 10/0 1 18/0 30/0 50/109 80/1
102/401 103/1 17 705 104/117
SEEN-BY: 105/81 106/201 123/0 25 180 755 3001
3002 124/5016 128/187 135/0 115
SEEN-BY: 135/205 220 240 363 366 382 385 388 390
391 153/7715 154/10 110
SEEN-BY: 214/22 218/0 1 215 601 700 720 840 850
860 880 900 910 220/6 221/1 6
SEEN-BY: 222/2 226/30 227/114 229/110 114 200 206
300 317 400 426 428 470 664
SEEN-BY: 229/700 705 240/1120 250/1 266/512
275/1000 280/464 291/111 292/854
SEEN-BY: 301/1 113 320/219 322/757 335/364 341/66
342/200 396/45 460/58
SEEN-BY: 633/280 712/848 1321 902/26 2320/105
3634/0 12 24 27 56 57 58 60 119
SEEN-BY: 5020/846 848 1042 4441 12000 5030/49 1081
1474 5053/51 5061/133
SEEN-BY: 5075/128 5083/1 444
@PATH: 135/115 3634/12 229/426 218/700 301/1
5020/1042 4441