home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 1077.MID.DOC < prev    next >
Text File  |  1989-01-05  |  5KB  |  150 lines
  1.  
  2.  
  3. There is an "MID" (Message IDentifier) associated with each message.
  4. If an MID is not given explicitly with the "Send" command, one is
  5. created automatically from the message number and callsign of the MailBox
  6. into which the message was initially entered. It has the form nnn_call.
  7.  
  8.  
  9. There are 3 types of messages:
  10.  
  11.  
  12. 1) Personal.    If sent with SP, or with S and to a callsign.
  13.  
  14. 2) NTS traffic. If sent with ST.
  15.  
  16. 3) Bulletins.    If sent with SB, or with S and NOT to a callsign.
  17.  
  18.  
  19. For backward compatibility, any message sent with Sx, where x is NOT
  20. B, P, or T is also considered a bulletin. These types have been
  21. used in the past for bulletin type sorting.
  22.  
  23. Each type of message gets somewhat different handling:
  24.  
  25. For NTS traffic, the LT, KT, and ET commands are active.
  26. For Bulletins, a BID (the MID) is sent when forwarding to MBL systems.
  27. For Personal, the message can only be rad by the sender, addressee, and sysop.
  28.  
  29.  
  30. There are several "flags" associated with each message. These are shown in
  31. the "message status" position in the "list message" display. Note that each
  32. flag has an associated "L" command, and some have associated "K" commands.
  33.  
  34.  
  35.    F - The "Forwarded" flag:
  36.  
  37.        This indicates the message has been forwarded to all
  38.        its destinations, but has not yet been killed.
  39.  
  40.    H - The "Hold" flag:
  41.  
  42.        This indicates the message is held.
  43.        It will not forward, and can only be seen by the sysop.
  44.  
  45.    I - The "In process" flag:
  46.  
  47.        This indicates the message is in the process of being forwarded.
  48.  
  49.    K - The "Killed" flag:
  50.  
  51.        This indicates the message is killed, but has not yet been purged
  52.        from the system. Killed messages are purged with the GM command.
  53.  
  54.    O - The "Old" flag:
  55.  
  56.        This indicates the message has been hanging around
  57.        un-forwarded and un-read for too long.
  58.  
  59.    Y - The "Read" flag:
  60.  
  61.        This indicates the message has been read by its addressee,
  62.        but has not yet been killed.
  63.  
  64.  
  65.  
  66. How do BID's work?
  67.  
  68. The various commands (S, M, CM) work exactly the same.
  69. The basic command is S[type] TO [@ AT] [< FROM] [$[MID]]
  70. Data inside [] may be omitted.
  71.  
  72. Messages differ in the following ways:
  73.  
  74.    TO gets translated.
  75.    TO is a callsign.
  76.    TO is an interest group.
  77.    AT gets translated.
  78.    AT is a callsign.
  79.    AT is a distribution list.
  80.    $ field is present.
  81.    $ field is present, with BID.
  82.    Type is B
  83.    Type is P
  84.    Type is T
  85.    Type was not specified.
  86.    Message is held.
  87.  
  88.  
  89. A type B or P message gets a BID if the command that creates
  90. the message has the "$" field. A message of type B or P gets
  91. a default BID if none was specified and it has a distribution
  92. list. A message of type T never gets a BID. In the discussion
  93. below, the same rules apply whether the message was created
  94. using the S, M, or CM commands.
  95.  
  96.  
  97. Here is how the system behaves:
  98.  
  99.  
  100. 1) If the user sends the message with "$ID" given in the command,
  101.    the message is assigned identifier "ID". If this identifier
  102.    has been seen before, the message is rejected and the text
  103.    "NO - Already have it." is displayed.
  104.  
  105.  
  106. 2) If the user sends the message with "$" given in the command,
  107.    the message is assigned a unique MailBox generated BID. This BID
  108.    is generated from the message number and callsign of the MailBox.
  109.    The message is accepted, since this BID cannot have been seen before.
  110.  
  111.  
  112. 3) If there is a distribution list, and a BID is not given
  113.    with the command, a unique MailBox generated BID is assigned.
  114.    This BID is generated from the message number and callsign
  115.    of the MailBox of origin. If this BID has been seen before,
  116.    the message is put on hold.
  117.  
  118.  
  119. 5) If the user (sysop) attempts to change the BID of a message,
  120.    and the new BID is one that has been seen before, the change is
  121.    rejected, the text "NO - Have it already" is displayed,
  122.    and the message retains its current BID.
  123.  
  124.  
  125. 6) If a message is received from another MailBox, and has a BID
  126.    sent along with it, and has a distribution list that includes
  127.    the MailBox from which the message was received, the message is
  128.    marked as already forwarded to that MailBox.
  129.  
  130.  
  131. Some results of applying these rules:
  132.  
  133.  
  134. 1) A message entered into the system without using "$" in the command
  135.    and without a distribution list may loop within the system.
  136.    There is no rejection mechanism for this type of message.
  137.  
  138.  
  139. 2) A message which was entered with a "$" given in the command
  140.    will be rejected when it is forwarded back to any system it
  141.    previously passed through.
  142.  
  143.  
  144. 3) Messages of type B or P may have a distribution list,
  145.    messages of type T may not.
  146.  
  147. 4) There will be no attempt to pass a message which has a BID
  148.    back to the station that sent it to you.
  149.  
  150.