The  Message-ID  header contains the article's message ID, a
          unique identifier  distinguishing  the  article  from  every
          other article:

               Message-ID-content  = message-id
               message-id          = "<" local-part "@" domain ">"

          As  with  From addresses, a message ID's local part is case-
          sensitive and its domain is case-insensitive.  The  "<"  and
          ">"  are  parts  of the message ID, not peculiarities of the
          Message-ID header.

               NOTE: News message IDs are a restricted subset  of
               MAIL message IDs.  In particular, no existing news
               software copes properly with MAIL quoting  conven-
               tions  within  the local part, so they are forbid-
               den.  This is unfortunate, particularly for  X.400
               gateways  that  often  wish  to include characters
               which are not legal in unquoted message  IDs,  but
               it  is  impossible to fix net-wide.  See the notes
               on gatewaying in section 10.

          The domain in the message ID SHOULD  be  the  full  Internet
          domain name of the posting agent's host.  Use of the ".uucp"
          pseudo-domain (for hosts registered in the UUCP maps) or the
          ".bitnet"  pseudo-domain  (for Bitnet hosts) is permissible,
          but SHOULD be avoided.

          Posters and posting agents MUST generate the local part of a
          message ID using an algorithm which obeys the specified syn-
          tax (words separated by ".",  with  certain  characters  not
          permitted)  (see  section  5.2  for  details),  and will not
          repeat itself (ever).  The  algorithm  SHOULD  not  generate
          message  IDs which differ only in case of letters.  Note the
          specification in section 6.5 of a recommended convention for
          indicating  subject  changes.  Otherwise the algorithm is up
          to the implementor.

               NOTE: The crucial use of message IDs is to distin-
               guish  circulating  articles  from  each other and
               from articles circulated recently.  They are  also
               potentially  useful  as  permanent  indexing keys,
               hence the requirement for permanent  uniqueness...
               but   indexers  cannot  absolutely  rely  on  this
               because the earlier RFCs  urged  it  but  did  not
               demand  it.  All major implementations have always
               generated  permanently-unique   message   IDs   by
               design,  but  in  some  cases this is sensitive to
               proper administration,  and  duplicates  may  have
               occurred by accident.

               NOTE:  The most popular method of generating local
               parts is to use the date and time, plus  some  way
               of distinguishing between simultaneous postings on
               the same host (e.g. a process number), and  encode
               them  in a suitably-restricted alphabet.  An older
               but now  less-popular  alternative  is  to  use  a
               sequence  number,  incremented  each time the host
               generates a new message ID; this is workable,  but
               requires  careful  design  to  cope  properly with
               simultaneous  posting  attempts,  and  is  not  as
               robust  in  the presence of crashes and other mal-
               functions.

               NOTE: Some buggy news software  considers  message
               IDs  completely case-insensitive, hence the advice
               to  avoid  relying  on  case  distinctions.    The
               restrictions  placed  on  the  "alphabet" of local
               parts and domains in section 5.2 have  the  useful
               side effect of making it unnecessary to parse mes-
               sage IDs in complex ways to break them into  case-
               sensitive and case-insensitive portions.

          The  local  part of a message ID MUST not be "postmaster" or
          any other string that would compare equal to "postmaster" in
          a  case-insensitive  comparison.   Message  IDs  MUST  be no
          longer than 250 octets, including the "<" and ">".

               NOTE: "Postmaster"  is  an  irksome  exception  to
               case-sensitivity  in  local  parts, inherited from
               MAIL, and simply avoiding it is the  best  way  to
               deal  with it (not that it's likely, but the issue
               needs to be dealt  with).   The  length  limit  is
               undesirable,  but is present in widely-used exist-
               ing software.  The limit is actually  255,  but  a
               small safety margin is wise.