Network News Transfer Protocol (NNTP)
obsoletes
- rfc-977 — Network News Transfer Protocol
updated by
- rfc-6048 — Network News Transfer Protocol (NNTP) Additions to LIST Command
updates
- rfc-2980 — Common NNTP Extensions
Extracted elements (28)
NNTP distinguishes 'reading' (client fetches articles for a user) from 'transit' (bulk peer-to-peer transfer). Some server implementations are optimized for one use. The official port 119 is for reading servers; port 433 SHOULD be used for transit servers to allow separate deployments.
The WILDMAT format deliberately excludes backslash (escape) and bracket (character class) syntax despite common use in other pattern matchers. Interpretation of these characters in UTF-8 strings is complex and differs across existing implementations, so they were omitted to avoid ambiguity.
The default character set is changed from US-ASCII (RFC 977) to UTF-8 in this specification. Implementations MUST be prepared to receive headers using octets 128–255 in other encodings when articles arrive from external sources, and MUST NOT assume headers are always valid UTF-8.
The distinction between 200 (posting allowed) and 201 (posting prohibited) initial greeting codes has proved insufficient in practice: some servers require authentication before allowing posting, and some clients incorrectly treat 201 as a permanent prohibition. Clients SHOULD use the CAPABILITIES command instead of relying on the greeting code.
A message-id MUST begin with '<', end with '>', contain no '>' except at the end, be between 3 and 250 octets in length, and contain only printable US-ASCII characters. If a server cannot determine a message-id from the article itself it MUST synthesize one.
Article numbers MUST lie in the range 1 to 2,147,483,647 inclusive. The server MUST issue article numbers in arrival order (later articles MUST receive higher numbers) and SHOULD allocate the next sequential unused number to each new article.
Articles MUST NOT contain NUL (%x00) and MUST NOT contain bare LF or CR outside CRLF pairs. Each article MUST have a unique message-id. Two articles offered by a server MUST NOT share the same message-id.
Following a 400 connection-termination response, clients SHOULD NOT reconnect and retry immediately. Instead they SHOULD use an exponentially increasing delay between retries or present the associated text to the user to decide whether and when to retry.
Generic response codes are mandatory: 500 for unrecognized commands, 501 for syntax errors, 403 for internal server faults, 503 for unsupported optional features, 502 for facilities requiring a new authorized connection, 480 for facilities requiring authentication, and 483 for facilities requiring privacy.
Registered extension capability labels and command names MUST NOT begin with 'X'. Private extension labels, if listed in capabilities, MUST begin with 'X'. If a server advertises a registered extension capability it MUST fully implement that extension; partial implementations MUST use a different (private) name.
The capability list MUST accurately reflect currently available capabilities and MUST only include a capability when the server is in the state where it is usable. Clients MUST NOT use cached capability results in relation to security, privacy, and authentication extensions.
The server MUST support pipelining: it MUST NOT discard text received after a command and MUST process commands in the order sent. Commands designated 'MUST NOT be pipelined' (e.g., MODE READER, initial connection) require the client to await the full response before sending the next command.
Upon initial connection the server MUST send a greeting: 200 if posting is allowed, 201 if posting is prohibited, or 400/502 if service is unavailable. Following a 400 or 502 response the server MUST immediately close the connection.
Where UTF-8 characters outside U+0000–U+007F are permitted, implementations MUST NOT use the Byte Order Mark (U+FEFF, %xEF.BB.BF) and MUST use the Word Joiner (U+2060) for the meaning Zero Width No-Break Space in command lines and initial response lines.
NNTP servers accumulate log data including client IP addresses, newsgroup subscription patterns, and article content that may reveal personal information. Server operators must be aware that log data and server-stored article data can expose users' reading interests and personal details.
An NNTP article consists of a header section and a body separated by a single blank line (two consecutive CRLF pairs). Header lines follow the format 'name: content CRLF' and may be folded by inserting CRLF before TAB or space. The body may be empty; the article MUST end with a CRLF pair.
NNTP response codes are three-digit status indicators. The first digit signals success (2xx), continuation (3xx), command failure (4xx), or server/syntax error (5xx). The second digit indicates function category: x0x connection, x1x newsgroup selection, x2x article selection, x4x posting, x8x authentication/privacy (reserved), x9x private use.
The CAPABILITIES command (mandatory) returns a multi-line list of capability lines. Each line begins with a capability label keyword followed by optional arguments. VERSION MUST be the first line and MUST be advertised by all servers; it carries the numeric NNTP version number(s) supported.
The GROUP command selects a newsgroup and returns '211 number low high group': an estimated article count (MUST be at least the actual count and no more than high−low+1), the reported low water mark, and the high water mark. Selecting a valid non-empty group sets the current article number to the first article.
The WILDMAT format provides newsgroup name pattern matching. A wildmat is a comma-separated list of patterns where '!' negates a pattern; the rightmost matching pattern determines the result. '*' matches zero or more characters; '?' matches exactly one character. Backslash and bracket syntax are excluded.
IANA maintains a registry of NNTP capability labels. All registered labels MUST be keywords and MUST NOT begin with 'X'. The initial entries include VERSION, READER, IHAVE, POST, NEWNEWS, HDR, OVER, LIST, IMPLEMENTATION, MODE-READER, AUTHINFO, SASL, STARTTLS, and STREAMING.
Clients MUST NOT use cached capability list results when making security, privacy, or authentication decisions. A stale cache could indicate that a security extension is unavailable when it is, or vice versa, leading to data sent over an unintended connection type.
Malformed UTF-8 input, including illegal sequences and overlong encodings, can be exploited to bypass security checks or inject control characters. Servers must validate UTF-8 carefully; the document notes that characters like '.' and '<' encoded via non-shortest forms could evade parsers.
NNTP servers that resolve client hostnames via DNS for access control are vulnerable to DNS spoofing. An attacker who can poison DNS responses could gain unauthorized access by causing the server to resolve an attacker-controlled IP to a trusted hostname.
The base NNTP protocol provides weak authentication and access control. Servers relying solely on source IP address for access control are vulnerable to IP spoofing. Extensions AUTHINFO (SASL) and STARTTLS are required for strong authentication and encryption of the connection.
A mode-switching server starts in transit mode (advertises MODE-READER, not READER) and transitions to reading mode after a successful MODE READER command (advertises READER, not MODE-READER; MAY drop IHAVE). The MODE READER command MUST NOT be issued more than once or after any security or privacy commands.
Multi-line data blocks use dot-stuffing: any line beginning with '.' (%x2E) MUST have an additional '.' prepended. The block is terminated by a line containing only '.' followed by CRLF (%x2E.0D.0A). NUL, bare LF, and bare CR MUST NOT appear in the block.
NNTP command lines consist of a keyword optionally followed by arguments, terminated by CRLF. Command lines MUST NOT exceed 512 octets (including CRLF); arguments MUST NOT exceed 497 octets. Multiple commands MUST NOT appear on the same line.