Wdy Mon DD HH:MM:SS YYYY

    is not acceptable because it is not a valid RFC-822 date.  However,
    since older software still generates this format, news
    implementations are encouraged to accept this format and translate
    it into an acceptable format.

    There is no hope of having a complete list of timezones.  Universal
    Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
    CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
    supported.  It is recommended that times in message headers be
    transmitted in GMT and displayed in the local time zone.

2.1.3.  Newsgroups

    The "Newsgroups" line specifies the newsgroup or newsgroups in which
    the message belongs.  Multiple newsgroups may be specified,
    separated by a comma.  Newsgroups specified must all be the names of
    existing newsgroups, as no new newsgroups will be created by simply
    posting to them.






 
RFC 1036              Standard for USENET Messages         December 1987


    Wildcards (e.g., the word "all") are never allowed in a "News-
    groups" line.  For example, a newsgroup comp.all is illegal,
    although a newsgroup rec.sport.football is permitted.

    If a message is received with a "Newsgroups" line listing some valid
    newsgroups and some invalid newsgroups, a host should not remove
    invalid newsgroups from the list.  Instead, the invalid newsgroups
    should be ignored.  For example, suppose host A subscribes to the
    classes btl.all and comp.all, and exchanges news messages with host
    B, which subscribes to comp.all but not btl.all.  Suppose A receives
    a message with Newsgroups: comp.unix,btl.general.

    This message is passed on to B because B receives comp.unix, but B
    does not receive btl.general.  A must leave the "Newsgroups" line
    unchanged.  If it were to remove btl.general, the edited header
    could eventually re-enter the btl.all class, resulting in a message
    that is not shown to users subscribing to btl.general.  Also,
    follow-ups from outside btl.all would not be shown to such users.

2.1.4.  Subject

    The "Subject" line (formerly "Title") tells what the message is
    about.  It should be suggestive enough of the contents of the
    message to enable a reader to make a decision whether to read the
    message based on the subject alone.  If the message is submitted in
    response to another message (e.g., is a follow-up) the default
    subject should begin with the four characters "Re:", and the
    "References" line is required.  For follow-ups, the use of the
    "Summary" line is encouraged.

2.1.5.  Message-ID

    The "Message-ID" line gives the message a unique identifier.  The
    Message-ID may not be reused during the lifetime of any previous
    message with the same Message-ID.  (It is recommended that no
    Message-ID be reused for at least two years.)  Message-ID's have the
    syntax:

                     <string not containing blank or ">">

    In order to conform to RFC-822, the Message-ID must have the format:

                          <unique@full_domain_name>

    where full_domain_name is the full name of the host at which the
    message entered the network, including a domain that host is in, and
    unique is any string of printing ASCII characters, not including "<"
    (left angle bracket), ">" (right angle bracket), or "@" (at sign).




 
RFC 1036              Standard for USENET Messages         December 1987


    For example, the unique part could be an integer representing a
    sequence number for messages submitted to the network, or a short
    string derived from the date and time the message was created.  For
    example, a valid Message-ID for a message submitted from host ucbvax
    in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
    Programmers are urged not to make assumptions about the content of
    Message-ID fields from other hosts, but to treat them as unknown
    character strings.  It is not safe, for example, to assume that a
    Message-ID will be under 14 characters, that it is unique in the
    first 14 characters, nor that is does not contain a "/".

    The angle brackets are considered part of the Message-ID.  Thus, in
    references to the Message-ID, such as the ihave/sendme and cancel
    control messages, the angle brackets are included.  White space