Usenet Format Working Group                            K. Murchison, Ed.
Internet-Draft                                        Oceana Matrix Ltd.                                Carnegie Mellon University
Obsoletes: 1036 (if approved)                                 C. Lindsey
Expires: January 9, June 19, 2006                          University of Manchester
                                                                 D. Kohn
                                                        Skymoon Ventures
                                                            July 8,
                                                       December 16, 2005

                         Netnews Article Format

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 9, June 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document specifies the syntax of network news (Netnews) articles
   in the context of the "Internet Message Format" (RFC 2822) and
   "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045).  This
   document supersedes RFC 1036, updating it to reflect current practice
   and incorporating incremental changes specified in other documents.

Note to the RFC Editor

   The normative reference to RFC 2234 and the informative reference to
   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and
   draft-ietf-nntpext-base respectively should it one or both of those of
   those documents reach RFC status before this one.

Changes since draft-ietf-usefor-usefor-05

   o  Resolved ticket #1003 (msg-id).

   o  Resolved ticket #1021 (Newsgroups description and exceptions).

   o  Resolved ticket #1028 (fixed ABNF for orig-date).

   o  Began adding text for ticket #1032 (diff from RFC 1036).

   o  Resolved ticket #1046 (MIME boundary security considerations).

   o  Addressed ticket #1047 (Path header field delimiters and
      components) using Harald's suggested text -- Still an open issue.

   o  Resolved ticket #1052 (diffs from RFC 2822).

   o  Resolved ticket #1053 (relationship to RFC 2822).

   o  Resolved ticket #1079 (header fields which don't permit CFWS).

   o  Applied text from ticket #1080 (Injection-Info MIME params).

   o  Resolved ticket #1082 (Approved header field semantics).

   o  Resolved ticket #1088 (Injection-Date mandatory/optional).

   o  Resolved ticket #1102 (Definition of "agents", etc).

   o  Removed RFC 0821 as a normative reference.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-04

   o  Resolved ticket #1002 (updated references).

   o  Applied text from ticket #1003 (ABNF cleanup for msg-id).

   o  Resolved ticket #1004 (deprecate X- headers).

   o  Resolved ticket #1008 (followups & References header field).

   o  Applied text from ticket #1021 (Newsgroups ABNF and description).

   o  Resolved ticket #1022 (obs-phrase).

   o  Applied text from ticket #1028 (GMT timezone for Date).

   o  Applied text from ticket #1042 (Newsgroups folding).

   o  Resolved ticket #1043 (RFC 2822 terms for header fields).

   o  Starting to resolve ticket #1052 (differences from RFC 2822).

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-03

   o  Reworked ABNFs of several headers.

   o  Used Charles' ABNF for <msg-id>.

   o  Disallowed comments in Supersedes header.

   o  Disallowed comments in Xref header.

   o  Disallowed comments in Message-Id header.

   o  CFWS between msg-ids in References header is not optional.

   o  Compatibility changes based on comments from Charles.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-02

   o  Changed to RFC 3978 boilerplate (xml2rfc v1.29)

   o  Changed "network news" to "Netnews" throughout.

   o  Prohibit NO-WS-CTL in msg-id.

   o  Complaints-To header is now an Injection-Info parameter.

   o  Added descriptions of Injection-Info parameters.

   o  Removed "filename" parameter from Archive header.

   o  Added CFWS to User-Agent header.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-01

   o  Removed half-hearted discussion of internal format and 8-bit clean

   o  Added definitions of "proto-article", "posting agent", "followup",
      "followup-agent", "user-agent", and "injecting agent".

   o  Removed discussion of message/partial MIME messages.

   o  Noted that the header contents in every line MUST NOT be empty.

   o  Merged MIME sections.

   o  Only allow "UT" and "GMT" in Date header; disallow all other <obs-

   o  Used Charles' ABNF for <msg-id> and <unstructured>.

   o  Removed restrictions on length and start character for Newsgroups.

   o  More verbose description of Path header.

   o  Disallowed comments in Control header.

   o  Specified that <control-command> is a verb optionally followed by
      whitespace-separated arguments.

   o  Noted that Supersedes header is different from [Son-of-1036].

   o  More exact ABNF for Archive and Injection-Info parameters.

   o  Discussed meaning of "yes", "no" in Archive header.

   o  Added "Obsolete Headers" section.

   o  Miscellaneous editorial changes

Changes since draft-ietf-usefor-article-13

   o  The Mail-Copies-To, Posted-And-Mailed headers have been moved to
      other documents.

   o  Dropped MIME parameters, as there is no WG consensus (per Chair).

   o  More exact ABNF for Archive and Injection-Info parameters.

   o  Complaints-To header is now an Injection-Info parameter.

Issues to be addressed

   o  MIME boundary security considerations.

   o  Ticket #1047: Path header field delimiters and components.

   o  Complete appendixes for changes from RFC 1036 and differences from
      RFC 2822.

   o  IANA considerations (the Klyne message header registry is now
      official as RFC 3864)?.

   o  Collected Syntax?

   o  Merge more security issues?

   o  Merge acknowledgments?

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.1 .  7
     1.1.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .   6
     1.2  7
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3  7
     1.3.  Requirements Notation  . . . . . . . . . . . . . . . . . .   6
     1.4  7
     1.4.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .   7
     1.5  8
     1.5.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   7
     1.6  8
     1.6.  Structure of This Document . . . . . . . . . . . . . . . .   8  9
   2.  Format . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.1 . 10
     2.1.  Base . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.2 10
     2.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . .   9
     2.3 10
     2.3.  MIME Conformance . . . . . . . . . . . . . . . . . . . . .  10 12
   3.  News Header Fields . . . . . . . . . . . . . . . . . . . . .  11
     3.1 . 13
     3.1.  Mandatory Header Fields  . . . . . . . . . . . . . . . . .  11
       3.1.1 13
       3.1.1.  From . . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.2 14
       3.1.2.  Date . . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.3 14
       3.1.3.  Message-ID . . . . . . . . . . . . . . . . . . . . . .  12
       3.1.4 14
       3.1.4.  Subject  . . . . . . . . . . . . . . . . . . . . . . .  14
       3.1.5 16
       3.1.5.  Newsgroups . . . . . . . . . . . . . . . . . . . . . .  15
       3.1.6 17
       3.1.6.  Path . . . . . . . . . . . . . . . . . . . . . . . . .  16
     3.2 18
     3.2.  Optional Header Fields . . . . . . . . . . . . . . . . . .  17
       3.2.1 20
       3.2.1.  Injection-Date . . . . . . . . . . . . . . . . . . . .  18
       3.2.2 20
       3.2.2.  References . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.3 21
       3.2.3.  Followup-To  . . . . . . . . . . . . . . . . . . . . .  19
       3.2.4 21
       3.2.4.  Expires  . . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.5 22
       3.2.5.  Control  . . . . . . . . . . . . . . . . . . . . . . .  20
       3.2.6 22
       3.2.6.  Supersedes . . . . . . . . . . . . . . . . . . . . . .  20
       3.2.7 22
       3.2.7.  Distribution . . . . . . . . . . . . . . . . . . . . .  20
       3.2.8 23
       3.2.8.  Summary  . . . . . . . . . . . . . . . . . . . . . . .  21
       3.2.9 23
       3.2.9.  Approved . . . . . . . . . . . . . . . . . . . . . . .  21
       3.2.10 23
       3.2.10. Organization . . . . . . . . . . . . . . . . . . . .  21
       3.2.11 . 24
       3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . .  22
       3.2.12 . 24
       3.2.12. Archive  . . . . . . . . . . . . . . . . . . . . . .  22
       3.2.13 . 24
       3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . .  23
       3.2.14 . 25
       3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . .  23
     3.3 . 25
     3.3.  Obsolete Header Fields . . . . . . . . . . . . . . . . . .  25
       3.3.1 27
       3.3.1.  Lines  . . . . . . . . . . . . . . . . . . . . . . . .  26 28
   4.  Internationalization Considerations  . . . . . . . . . . . .  27 . 29
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  28 . 30
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.1 . 31
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  29
     6.2 31
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  30
        Authors' Addresses 31
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 33
   Appendix B.  Differences from RFC 1036 and its derivatives . . .  31
   A.   Acknowledgements . 34
   Appendix C.  Differences from RFC 2822 . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . .  32
   B.   Differences from RFC 1036 . . . . . . . . . . . . . . . . .  33
   C.   Differences from RFC 2822  . . . . . . . . . . . . . . . . .  34 36
   Intellectual Property and Copyright Statements . . . . . . .  35 . . . 37

1.  Introduction


1.1.  Basic Concepts

   "Netnews" is a set of protocols for generating, storing and
   retrieving news "articles" (whose format is a subset of that for
   Email messages) and for exchanging them amongst a readership which is
   potentially widely distributed.  It is organized around "newsgroups",
   with the expectation that each reader will be able to see all
   articles posted to each newsgroup in which he participates.  These
   protocols most commonly use a flooding algorithm which propagates
   copies throughout a network of participating servers.  Typically,
   only one copy is stored per server, and each server makes it
   available on demand to readers able to access that server.


1.2.  Scope

   This document specifies the syntax of network news (Netnews) articles
   in the context of the "Internet Message Format" [RFC2822] and
   "Multipurpose Internet Mail Extensions (MIME)" [RFC2045].  This
   document supersedes [RFC1036], updating it to reflect current
   practice and incorporating changes and clarifications specified in
   other documents such as [Son-of-1036].

   This is the first in a set of documents that obsolete [RFC1036].
   This document focuses on the syntax and semantics of Netnews
   articles.  [USEPRO] is also a standards-track document, and describes
   the protocol issues of Netnews articles, independent of transport
   protocols such as [NNTP].  An  A best common practice document, [USEAGE],
   describes implementation recommendations to improve interoperability
   and usability.

   This specification is intended as a definition of what article
   content format is to be passed between systems.  Though some news
   systems locally store articles in this format (which eliminates the
   need for translation between formats) and others use formats that
   differ from the one specified in this standard, local storage is
   outside of the scope of this standard.


1.3.  Requirements Notation

   This document uses terms that appear in capital letters.  The key
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].


1.4.  Syntax Notation

   Header fields defined in this specification use the Augmented Backus-
   Naur Form (ABNF) notation (including the Core Rules) specified in
   [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
   Section 3.1.3 updates the [RFC2822] definition of <msg-id>.

   The following constructs referenced by this document are defined in
   [RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>,
   <address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS>
   and <CRLF>.

   The following constructs referenced by this document are defined in
   [RFC2045] (as amended by [RFC2231]): <token>, <parameter>, <value>.


1.5.  Definitions

   An "article" is the unit of news, synonymous with an [RFC2822]
   "message".  A "proto-article" is one that has not yet been injected
   into the news system.  In constrast to an "article", a "proto-
   article" may lack some mandatory header fields.

   A "message identifier" (Section 3.1.3) is a unique identifier for an
   article, usually supplied by the "posting "user agent" which posted it or,
   failing that, by the "injecting agent". "news server".  It distinguishes the article
   from every other article ever posted anywhere.  Articles with the
   same message identifier are treated as if they are the same article
   regardless of any differences in the body or header. header fields.

   A "newsgroup" is a single news forum, a logical bulletin board,
   having a name and nominally intended for articles on a specific
   topic.  An article is "posted to" a single newsgroup or several
   newsgroups.  When an article is posted to more than one newsgroup, it
   is said to be "crossposted"; note that this differs from posting the
   same text as part of each of several articles, one per newsgroup.

   A newsgroup may be "moderated", in which case submissions are not
   posted directly, but mailed to a "moderator" for consideration and
   possible posting.  Moderators are typically human but may be
   implemented partially or entirely in software.

   A "poster" is the person or software that composes and submits a
   possibly compliant article to a "posting "user agent".  The poster is
   analogous to [RFC2822]'s author.

   A "posting agent" is the software that assists posters to prepare
   proto-articles, in compliance with this standard.  The proto-article
   is then passed on to an "injecting agent" for final checking and
   injection into the news stream.  If the article is not compliant, or
   is rejected by the injecting agent, then the posting agent informs
   the poster with an explanation of the error.

   A "reader" is the person or software reading news articles.

   A "reading agent" is software which presents articles to a reader.

   A "followup" is an article containing a response to the contents of
   an earlier article, its "precursor".  Every followup includes a
   "References" header field identifying that precursor (but note that
   non-followup articles may also use a References header field).

   A "followup agent" is a combination of reading agent and posting
   agent that aids in the preparation and posting of a followup.

   Posting, reading and followup agents (which are usually just
   different services provided by the same piece of software) are known
   collectively as "user agents".

   An "injecting agent" takes the finished article from the posting
   agent (often via the [NNTP] "post" command) performs some final
   checks and passes it on to a relaying agent for general distribution.

   A "control message" is an article which is marked as containing
   control information; a relaying or serving agent news server receiving such an article may
   (subject to the policies observed at that site) take actions beyond
   just filing and passing on the article.


   A "news server" is software that may accept articles from a "user
   agent", and/or make articles available to user agents, and/or
   exchange articles with other news servers.

   A "user agent" is software that may help posters submit proto-
   articles to a news server, and/or fetch articles from a news server
   and present them to a reader, and/or assist the reader in creating
   articles and followups.

   The generic term "agent" is used when describing requirements that
   apply to both user agents and news servers.

1.6.  Structure of This Document

   This document uses a cite by reference methodology, rather than
   repeating the contents of other standards, which could otherwise
   result in subtle differences and interoperability challenges.
   Although this document is as a result rather short, it requires
   complete understanding and implementation of the normative references
   to be compliant.

   Section 2 defines the format of news articles.  Section 3 details the
   header fields necessary to make an article suitable for the Netnews

2.  Format


2.1.  Base

   News articles MUST conform

   An article is said to be conformant to this specification if it
   conforms to the syntax format specified in Section [RFC2822] section 3 of
   [RFC2822].  Netnews agents MAY also accept and to the obsolete syntax
   specified in Section 4
   additional requirements of this specification.

   An article that uses the obsolete syntax specified in section 4 of
   [RFC2822], but they MUST except for the two exceptions mentioned below, is NOT generate
   productions of such syntax.

   Agents MUST accept
   conformant to this specification.

   Articles are conformant if they use the obs-phrase <obs-phrase> construct (use
   of a phrase like "John Q. Public" without the use of quotes, see
   [RFC2822] section 4.1) but they agents MUST NOT generate productions of
   such syntax.

   Articles are conformant if they use the "GMT" <zone>, as specified in
   Section 3.1.2.

   This document, and specifications that build upon it, specifies how
   to handle conformant articles.  Handling of non-conformant articles
   is outside the scope of this specification.

   Agents conforming to this specification MUST generate only conformant

   The text below uses ABNF to specify restrictions on the syntax
   specified in [RFC2822]; this grammar is intended to be more
   restrictive than the [RFC2822] grammar.  Articles must conform to the
   ABNF specified in [RFC2822].

   Articles must also conform to the restrictions specified here, both
   those that are expressed as text and those that are expressed as

      NOTE: Older Netnews specifications used the term "header" as a
      synonym for what [RFC2822] calls "header field".  This document
      follows the terminology in Section 2 of [RFC2822] in using the
      terms "line", "header field", "header field name", "header field
      body", and "folding", based on a belief that consistent
      terminology among specifications that depend on each other makes
      the specifications easier to use in the long run.


2.2.  Header Fields

   All header fields in a news article are compliant with [RFC2822],
   however this specification is less permissive in what can be
   generated and accepted by news agents.  The syntax allowed for news
   articles is a strict subset of the "Internet Message Format", making
   all messages compliant with this specification inherently compliant
   with [RFC2822].  Note however that the converse is not guaranteed to
   be true in all cases.

   General rules which apply to all header fields (even those documented
   in [RFC2822] and [RFC2045]) are listed below and those that apply to
   specific header fields are described in the relevent sections of this

   o  All agents MUST generate header fields so that at least one space
      immediately follows the ':' separating the header field name and
      the header field body (for compatibility with deployed software). software,
      including [NNTP] servers).  News agents MAY accept header fields
      which do not contain the required space.

   o  Every line of a header field body (including the first and any
      that are subsequently folded) MUST contain at least one non-
      whitespace character.

         NOTE: This means that no header field body defined by or
         referenced by this document can be empty.  As a result, this
         document updates the <unstructured> construct from Section
         3.2.6 of [RFC2822] as follows:

   unstructured    =  1*( [FWS] utext ) [FWS]

   o  Compliant software MUST NOT generate (but MAY accept) header
      fields of more than 998 octets.  This is the only limit on the
      length of a header field prescribed by this standard.  However,
      specific rules to the contrary may apply in particular cases (for
      example, according to [RFC2047] lines of a header field containing
      encoded-words are limited to 76 octets).  [USEAGE] includes
      suggested limits for convenience of display by user agents.

         NOTE: There is NO restriction on the number of lines into which
         a header field may be split, and hence there is NO restriction
         on the total length of a header field (in particular it may, by
         suitable folding, be made to exceed the 998 octets restriction
         pertaining to a single header line).

   o  The character set for header fields is US-ASCII.  Where the use of
      non-ASCII characters is required, they MUST be encoded using the
      MIME mechanisms defined in [RFC2047] and [RFC2231].


2.3.  MIME Conformance

   User agents MUST meet the definition of MIME-conformance in [RFC2049]
   and MUST also support [RFC2231].  This level of MIME Conformance
   provides support for internationalization and multimedia in message
   bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
   internationalization of header fields ([RFC2047], [RFC2231]).  Note
   that [Errata] currently exist for [RFC2046] and [RFC2231].

   For the purposes of Section 5 of [RFC2047], all header fields defined
   in Section 3 of this standard are to be considered as "extension
   message header fields" (insofar as they are not already so considered
   under the existing Email standards), permitting the use of [RFC2047]
   encodings within any <unstructured> header field, or within any
   <comment> or <phrase> permittted within any structured header field.

   User agents MAY accept and generate other MIME extension header
   fields, and in particular SHOULD accept Content-Disposition [RFC2183]
   and Content-Language [RFC3282].

3.  News Header Fields

   The following news header fields extend those defined in section 3.6
   of [RFC2822]:

   fields          =/ *( newsgroups /
                         path /
                         injection-date /
                         followup-to /
                         expires /
                         control /
                         supersedes /
                         distribution /
                         summary /
                         approved /
                         organization /
                         xref /
                         archive /
                         user-agent /
                         injection-info )

   Each of these header fields may occur at most once in a news article.


   The following header fields defined in this document do not allow
   comments (CFWS):


   This also applies to the following header field defined in [RFC2822]:


   Several of these headers are mainly of interest to servers, and
   servers often need to process these fields very rapidly.

3.1.  Mandatory Header Fields

   Each news article conformant with this specification MUST have
   exactly one of each of the following header fields: From, Date,
   Message-ID, Subject, Newsgroups, Path.


3.1.1.  From

   The From header field is the same as that specified in Section 3.6.2
   of [RFC2822] with the added restrictions detailed in Section 2.2.

   from            =  "From:" SP mailbox-list CRLF


3.1.2.  Date

   The Date header field is the same as that specified in Sections 3.3
   and 3.6.1 of [RFC2822] with the added restrictions detailed in
   Section 2.2.  However, the use of "GMT" as a time zone (part of <obs-
   zone>), although deprecated, is widespread in news articles today.
   Therefore, agents MUST accept <date-time> constructs which use the
   "GMT" zone.


   orig-date       =  "Date:" SP date-time CRLF

      NOTE: This specification does not change [RFC2822], which says
      that agents MUST NOT generate <date-time> constructs which include
      any zone names defined by <obs-zone>.

   Software that accepts dates with unknown timezones SHOULD treat such
   timezones as equivalent to "-0000" when comparing dates, as specified
   in [RFC2822] section 4.3.

   Also note that these requirements apply wherever <date-time> is used,
   including Injection-Date and Expires in Section 3.2.1 and
   Section 3.2.4 respectively.


3.1.3.  Message-ID

   The Message-ID header field contains a single unique message
   identifier.  Netnews is more dependent on message identifier
   uniqueness and fast comparison than Email is, and some news software
   and standards [RFC0977] might have trouble with the full range of
   possible <msg-id>s permitted by [RFC2822]; this section therefore
   restricts the syntax of <msg-id> as compared to Section 3.6.4 of
   [RFC2822].  The global uniqueness requirement for <msg-id> in
   [RFC2822] is to be understood as applying across all protocols using
   such message identifiers, and across both Email and Netnews in

   message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF

   msg-id          =  "<" id-left "@" id-right ">"
                      ; maximum length is 250 octets

   id-left         =  dot-atom-text / no-fold-quote

   id-right        =  dot-atom-text / no-fold-literal

   no-fold-quote   =  DQUOTE
                         ( "." *mqtext /
                           *mqtext "." /
                           *mqtext mqspecial *mqtext )

   mqtext          =  atext / "." / mqspecial

   mqspecial       =  "(" / ")" /      ; same as specials except
                      "<" /            ; "\" and DQUOTE quoted
                      "[" / "]" /      ; "." doubled and ">" omitted
                      ":" / ";" /
                      "@" / "," /
                      ".." / "\\" / "\" DQUOTE

   no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"

   mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                      %d63-90 /        ; characters not including
                      %d94-126         ; ">", "[", "]", or "\"

   The msg-id MUST NOT be more than 250 octets in length.

      NOTE: The length restriction ensures that systems which accept
      message identifiers as a parameter when retrieving an article
      (e.g.  [NNTP]) can rely on a bounded length.

   Observe that msg-id includes the < and >.

   Observe also that in contrast to the corresponding header field in

   o  the syntax does not allow comments within the Message-ID header

   o  it ensures that no string of characters is quoted if it was
      already a <dot-atom-text> (it MUST start or end with a ".", or
      contain at least one <mqspecial>),
   o  it ensures that no single character is prefixed by a "\" in the
      form of a <quoted-pair> unless strictly necessary,

   o  it excludes all control characters,

   o  there is no possibility for ">" or WSP to occur inside a <msg-id>,
      whether quoted or not, and

   o  even though commonly derived from <domain>s, <id-rights>s are
      case-sensitive (and thus, once created, are not to be altered
      during subsequent transmission or copying)

   This is to simplify processing by relaying and serving agents news servers and to ensure
   interoperability with existing implementations and compliance with
   [NNTP].  Thus, whereas under [RFC2822] the following <msg-id>s would
   be considered semantically equivalent,



   only the first of them is syntactically permitted by this standard,
   and hence a simple comparison of octets will always suffice to
   determine the identity of two <msg-id>s.

   Also note that this updated ABNF applies wherever <msg-id> is used,
   including the References header field discussed in Section 3.2.2 and
   the Supersedes header field discussed in Section 3.2.6.

   Some software will try to match the <id-right> of a <msg-id> in a
   case-insensitive fashion; some will match it in a case-sensitive
   fashion.  Implementations MUST NOT generate two Message-IDs where the
   only difference is the case of characters in the <id-right> part.


   When generationg a <msg-id>, implementations SHOULD use a domain literals are used, name
   as the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED. <id-right>.

      NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
      should be a domain name or a domain literal.  Domain literals are
      troublesome since many IP addresses are not globally unique;
      domain names are more likely to generate unique Message-IDs.


3.1.4.  Subject

   The Subject header field is the same as that specified in Section
   3.6.5 of [RFC2822] with the added restrictions detailed in
   Section 2.2.  Further discussion of the content of the Subject header
   field appears in [USEPRO] and [USEAGE].

   subject         =  "Subject:" SP unstructured CRLF


3.1.5.  Newsgroups

   The Newsgroups header field specifies the newsgroup(s) to which the
   article is posted.

   newsgroups      =  "Newsgroups:" SP newsgroup-list CRLF

   newsgroup-list  =  [FWS] newsgroup-name
                      *( [FWS] "," [FWS] newsgroup-name ) [FWS]

   newsgroup-name  =  component *( "." component )

   component       =  1*component-char

   component-char  =  ALPHA / DIGIT / "+" / "-" / "_"

      NOTE: Observe that the syntax does not allow comments within the
      Newsgroups header field; this is to simplify processing by
      relaying and serving agents which have a requirement to process
      this header field extremely rapidly.

   Folding the Newsgroups header field over several lines has been shown
   to harm propagation significantly.  Folded Newsgroups header fields
   SHOULD NOT be generated, but MUST be accepted.

   A newsgroup component SHOULD NOT consist of digits only, and SHOULD
   NOT contain uppercase letters.  Such components MAY be used only to
   refer to existing groups that do not conform to this naming scheme.

      NOTE: All-digit components conflict with one widely used storage
      scheme for articles.  Mixed case groups cause confusion between
      systems with case sensitive matching and systems with case
      insensitive matching of newsgroup names.

   Components <newsgroup-name>s.

   <component>s beginning with underline ("_") are reserved for use by
   future versions of this standard and MUST NOT be generated by posting user
   agents (whether in Newsgroups header fields or in newgroup control
   messages [USEPRO]).  However, such names MUST be accepted by relaying
   and serving agents.

   Components news

   <component>s beginning with "+" and "-" are reserved for private use
   and MUST NOT be generated by posting user agents (whether in Newsgroups
   header fields or in newgroup control messages [USEPRO]) without a
   private prior agreement to do so.  However, such names MUST be
   accepted by relaying and serving agents. news servers.

   The following newsgroup names <newsgroup-name>s are reserved, and MUST NOT be used as
   the name of a newsgroup:

   o  Groups starting with the whose first (or only) component is "example"
   o  The group "poster"

   The following newsgroup names <newsgroup-name&gts have been used for specific
   purposes in various implementations and protocols, and MUST therefore not MUST
   NOT be used for the names of normal newsgroups.  They MAY be used for
   their specific purpose, or by local agreement.

      Groups starting with the whose first (or only) component is "to"

      Groups starting with the whose first (or only) component is "control"

      Groups containing which contain (or consist only of) the component "all"

      Groups containing which contain (or consist only of) the component "ctl"

      The group "junk"

      NOTE: The list above includes "example.*" is reserved for examples in this and other
      standards; "poster" has a special meaning in the groups "to", "control", "all", Followup-To
      header field; "to.*" is reserved for certain point-to-point
      communications in conjunction with the "ihave" control message
      [USEPRO]; "control.*" and "junk" have special meanings in some
      news-servers; "all" is used as a wildcard in some implementations;
      and "ctl".

3.1.6 "ctl" was formerly used to indicate a <control-command> within
      the Subject header field.

3.1.6.  Path

   The Path header field indicates the route taken by an article since
   its injection into the Netnews system.  Each agent that processes an
   article is required to prepend one (or more) identities to this
   header field body.  This is primarily to enable relaying agents news servers to avoid
   sending articles to sites already known to have them, in particular
   the site they came from, and additionally to permit tracing the route
   articles take in moving over the network, and for gathering Usenet

   path            =  "Path:" SP path-list CRLF

   path-list       =  [FWS]
                      *( ( path-identity / path-keyword /
                           path-diagnostic ) [FWS]
                         path-delimiter [FWS] )
                      tail-entry [FWS]

   path-identity   =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

   path-keyword    =  "POSTED" / "MISMATCH"

   path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

   tail-entry      =  path-identity

   path-delimiter  =  "!" / "!!"

   A <path-identity> is a name identifying a site.  It takes the form of
   a domain name having one or more components separated by dots.

   Each <path-identity> in the <path-list> (excluding the one in the
   <tail-entry>) indicates, from right to left, the successive agents
   through which the article has passed.  The <keyword> <path-keyword> "POSTED"
   indicates that the agent to its left injected the article.  The use
   of the <path-delimiter> "!!" indicates that the agent to its left
   claims that the agent to its right was the verified source of the
   article (whereas the <path-delimiter> "!" implies no such claim).
   The <keyword> <path-keyword> "MISMATCH" indicates that the agent to its right
   failed to be so verified.  The full procedure for constructing a Path header
   field as well as the specific format and use of <path-identity> and
   <tail-entry> are discussed in [USEPRO].

      NOTE: Historically, the <tail-entry> indicated the name of the
      sender.  If not used for this purpose, the string "not-for-mail"
      is often used instead (since at one time the whole path could be
      used as a mail address for the sender).

      NOTE: Although case-insensitive, it is intended that the <path-
      keyword>s "POSTED" and "MISMATCH" should be in upper case, to
      distinguish them from the <path-identity>s which are traditionally
      in lower case.

3.2  Optional Header Fields

   None of

   A <path-diagnostic> is an item inserted into the Path header fields appearing in this section for
   purposes other than to indicate the name of a site.  One commonly
   observed usage is required to
   appear insert an IP address.  The colon (":") is
   permitted in every article but some of them may order to allow IPv6 addresses to be required in certain
   types of articles.  Further discussion of inserted; note that
   this will cause interoperability problems at older sites that regard
   ":" as a <path-delimiter> and have neighbors whose names have 4 or
   fewer characters, and where all the characters are valid HEX digits.

3.2.  Optional Header Fields

   None of the header fields appearing in this section is required to
   appear in every article but some of them may be required in certain
   types of articles.  Further discussion of these requirements appears
   in [USEPRO] and [USEAGE].

   The header fields Reply-To, Sender, Comments, and Keywords are used
   in news articles in the same circumstances and with the same meaning
   as that specified in [RFC2822] with the added restrictions detailed
   in Section 2.2.  Multiple occurances of the Keywords header field are
   not permitted.

   sender          =  "Sender:" SP mailbox CRLF

   reply-to        =  "Reply-To:" SP address-list CRLF

   comments        =  "Comments:" SP unstructured CRLF

   keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

   The MIME header fields MIME-Version, Content-Type, Content-Transfer-
   Encoding, Content-Disposition, and Content-Language are used in news
   articles in the same circumstances and with the same meanings as
   those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
   restrictions detailed in Section 2.2.

   All remaining news header fields are described below.


3.2.1.  Injection-Date

   The Injection-Date header field contains the date and time that the
   article was injected into the network.  Its purpose is to prevent the
   reinjection into the news stream of "stale" articles which have
   already expired by the time they arrive at some relaying or serving
   agent. news server.

   This header field MUST be inserted whenever an article is injected.
   However, software that predates this standard does not use this
   header, and therefore agents MUST accept articles without the
   Injection-Date header field.

   injection-date  =  "Injection-Date:" SP date-time CRLF

   See the remarks under Section 3.1.2 regarding the syntax of date-
   time <date-
   time> and the requirements and recommendations to which it is

      NOTE: The date-time <date-time> in this header field would normally be
      expected to be later than the date-time <date-time> in the Date header
      field, but differences between the clocks on the various agents
      and other special circumstances might vitiate that; no provision
      is made for any such discrepancy to be corrected - better that the injecting
      news server should just insert the correct time as it sees it.

   This header field is intended to replace the currently-used but
   undocumented "NNTP-Posting-Date" header field, whose use is now


3.2.2.  References

   The References header field is the same as that specified in Section
   3.6.4 of [RFC2822] with the added restrictions detailed in
   Section 2.2 and those listed below:

   o  The updated <msg-id> construct defined in Section 3.1.3 MUST be

   o  Message identifiers MUST be separated with CFWS.

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

   references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id)
                      [CFWS] CRLF


3.2.3.  Followup-To

   The Followup-To header field specifies to which newsgroup(s)
   followups should be posted.  The Followup-To header field SHOULD NOT
   appear in a message, unless its content is different from the content
   of the Newsgroups header field.

   followup-to     =  "Followup-To:" SP ( newsgroup-list / poster-text )

   poster-text     =  [FWS] %d112. [FWS]
                      ; "poster" in lower-case

   The syntax is the same as that of the Newsgroups header field
   (Section 3.1.5, with the exception that the keyword "poster" (which
   is always lowercase) requests that followups should be mailed to the
   article's reply address rather than posted.  Although the keyword
   "poster" is case-sensitive, followup user agents MAY choose to recognize
   case-insensitive case-
   insensitive forms such as "Poster".


3.2.4.  Expires

   The Expires header field specifies a date and time when the article
   is deemed to be no longer relevant and could usefully be removed

   expires         =  "Expires:" SP date-time CRLF

   See the remarks under Section 3.1.2 regarding the syntax of date-
   time <date-
   time> and the requirements and recommendations to which it is


3.2.5.  Control

   The Control header field marks the article as a control message, and
   specifies the desired actions (additional to the usual ones of
   storing and/or relaying the article).

   control         =  "Control:" SP [FWS] control-command [FWS] CRLF

   control-command =  verb *( [FWS] argument )

   verb            =  token

   argument        =  value

   The verb indicates what action should be taken, and the argument(s)
   (if any) supply details.  In some cases, the body of the article may
   also contain details.  The legal verbs and respective arguments are
   discussed in the companion document, [USEPRO].

   An article with a Control header field MUST NOT also have a
   Supersedes header field.


3.2.6.  Supersedes

   The Supersedes header field contains a message identifier specifying
   an article to be superseded upon the arrival of this one.  An article
   containing a Supersedes header field is equivalent to a "cancel"
   [USEPRO] control message for the specified article, followed
   immediately by the new article without the Supersedes header field.

   supersedes      =  "Supersedes:" SP [FWS] msg-id [FWS] CRLF

   NOTE: There is no "c" in Supersedes.

   NOTE: The Supersedes header field defined here has no connection with
   the Supersedes header field that sometimes appears in Email messages
   converted from X.400 according to [RFC2156]; in particular, the
   syntax here permits only one <msg-id> in contrast to the multiple
   <msg-id>s in that Email version.


3.2.7.  Distribution

   The Distribution header field specifies geographic or organizational
   limits on an article's propagation.

   distribution    =  "Distribution:" SP dist-list CRLF

   dist-list       =  [FWS] dist-name
                      *( [FWS] "," [FWS] dist-name ) [FWS]

   dist-name       =  ALPHA / DIGIT
                      *( ALPHA / DIGIT / "+" / "-" / "_" )

   The <dist-name>s "world" and "local" are predefined.  However,
   "world" SHOULD NOT be used explicitly, since it is the default when
   the Distribution header field is absent entirely.

   "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain
   at least three characters, except when they are two-letter country
   names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e.
   "US", "Us", "uS", and "us" all specify the same distribution).


3.2.8.  Summary

   The Summary header field is a short phrase summarizing the article's

   summary         =  "Summary:" SP unstructured CRLF


3.2.9.  Approved

   The Approved header field indicates the mailing addresses (and
   possibly the full names) of the persons or entities approving the
   article for posting.  Its principal uses are in moderated articles
   and in group control messages [USEPRO].

   approved        =  "Approved:" SP mailbox-list CRLF

   Each mailbox contained in the Approved header field MUST be that of
   one of the person(s) or entity(ies) in question, and one of those
   mailboxes MUST be that of the actual sender of the article.  Note
   that this standard does not provide any means to enforce or verify
   this requirement, but future extensions or standards may provide such
   a facility (e.g. digitial signatures).


3.2.10.  Organization

   The Organization header field is a short phrase identifying the
   poster's organization.

   organization    =  "Organization:" SP unstructured CRLF

   There is no "s" in Organization.


3.2.11.  Xref

   The Xref header field indicates where an article was filed by the
   last serving agent news server to process it.  The article locations are used to
   keep track of crossposted articles so that reading user agents serviced by a
   particular serving agent news server can mark such articles as read.

   xref            =  "Xref:" SP [FWS] server-name
                      1*( FWS location ) [FWS] CRLF

   server-name     =  path-identity

   location        =  newsgroup-name ":" article-locator

   article-locator =  1*( %x21-27 / %x29-3A / %x3C-7E )
                      ; US-ASCII printable characters
                      ; except '(' and ';'

   The <server-name> is included so that software can determine which
   serving agent
   news server generated the header field.  The locations specify what
   newsgroups the article was filed under (which may differ from those
   in the Newsgroups header field) and where it was filed under them.
   The exact form of an article-locator <article-locator> is implementation-specific.

      NOTE: The traditional form of an article-locator <article-locator> (as required by
      [NNTP]) is a decimal number, with articles in each newsgroup
      numbered consecutively starting from 1.


3.2.12.  Archive

   The Archive header field provides an indication of the poster's
   intent regarding preservation of the article in publicly accessible
   long-term or permanent storage.

   archive         =  "Archive:" SP [CFWS] ("no" / "yes")
                      *( [CFWS] ";" archive-param ) CRLF

   archive-param   =  parameter

   The presence of an Archive header field in an article with a field
   body of "no" indicates that the poster does not permit redistribution
   from publicly accessible long-term or permanent archives.  The
   absence of this header field, or the presence of this header field
   with a field body of "yes", indicates that the poster is willing for
   such redistribution to take place.  Further extensions to this
   standard may provide parameters for administration of the archiving


3.2.13.  User-Agent

   The User-Agent header field contains information about the user agent
   (typically a newsreader) generating the article, for statistical
   purposes and tracing of standards violations to specific software
   needing correction.  It is intended that this header field be
   suitable for use in Email.

   user-agent      =  "User-Agent:" SP 1*product [CFWS] CRLF

   product         =  [CFWS] token [ [CFWS] "/" product-version ]

   product-version =  [CFWS] token

   This header field MAY contain multiple product-tokens identifying the
   user agent and any subproducts which form a significant part of the
   posting agent, it,
   listed in order of their significance for identifying the

      NOTE: Some of this information has previously been sent in non-
      standardized header fields such as X-Newsreader, X-Mailer,
      X-Posting-Agent, X-Http-User-Agent, and others.  Once an a user agent
      uses User-Agent, it should have no need to send these non-standard
      header fields.

      NOTE: [RFC2616] describes a similar facility for the HTTP
      protocol.  This specification differs in that "{" and "}" are
      allowed in tokens (<product> and <product-version>) and comments
      are permitted wherever whitespace is allowed.


3.2.14.  Injection-Info

   The Injection-Info header field provides contains information provided by the
   injecting news server as to how an article entered the Netnews system
   and to assist in tracing its true origin.  It can also specify one or
   more addresses where complaints concerning the poster of the article
   may be sent.

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                      *( [CFWS] ";" [CFWS] inj-info-param )
                      [CFWS] *(';' parameter) CRLF

   inj-info-param  =  post-host-param /
                      post-acct-param /
                      sender-param /
                      logging-param /
                      complainto-param /

      NOTE: The syntax of <parameter> ([RFC2045] as amended by
      [RFC2231]), taken in conjunction with the folding rules of
      [RFC0822], effectively allows [CFWS] to occur both before and
      after the <parameter>, and also on either side of its "=".

   The following table gives the <attribute> and the format of the
   <value> for each <parameter> defined for use with this header field.
   At most one occurrence of "post-host-param",
                      ;; "post-acct-param", "sender-param",
                      ;; "logging-param" or "complainto-param"
                      ;; each such <parameter> is allowed.

   ext-param       = parameter
   [[Should also allow for x-attributes?]]

   post-host-param =

   <attribute>              format of <value>
   --------------------     -----------------
   "posting-host" "=" host-value           a <host-value>
   "posting-account"        any <value>
   "sender"                 a <sender-value>
   "logging-data"           any <value>
   "mail-complaints-to"     an <address-list>


   host-value      =  dot-atom  dot-atom-text / [ dot-atom dot-atom-text ":" ]
                      ( IPv4address / IPv6address ) ;  see [RFC 3986]

   post-acct-param =  "posting-account" "=" value

   sender-param    =  "sender" "=" sender-value

   sender-value    =  mailbox / "verified"

   logging-param   =  "logging-data" "=" value

   complainto-param=  "mail-complaints-to" "=" address-list

   Although comments and folding of white space are permitted throughout

      NOTE: Since any such <host-value>>, <sender-value> or <address-
      list> has also to be a syntactically correct <value>, it will
      usually be necessary to encapsulate is as a <quoted-string>, for

   sender = "\"Joe Q. Public\" <>"

   Additionally, any other <parameter> whose <attribute> starts with
   "x-" MAY be used where the defined ones appear to be unsuitable, but
   other unlisted <parameter>s SHOULD NOT be used unless defined in
   extensions to this standard.

   Although comments and folding of white space are permitted throughout
   the Injection-Info header field, it is RECOMMENDED that folding is
   not used within any parameter <parameter> (but only before or after the ";"
   separating those parameters), <parameter>s), and that comments are only used
   following the last parameter. <parameter>.

      NOTE: Some of this information has previously been sent in non-
      standardized header fields such as NNTP-Posting-Host, X-trace,
      X-Complaints-To, and others.  Once an injecting agent a news server uses
      Injection-Info, Injection-
      Info, it should have no need to send these non-standard header

   The "posting-host" parameter <parameter> specifies the FQDN and/or IP address
   (IPv4address or IPv6address) of the host from which the injecting
   agent news server
   received the article.

      NOTE: If the "posting-host" parameter <parameter> identifies a dial-up point-
      point-of-presence, the "posting-account" or the "logging-data" parameter
      <parameter> may provide additional information about true origin
      of the article.

   The "posting-account" parameter <parameter> identifies the source from which the
   injecting agent
   that news server received the article.  For security reasons, it
   SHOULD be in a cryptic notation understandable only by the
   administrator of the injecting agent. news server.

   The "sender" parameter <parameter> identifies the mailbox of the verified
   sender of the article (alternatively, it uses the token "verified" to
   indicate that at least any addr-spec in the Sender header field of
   the article, or in the From header field if the Sender header field
   is absent, is correct).  If an injecting agent a news server can verify the sender of an
   article, it SHOULD use this parameter <parameter> in favour favor of the "posting-
   account" parameter. <parameter>.

   The "logging-data" parameter <parameter> contains information (typically a
   session number or other non-persistent means of identifying a posting
   account) which will enable the true origin of the article to be
   determined by reference to logging information kept by the injecting
   agent. news

   The "mail-complaints-to" parameter <parameter> specifies mailbox(es) for
   sending complaints concerning the behavior of the poster of the


3.3.  Obsolete Header Fields

   Early versions of news software following the modern format sometimes
   generated header fields like the following:

   Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
   Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
   Date-Received: Friday, 19-Nov-82 16:59:30 EST

   Relay-Version contained version information about the relaying agent news server
   that last processed the article.  Posting-Version contained version
   information about the posting user agent that posted the article.  Date-
   Received contained the date when the last relaying agent news server to process the
   article first saw it (in a slightly nonstandard format).

   In addition, this present standard obsoletes certain header fields
   defined in [Son-of-1036]:

   Also-Control: cancel <9urrt98y53@site.example>
   See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
   Article-Updates: <i4g587y@site1.example>

   Also-Control indicated a control message that was also intended to be
   filed as a normal article.  See-Also listed related articles, but
   without the specific relationship with followups that pertains to the
   References header field.  Article-Names indicated some special
   significance of that article in relation to the indicated newsgroup.
   Article-Updates indicated that an earlier article was updated,
   without at the same time being superseded.

   The header fields listed above are documented for historical purposes
   only.  Articles containing these header fields MUST NOT be generated.
   Persons writing new agents SHOULD ignore any former meanings of these
   header fields.


3.3.1.  Lines

   The Lines header field indicates the number of lines in the body of
   the article.

   lines           =  "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF

   The line count includes all body lines, including the signature if
   any, including empty lines (if any) at the beginning or end of the
   body, and including the whole of all MIME message and multipart parts
   contained in the body (the single empty separator line between the
   header fields and the body is not part of the body).  The "body" here
   is the body as found in the posted article as transmitted by the
   posting user

   Historically, this header field was used by the [NNTP] overview
   extension, but its use for this purpose is now deprecated.  As a
   result, this header field is to be regarded as obsolescent, and it is
   likely to be removed entirely in a future version of this standard.
   Servers and clients SHOULD ignore it, and SHOULD NOT generate it.

4.  Internationalization Considerations

   Internationalization of news article header fields and bodies is
   provided using MIME mechanisms discussed in Section 2.3.  Note that
   the generation of internationalized newsgroup names <newsgroup name>s for use in
   header fields is not addressed in this document.

5.  Security Considerations

   The news article format specified in this document does not provide
   any security services, such as confidentiality, authentication of
   sender, or non-repudiation.  Instead, such services need to be
   layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME
   [RFC3156], or below, using secure versions of news transport
   protocols.  Additionally, several currently non-standardized
   protocols [PGPVERIFY] will hopefully be standardized in the near

   Message identifiers (Section 3.1.3) in news are required to be
   unique; articles are refused (in server-to-server transfer) if the
   identifier has already been seen.  So if you can predict the
   identifier of a message, you can preempt it by posting a message
   (possibly to a quite different group) with the same message
   identifier, stopping your target message from propagating.  Agents
   that generate message identifiers for news articles SHOULD ensure
   that they are unpredictable.

   MIME security considerations are discussed in [RFC2046].  Note that
   the full range of encodings allowed for parameters in [RFC2046] and
   [RFC2231] permits constructs that simple parsers may fail to parse
   correctly; examples of hard-to-parse constructs are:

   Content-Type: multipart/mixed
   (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

   Content-Type: multipart/digest;
   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

   Such differences in parsing may be used as part of an attack.

6.  References


6.1.  Normative References

   [Errata]   "RFC Editor Errata".

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183, August 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              May 2002.


6.2.  Informative References

              International Organization for Standardization, "Codes for
              the representation of names of countries, 3rd edition",
              ISO Standard 3166, August 1988.

   [NNTP]     Feather, C., "Network News Transfer Protocol",

              Lawrence, D., "PGPverify", June 1999.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
              Protocol", RFC 977, February 1986.

   [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
              USENET messages", RFC 1036, December 1987.

   [RFC2156]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
              Mapping between X.400 and RFC 822/MIME", RFC 2156,
              January 1998.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

              Spencer, H., "News Article Format and Transmission",
              June 1994.

   [USEAGE]   Lindsey, C., "Usenet Best Practice",

   [USEPRO]   Lindsey, C., "News Article Architecture and Protocols",

Authors' Addresses

   Kenneth Murchison (editor)
   Oceana Matrix Ltd.
   21 Princeton Place
   Orchard Park, NY  14127

   Phone: +1 716 662 8973

   Charles H. Lindsey
   University of Manchester
   5 Clerewood Avenue
   Heald Green
   Cheshire  SK8 3JU

   Phone: +44 161 436 6131

   Dan Kohn
   Skymoon Ventures
   3045 Park Boulevard
   Palo Alto, CA  94306

   Phone: +1 650 327 2600

Appendix A.  Acknowledgements

   Comments and/or text were provided by Mark Crispin, Claus Faerber,
   Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson,
   Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey

Appendix B.  Differences from RFC 1036 and its derivatives

   This appendix contains a list of changes that have been made in the
   Netnews Article Format from earlier standards, specifically

Appendix C.  Differences from RFC 2822

   This appendix lists the

      The [RFC2822] conventions for parenthesis-enclosed <comment>s in
      header fields are supported in all newly defined header fields and
      in header fields inherited from [RFC2822].  They are, however,
      still disallowed for performance and/or compatibility reasons in
      the Message-ID, Newsgroups, Path, Followup-To, Control,
      Supersedes, Distribution, Xref and Lines header fields.

      Whitespace is permitted in Newsgroups header fields.

      An enhanced syntax for the Path header field enables the injection
      point of, and the route taken by an article to be determined with
      more precision.

      MIME is recognized as an integral part of Netnews.

      There is a new Injection-Date header to make the rejection of
      stale articles more precise and to minimize spurious rejections.

      There are several new optional header fields defined, notably
      Archive, Injection-Info and User-Agent, leading to increased

      Certain header fields, notably Lines, have been made obsolete
      (Section 3.3).

      There are numerous other small changes, clarifications and

Appendix C.  Differences from RFC 2822

   This appendix lists the differences between the syntax allowed by the
   Netnews Article Format (this document) as compared to the Internet
   Message Format, specifically as specified in [RFC2822].

   The Netnews article format is a strict subset of the Internet Message
   Format; all Netnews articles conform to the syntax of [RFC2822].

   The following restrictions are important:

      A SP (space) is REQUIRED after the colon (':') following header
      field name.

      A more restricted syntax of msg-id <msg-id> (to be used by the
      Message-ID, References, and Supersedes header fields). fields) is defined.

      The length of a msg-id MUST NOT exceed 250 octets.

      Comments are not allowed in the Message-ID header field.

      The CFWS between msg-ids <msg-id>s in the References header field is not

      An <unstructured> header field body MUST contain at least one non-
      whitespace character (header fields such as Subject can

      It is legal for a parser to not be
      empty). accept obsolete syntax, except

         The <obs-phrase> construct MUST be accepted.

         The obsolete timezone <zone> "GMT" MUST be accepted in the Date header

      The length within a <date-

      Every line of a msg-id header field body (including the first and any
      that are subsequently folded) MUST NOT exceed 250 octets. contain at least one non-
      whitespace character.  This means that an empty header field body
      is illegal.

Authors' Addresses

   Kenneth Murchison (editor)
   Carnegie Mellon University
   5000 Forbes Avenue
   Cyert Hall 285
   Pittsburgh, PA  15213

   Phone: +1 412 268 2638

   Charles H. Lindsey
   University of Manchester
   5 Clerewood Avenue
   Heald Green
   Cheshire  SK8 3JU

   Phone: +44 161 436 6131

   Dan Kohn
   Skymoon Ventures
   3045 Park Boulevard
   Palo Alto, CA  94306

   Phone: +1 650 327 2600

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.