MSGID: 1:396/45.0 fc9265e0   
   REPLY: 1:132/174 5fc8a5f2   
   CHRS: IBMPC 2   
   Hello Fred.   
      
      
      
   [snip]   
    ML> To answer your questions about the storage format for NetMail, it is    
    ML> in .MSG format - that's the one and only area that doesn't store in    
    ML> Squish format.   
      
    FR> I run the same way here because I like to use the old   
    FR> tried-and-true utilities like AreaFix and Tick that were written   
    FR> way before the squish database existed.    
      
      
    ML> I REALLY don't think that Squish is at fault.    
      
    FR> I think Squish is partially at fault.  When messages tossed to   
    FR> *.Msg files, it leaves trash at offset B0 and B2 where the orig &   
    FR> dest zone should be.  Same with ofs B4 & B6 where the point number   
    FR> should be.   
      
    FR> This happens if there is a "proper", MsgId, a Sync-style ID, or no   
    FR> ID at all.    
      
      
    ML> I am at a complete loss as to what to do.    
      
    FR> If you think it would help, I could write you a fixer-upper routine   
    FR> that removes the "xxxxxxx@" part of the msgid from the packed   
    FR> messages, but it will take some batch file magic to wedge it in   
    FR> between the packets being unpacked and Squish tossing them.  Are   
    FR> you up for it?   
      
   I'm up for that; batch language is my *only* strong point. My MAILTOSS.BAT is   
   a LONG fairly complicated batch, and I can fairly easily insert something   
   before the point where Squish comes into play. (BTW, I even temporarily   
   altered the MAILTOSS.BAT to call Squish in DOS mode rather than calling it in   
   OS/2 mode, and it made zero difference.   
      
   In keeping with what Rob Swindell has said, I am willing to acquiesce that   
   Squish may be having a problem with the newer @MSGID line format, though it   
   has no problem with the very same line format in EchoMail. So if you can come   
   up with a methodology of extracting the extra characters, I'm up for it.   
   Again, I only wish I had the required knowledge to zoom in on what exactly is   
   going on when Squish trys to toss one of these NetMail messages and gets   
   totally screwed up doing so.   
      
   I was admittedly very hasty in saying I was ready to "hang it up". I am not. I   
   just dread redesigning the toss system to a different tosser inasmuch as   
   getting Squish re-compiled with any corrections for this "fault" are going to   
   be difficult at best since a specific compiler and associated files are   
   apparently few and far between.  I will however post to the appropriate echo   
   about finding someone to tackle this.   
      
    FR> Idea #2...  A program that sorts through your NetMail folder and   
    FR> replaces the trash at those 4 locations with Zone & point info.    
    FR> That would be much easier to add to your system.   
      
   I'm up for that too, but the only problem with that is that NetMgr has already   
   rejected the affected NetMails after Squish has put them in the NetMail   
   directory, as being from a non-FidoNet address. I could possibly alter the   
   NetMgr configurations to not read NetMails any longer, but that would almost   
   completely defeat the reason for running NetMgr.   
      
   Your first idea sounds completely do-able here... at least until a "fix" for   
   Squish can be conjured up.   
      
   Best regards,   
   Marc   
      
   --- timEd/2 1.10.y2k+   
    * Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)   
   SEEN-BY: 1/123 18/200 19/33 90/1 105/81 106/633 987 120/340 123/131   
   SEEN-BY: 124/5014 5016 130/803 203/0 221/0 226/30 227/114 702 229/101   
   SEEN-BY: 229/424 426 550 664 1016 240/5832 249/110 206 317 400 261/38   
   SEEN-BY: 280/464 5003 292/854 8125 317/3 322/757 342/200 387/25 396/45   
   SEEN-BY: 633/280   
   PATH: 396/45 280/464 229/101 426