@MSGID: 3625.fido_ftscpubl@1:135/115 2c2da409
@REPLY: 2:292/854 12123414
@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
-=> Ward Dossche wrote to Alan Ianson <=-

 AI> My and I suppose most NC`s segments are done by hand but processing it
 AI> with makenl includes the CRC and that`s a plus. It`s a requirement I
 AI> think.

 WD> When a segment arrives and it has a CRC, the CRC is checked. If it
 WD> checks-out, fine. If it doesn`t, my system will compute it and replace.

So it sounds like the CRC has no meaning.  If your system is
re-computing the CRC, then the segment could be invalid because of
in-transit corruption (or any other reason).  If I`m wrong about that,  
please explain more about it.

 WD> @ALL ... please don`t tell me that it`s wrong, you have no idea the
 WD> amount of crap that sometimes is delivered and needs to be re-processed
 WD> although times have improved.

This sounds like RCs not doing their job properly.  Why are they not 
being held accountable to do it correctly?

 WD> If a segment arrives without CRC, idem ditto.

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

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

Thanks for any info you can provide!



... Users come in two types: Those who have lost data, and those who will.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
 * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
SEEN-BY: 1/120 18/0 30/0 50/109 104/117 123/0 25
180 755 3001 3002 135/0 115
SEEN-BY: 135/205 220 240 363 366 382 385 388 390
391 153/7715 154/10 220/6
SEEN-BY: 221/1 6 222/2 229/426 240/12 1120 1512
1634 8001 8002 8005 8050
SEEN-BY: 250/1 275/1000 280/464 5003 291/111
292/854 301/1 113 303/0 313/41
SEEN-BY: 320/219 335/364 341/66 371/0 460/58
530/204 712/1321 2320/105 3634/0
SEEN-BY: 3634/12 24 27 56 57 58 60 119 5020/846
848 1042 4441 12000 5030/49
SEEN-BY: 5030/1081 1474 5053/51 5061/133 5075/128
5083/1 444
@PATH: 135/115 3634/12 240/1120 301/1 5020/1042
4441