home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / fido / ftsc_all.z43 / FSC-0031.TXT < prev    next >
Text File  |  1989-05-18  |  3KB  |  75 lines
  1. FSC-0031                                            May 1, 1989
  2.  
  3.  
  4.           EchoMail ^aEID: Dup-Checking with Linked Replies
  5.       A Proposal To The FidoNet Technical Standards Committee
  6.  
  7.  
  8.  
  9. Currently, no universal methodology for implementing echomail
  10. duplicate message checking exists.  One thing is certain - they
  11. will only increase in number as the shear volume of echomail is
  12. increasing every day!
  13.  
  14. In order to catch the highest percentage of duplicates possible
  15. it is desirable to utilize a system which actually tags each of
  16. the messages themselves with a distinct messages identifier to
  17. be used to check against an existing database of all previous
  18. messages' identifiers.  In practice, this is not possible, but
  19. we can limit the number of previous identifiers kept so that
  20. processing is quick but still almost certain to eliminate any
  21. duplicate messages.
  22.  
  23.  
  24. This also provides an easy method of linking replies to their
  25. original message by appending the previous identifier.  Using
  26. a linked reply technique allows easy relinking of the messages
  27. to the original message, assuming it still exists.
  28.  
  29.  
  30. This proposed ^aEID: kludge line specifications are as follows:
  31.  
  32. 1)  A 16-bit CRC followed by a 32-bit DOS file date/time stamp.
  33.  
  34. 2)  The 16-bit CRC is calculated by first CRC'ing all but the
  35.     first 11 (static) characters of the origin line, followed
  36.     by the first two "words" of the from name, the first two
  37.     words of the to name, and the first 25 characters of the
  38.     subject line after stripping leading occurances of "Re: "
  39.     sequences.
  40.  
  41.  
  42. Notes:  You must always upper-case the to/from/subject fields,
  43.   as some current processors will change the case of that text.
  44.   Using only the first two words of the from and to names will
  45.   eliminate the potential problem when some processors add the
  46.   " of xxx/yyy" to the end.  Stripping all leading occurances
  47.   of the "Re: " in the subject field is also done to eliminate
  48.   the possibility of changed subject lines not matching with
  49.   the original message, which is also the reason for limiting
  50.   the length of that field to the first 25 bytes (after taking
  51.   off all the "Re: " sequences), because adding the leading
  52.   "Re: " may force characters out (because they are beyond the
  53.   72-character field limit).
  54.  
  55.  
  56. When you must add an EID line for a message which is not local,
  57. you have to zero the seconds field before creating the 32-bit
  58. time stamp - some processors eliminate this information!  This
  59. limitation can be overcome if most editors insert them at the
  60. time they are written.
  61.  
  62.  
  63.  
  64. Automatic reply linking
  65. ========= ===== =======
  66.  
  67. When replying to a message with an ^aEID: line, extend the new
  68. ^aEID: with the ^aEID: fields of the original message.  The new
  69. line would look like this:
  70.  
  71. ^aEID: xxxx yyyyzzzz uuuu vvvvwwww
  72.  
  73. Where 'uuuu vvvvwwww' is the Eid information of the original
  74. message.  Only one previous message's information is retained.
  75.