> Like I said in a previous message, this problem doesn't exist at this
 > particular node but I am aware of at least one tosser, actually more of a
 > gateway but does toss, where this is a problem and badly formed MSGID's will
 > not make it beyond the bit bucket, or so I've been told.  If that is true th
 > only one well situated hub using this tosser will result in messages being
 > filtered out of the mix.  If none of us, or even a few of us, never see thes
 > messages then how would one know?
 >
 > I see no reason for the extra fields in the pointed out MSGID.  Do you?


Here is the answer I go back from Rob Swindell, the author of
Synchronet

By: Joe Delahaye to Rob Swindell on Tue May 04 2004 05:04 pm

 > Somebody told me that the MSGID had a problem.  Here is what I was
 > told.  Notice the duplication of the ID.
 >
 >  >  >> {at}MSGID: 1:249/303 04fcd615 486.fidohusk 04FCD615
 >  >
 >  >  JD> So what is the proper way, and why is it a 'major' bug?
 >  >
 >  > I forget which FTSC doc covers this but the above is fine up to,
 >  > {at}MSGID: 1:249/303 04fcd615.  What can happen to tossers that
follow
 >  > the specs to the letter and use MSGID to scan for dupes is that
 >  > the extra characters will cause them to be tossed to a bad file
 >  > if it exists.  What is the purpose of duping the id in caps at
the
 >  > end?  I've never seen that happen other then in Syncronet
messages

The MSGID is fine and follows the FTS-9 specification as well as later
MSG-ID
definitions. The "serialno" portion is repeated twice to generate
*more* unique
strings for those programs that store the *entire* message-ID (and not
just the
serialno).

                                                  digital man

--- SBBSecho 2.10-Linux