REPLY: 1:153/7001 5fc8f021   
   MSGID: 2:240/77 5fc9150d   
   CHRS: LATIN-1 2   
   TID: hpt/lnx 1.4.0-sta 09-04-05   
   Hello Maurice!   
      
   03 Dec 20, Maurice Kinal wrote to Kai Richter:   
      
    KR>> FTN dupe handling is based on "per area". There is no universial   
    KR>> dupecheck.   
      
    MK> So far I agree with the above 100% given that both my uplinks tossed   
    MK> both msgs without any issues.  I see them on the EuroPoint as   
    MK> unaltered, not counting PATH and SEEN_BY of course, from what I know   
    MK> to be a fact is the original msg given that I created it.  They are   
    MK> all identical other than the AREA.   
      
    KR>> For example every squish messagebase *.sqd file has it's own   
    KR>> *.dqd dupedatabase file.   
      
    MK> I've used squish for ages but it is overkill from a single user   
    MK> perspective.   
      
   I wasn't talking about the software squish. Any squish messagebase compatible   
   tosser should be able to use the *.sq? and *.dqd files.   
      
    MK> --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)   
      
   Maybe i didn't noticed the background of your question. If that is the editor   
   that creates the complete message and you are looking for confirmation that it   
   does everything correct, then i could tell that golded does not create the   
   same MSGIDs for the crossposted message:   
      
    5fc90f4d   
    5fc90f4c   
      
   The crossposting does have +1. Which is the "failsafe" behavior for   
   msgid-based dupecheck procedures.   
      
   Regards   
      
   Kai   
      
   --- GoldED+/LNX 1.1.4.7   
    * Origin:  Monobox  (2:240/77)   
   SEEN-BY: 1/123 90/1 105/81 120/340 123/131 226/30 227/114 702 229/101   
   SEEN-BY: 229/424 426 452 550 616 664 1016 240/77 5138 5411 5824 5832   
   SEEN-BY: 240/5853 249/206 317 400 280/464 292/854 310/31 317/3 320/219   
   SEEN-BY: 322/757 342/200 633/280 2432/390 2452/250 2454/119   
   PATH: 240/77 5832 229/426