diff options
| author | Matěj Cepl <mcepl@cepl.eu> | 2023-07-23 17:22:55 +0200 |
|---|---|---|
| committer | Matěj Cepl <mcepl@cepl.eu> | 2023-07-23 17:22:55 +0200 |
| commit | 92d2dc5587e2383fd48a3b2dafda4d96cac56b2a (patch) | |
| tree | 859bd9e9163842bdee36a4006acc02267b249a42 /docs | |
| parent | aaccabcd76f6726563ec5207b5e3eb466a46cee9 (diff) | |
| download | pygn-92d2dc5587e2383fd48a3b2dafda4d96cac56b2a.tar.gz | |
Remove RFCs from the repository
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/RFC 1036 - Standard for interchange of USENET messages.html | 1137 | ||||
| -rw-r--r-- | docs/RFC 2821 - Simple Mail Transfer Protocol.html | 4495 | ||||
| -rw-r--r-- | docs/RFC 3977 - Network News Transfer Protocol (NNTP).html | 7068 |
3 files changed, 0 insertions, 12700 deletions
diff --git a/docs/RFC 1036 - Standard for interchange of USENET messages.html b/docs/RFC 1036 - Standard for interchange of USENET messages.html deleted file mode 100644 index a4b68af..0000000 --- a/docs/RFC 1036 - Standard for interchange of USENET messages.html +++ /dev/null @@ -1,1137 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> -<meta http-equiv="content-type" content="text/html; charset=UTF-8"> - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - <meta name="robots" content="index,follow"> - <meta name="creator" content="rfcmarkup version 1.109"> - <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> -<meta name="DC.Relation.Replaces" content="rfc850"> -<meta name="DC.Identifier" content="urn:ietf:rfc:1036"> -<meta name="DC.Date.Issued" content="December, 1987"> -<meta name="DC.Creator" content="Adams, R."> -<meta name="DC.Creator" content="Horton, M.R."> -<meta name="DC.Description.Abstract" content="This RFC defines the standard format for the interchange of network -News messages among USENET hosts. It updates and replaces RFC-850, -reflecting version B2.11 of the News program. This memo is distributed -as an RFC to make this information easily accessible to the Internet -community. It does not specify an Internet standard."> -<meta name="DC.Title" content="Standard for interchange of USENET messages"> - - <link rel="icon" href="index_files/rfc.png" type="image/png"> - <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> - <title>RFC 1036 - Standard for interchange of USENET messages</title> - - - <style type="text/css"><!--
-/* Effective stylesheet produced by snapshot save */
-body { margin: 0px 8px; font-size: 1em; }
-h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
-pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
-.pre { white-space: pre; font-family: monospace; }
-.newpage { page-break-before: always; }
-.invisible { text-decoration: none; color: white; }
-a.selflink { color: black; text-decoration: none; }
-@media print {
- body { font-family: monospace; font-size: 10.5pt; }
- h1, h2, h3, h4, h5, h6 { font-size: 1em; }
- a:link, a:visited { color: inherit; text-decoration: none; }
- .noprint { display: none; }
-}
-@media screen {
- .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
- .docinfo { background-color: rgb(238, 238, 238); }
- .top { border-top: 7px solid rgb(238, 238, 238); }
- .bgbrown { background-color: rgb(136, 68, 0); }
- .legend { font-size: 90%; }
-}
---></style> - <!--[if IE]> - <style> - body { - font-size: 13px; - margin: 10px 10px; - } - </style> - <![endif]--> - - <script type="text/javascript"><!--
-/* Script removed by snapshot save */
---></script> -</head> -<body onload=""> - <div style="height: 13px;"> - <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgbrown" title="Click for colour legend."> </div> - <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> - </div> - </div> -<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc1036.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc1036" title="PDF version of this document">pdf</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=1036">Errata</a>] </span><br> -<span class="pre noprint docinfo"> </span><br> -<span class="pre noprint docinfo">Obsoleted by: <a href="https://tools.ietf.org/html/rfc5536">5536</a>, <a href="https://tools.ietf.org/html/rfc5537">5537</a> </span><br> -<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br> -<pre>Network Working Group M. Horton -Request for Comments: 1036 AT&T Bell Laboratories -Obsoletes: <a href="https://tools.ietf.org/html/rfc850">RFC-850</a> R. Adams - Center for Seismic Studies - December 1987 - - - <span class="h1"><h1>Standard for Interchange of USENET Messages</h1></span> - - - -STATUS OF THIS MEMO - - This document defines the standard format for the interchange of - network News messages among USENET hosts. It updates and replaces - <a href="https://tools.ietf.org/html/rfc850">RFC-850</a>, reflecting version B2.11 of the News program. This memo is - disributed as an RFC to make this information easily accessible to - the Internet community. It does not specify an Internet standard. - Distribution of this memo is unlimited. - -<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> - - This document defines the standard format for the interchange of - network News messages among USENET hosts. It describes the format - for messages themselves and gives partial standards for transmission - of news. The news transmission is not entirely in order to give a - good deal of flexibility to the hosts to choose transmission - hardware and software, to batch news, and so on. - - There are five sections to this document. Section two defines the - format. Section three defines the valid control messages. Section - four specifies some valid transmission methods. Section five - describes the overall news propagation algorithm. - -<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Message Format</h2></span> - - The primary consideration in choosing a message format is that it - fit in with existing tools as well as possible. Existing tools - include implementations of both mail and news. (The notesfiles - system from the University of Illinois is considered a news - implementation.) A standard format for mail messages has existed - for many years on the Internet, and this format meets most of the - needs of USENET. Since the Internet format is extensible, - extensions to meet the additional needs of USENET are easily made - within the Internet standard. Therefore, the rule is adopted that - all USENET news messages must be formatted as valid Internet mail - messages, according to the Internet standard <a href="https://tools.ietf.org/html/rfc822">RFC-822</a>. The USENET - News standard is more restrictive than the Internet standard, - - - -<span class="grey">Horton & Adams [Page 1]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - placing additional requirements on each message and forbidding use - of certain Internet features. However, it should always be possible - to use a tool expecting an Internet message to process a news - message. In any situation where this standard conflicts with the - Internet standard, <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> should be considered correct and this - standard in error. - - Here is an example USENET message to illustrate the fields. - - From: jerry@eagle.ATT.COM (Jerry Schwarz) - Path: cbosgd!mhuxj!mhuxt!eagle!jerry - Newsgroups: news.announce - Subject: Usenet Etiquette -- Please Read - Message-ID: <642@eagle.ATT.COM> - Date: Fri, 19 Nov 82 16:14:55 GMT - Followup-To: news.misc - Expires: Sat, 1 Jan 83 00:00:00 -0500 - Organization: AT&T Bell Laboratories, Murray Hill - - The body of the message comes here, after a blank line. - - Here is an example of a message in the old format (before the - existence of this standard). It is recommended that - implementations also accept messages in this format to ease upward - conversion. - - From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) - Newsgroups: news.misc - Title: Usenet Etiquette -- Please Read - Article-I.D.: eagle.642 - Posted: Fri Nov 19 16:14:55 1982 - Received: Fri Nov 19 16:59:30 1982 - Expires: Mon Jan 1 00:00:00 1990 - - The body of the message comes here, after a blank line. - - Some news systems transmit news in the A format, which looks like - this: - - Aeagle.642 - news.misc - cbosgd!mhuxj!mhuxt!eagle!jerry - Fri Nov 19 16:14:55 1982 - Usenet Etiquette - Please Read - The body of the message comes here, with no blank line. - - A standard USENET message consists of several header lines, followed - by a blank line, followed by the body of the message. Each header - - - -<span class="grey">Horton & Adams [Page 2]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - line consist of a keyword, a colon, a blank, and some additional - information. This is a subset of the Internet standard, simplified - to allow simpler software to handle it. The "From" line may - optionally include a full name, in the format above, or use the - Internet angle bracket syntax. To keep the implementations simple, - other formats (for example, with part of the machine address after - the close parenthesis) are not allowed. The Internet convention of - continuation header lines (beginning with a blank or tab) is - allowed. - - Certain headers are required, and certain other headers are - optional. Any unrecognized headers are allowed, and will be passed - through unchanged. The required header lines are "From", "Date", - "Newsgroups", "Subject", "Message-ID", and "Path". The optional - header lines are "Followup-To", "Expires", "Reply-To", "Sender", - "References", "Control", "Distribution", "Keywords", "Summary", - "Approved", "Lines", "Xref", and "Organization". Each of these - header lines will be described below. - -<span class="h3"><h3><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a>. Required Header lines</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-2.1.1" href="#section-2.1.1">2.1.1</a>. From</h4></span> - - The "From" line contains the electronic mailing address of the - person who sent the message, in the Internet syntax. It may - optionally also contain the full name of the person, in parentheses, - after the electronic address. The electronic address is the same as - the entity responsible for originating the message, unless the - "Sender" header is present, in which case the "From" header might - not be verified. Note that in all host and domain names, upper and - lower case are considered the same, thus "mark@cbosgd.ATT.COM", - "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent. - User names may or may not be case sensitive, for example, - "Billy@cbosgd.ATT.COM" might be different from - "BillY@cbosgd.ATT.COM". Programs should avoid changing the case of - electronic addresses when forwarding news or mail. - - <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> specifies that all text in parentheses is to be interpreted - as a comment. It is common in Internet mail to place the full name - of the user in a comment at the end of the "From" line. This - standard specifies a more rigid syntax. The full name is not - considered a comment, but an optional part of the header line. - Either the full name is omitted, or it appears in parentheses after - the electronic address of the person posting the message, or it - appears before an electronic address which is enclosed in angle - brackets. Thus, the three permissible forms are: - - - - - -<span class="grey">Horton & Adams [Page 3]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - From: mark@cbosgd.ATT.COM - From: mark@cbosgd.ATT.COM (Mark Horton) - From: Mark Horton <mark@cbosgd.ATT.COM> - - Full names may contain any printing ASCII characters from space - through tilde, except that they may not contain "(" (left - parenthesis), ")" (right parenthesis), "<" (left angle bracket), or - ">" (right angle bracket). Additional restrictions may be placed on - full names by the mail standard, in particular, the characters "," - (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "=" - (equal), and ";" (semicolon) are inadvisable in full names. - -<span class="h4"><h4><a class="selflink" name="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Date</h4></span> - - The "Date" line (formerly "Posted") is the date that the message was - originally posted to the network. Its format must be acceptable - both in <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> and to the getdate(3) routine that is provided with - the Usenet software. This date remains unchanged as the message is - propagated throughout the network. One format that is acceptable to - both is: - - Wdy, DD Mon YY HH:MM:SS TIMEZONE - - Several examples of valid dates appear in the sample message above. - Note in particular that ctime(3) format: - - Wdy Mon DD HH:MM:SS YYYY - - is not acceptable because it is not a valid <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> 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 <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> should be - supported. It is recommended that times in message headers be - transmitted in GMT and displayed in the local time zone. - -<span class="h4"><h4><a class="selflink" name="section-2.1.3" href="#section-2.1.3">2.1.3</a>. Newsgroups</h4></span> - - 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. - - - - - -<span class="grey">Horton & Adams [Page 4]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - 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. - -<span class="h4"><h4><a class="selflink" name="section-2.1.4" href="#section-2.1.4">2.1.4</a>. Subject</h4></span> - - 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. - -<span class="h4"><h4><a class="selflink" name="section-2.1.5" href="#section-2.1.5">2.1.5</a>. Message-ID</h4></span> - - 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 <a href="https://tools.ietf.org/html/rfc822">RFC-822</a>, 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). - - - -<span class="grey">Horton & Adams [Page 5]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - 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 - characters (e.g., blank and tab) are not allowed in a Message-ID. - Slashes ("/") are strongly discouraged. All characters between the - angle brackets must be printing ASCII characters. - -<span class="h4"><h4><a class="selflink" name="section-2.1.6" href="#section-2.1.6">2.1.6</a>. Path</h4></span> - - This line shows the path the message took to reach the current - system. When a system forwards the message, it should add its own - name to the list of systems in the "Path" line. The names may be - separated by any punctuation character or characters (except "." - which is considered part of the hostname). Thus, the following are - valid entries: - - cbosgd!mhuxj!mhuxt - cbosgd, mhuxj, mhuxt - @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM - teklabs, zehntel, sri-unix@cca!decvax - - (The latter path indicates a message that passed through decvax, - cca, sri-unix, zehntel, and teklabs, in that order.) Additional - names should be added from the left. For example, the most recently - added name in the fourth example was teklabs. Letters, digits, - periods and hyphens are considered part of host names; other - punctuation, including blanks, are considered separators. - - Normally, the rightmost name will be the name of the originating - system. However, it is also permissible to include an extra entry - on the right, which is the name of the sender. This is for upward - compatibility with older systems. - - The "Path" line is not used for replies, and should not be taken as - a mailing address. It is intended to show the route the message - traveled to reach the local host. There are several uses for this - information. One is to monitor USENET routing for performance - - - -<span class="grey">Horton & Adams [Page 6]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - reasons. Another is to establish a path to reach new hosts. - Perhaps the most important use is to cut down on redundant USENET - traffic by failing to forward a message to a host that is known to - have already received it. In particular, when host A sends a - message to host B, the "Path" line includes A, so that host B will - not immediately send the message back to host A. The name each host - uses to identify itself should be the same as the name by which its - neighbors know it, in order to make this optimization possible. - - A host adds its own name to the front of a path when it receives a - message from another host. Thus, if a message with path "A!X!Y!Z" - is passed from host A to host B, B will add its own name to the path - when it receives the message from A, e.g., "B!A!X!Y!Z". If B then - passes the message on to C, the message sent to C will contain the - path "B!A!X!Y!Z", and when C receives it, C will change it to - "C!B!A!X!Y!Z". - - Special upward compatibility note: Since the "From", "Sender", and - "Reply-To" lines are in Internet format, and since many USENET hosts - do not yet have mailers capable of understanding Internet format, it - would break the reply capability to completely sever the connection - between the "Path" header and the reply function. It is recognized - that the path is not always a valid reply string in older - implementations, and no requirement to fix this problem is placed on - implementations. However, the existing convention of placing the - host name and an "!" at the front of the path, and of starting the - path with the host name, an "!", and the user name, should be - maintained when possible. - -<span class="h3"><h3><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a>. Optional Headers</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Reply-To</h4></span> - - This line has the same format as "From". If present, mailed replies - to the author should be sent to the name given here. Otherwise, - replies are mailed to the name on the "From" line. (This does not - prevent additional copies from being sent to recipients named by the - replier, or on "To" or "Cc" lines.) The full name may be optionally - given, in parentheses, as in the "From" line. - -<span class="h4"><h4><a class="selflink" name="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Sender</h4></span> - - This field is present only if the submitter manually enters a "From" - line. It is intended to record the entity responsible for - submitting the message to the network. It should be verified by the - software at the submitting host. - - - - - -<span class="grey">Horton & Adams [Page 7]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - For example, if John Smith is visiting CCA and wishes to post a - message to the network, using friend Sarah Jones' account, the - message might read: - - From: smith@ucbvax.Berkeley.EDU (John Smith) - Sender: jones@cca.COM (Sarah Jones) - - If a gateway program enters a mail message into the network at host - unix.SRI.COM, the lines might read: - - From: John.Doe@A.CS.CMU.EDU - Sender: network@unix.SRI.COM - - The primary purpose of this field is to be able to track down - messages to determine how they were entered into the network. The - full name may be optionally given, in parentheses, as in the "From" - line. - -<span class="h4"><h4><a class="selflink" name="section-2.2.3" href="#section-2.2.3">2.2.3</a>. Followup-To</h4></span> - - This line has the same format as "Newsgroups". If present, follow- - up messages are to be posted to the newsgroup or newsgroups listed - here. If this line is not present, follow-ups are posted to the - newsgroup or newsgroups listed in the "Newsgroups" line. - - If the keyword poster is present, follow-up messages are not - permitted. The message should be mailed to the submitter of the - message via mail. - -<span class="h4"><h4><a class="selflink" name="section-2.2.4" href="#section-2.2.4">2.2.4</a>. Expires</h4></span> - - This line, if present, is in a legal USENET date format. It - specifies a suggested expiration date for the message. If not - present, the local default expiration date is used. This field is - intended to be used to clean up messages with a limited usefulness, - or to keep important messages around for longer than usual. For - example, a message announcing an upcoming seminar could have an - expiration date the day after the seminar, since the message is not - useful after the seminar is over. Since local hosts have local - policies for expiration of news (depending on available disk space, - for instance), users are discouraged from providing expiration dates - for messages unless there is a natural expiration date associated - with the topic. System software should almost never provide a - default "Expires" line. Leave it out and allow local policies to be - used unless there is a good reason not to. - - - - - - -<span class="grey">Horton & Adams [Page 8]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - -<span class="h4"><h4><a class="selflink" name="section-2.2.5" href="#section-2.2.5">2.2.5</a>. References</h4></span> - - This field lists the Message-ID's of any messages prompting the - submission of this message. It is required for all follow-up - messages, and forbidden when a new subject is raised. - Implementations should provide a follow-up command, which allows a - user to post a follow-up message. This command should generate a - "Subject" line which is the same as the original message, except - that if the original subject does not begin with "Re:" or "re:", the - four characters "Re:" are inserted before the subject. If there is - no "References" line on the original header, the "References" line - should contain the Message-ID of the original message (including the - angle brackets). If the original message does have a "References" - line, the follow-up message should have a "References" line - containing the text of the original "References" line, a blank, and - the Message-ID of the original message. - - The purpose of the "References" header is to allow messages to be - grouped into conversations by the user interface program. This - allows conversations within a newsgroup to be kept together, and - potentially users might shut off entire conversations without - unsubscribing to a newsgroup. User interfaces need not make use of - this header, but all automatically generated follow-ups should - generate the "References" line for the benefit of systems that do - use it, and manually generated follow-ups (e.g., typed in well after - the original message has been printed by the machine) should be - encouraged to include them as well. - - It is permissible to not include the entire previous "References" - line if it is too long. An attempt should be made to include a - reasonable number of backwards references. - -<span class="h4"><h4><a class="selflink" name="section-2.2.6" href="#section-2.2.6">2.2.6</a>. Control</h4></span> - - If a message contains a "Control" line, the message is a control - message. Control messages are used for communication among USENET - host machines, not to be read by users. Control messages are - distributed by the same newsgroup mechanism as ordinary messages. - The body of the "Control" header line is the message to the host. - - For upward compatibility, messages that match the newsgroup pattern - "all.all.ctl" should also be interpreted as control messages. If no - "Control" header is present on such messages, the subject is used as - the control message. However, messages on newsgroups matching this - pattern do not conform to this standard. - - - - - - -<span class="grey">Horton & Adams [Page 9]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - Also for upward compatibility, if the first 4 characters of the - "Subject:" line are "cmsg", the rest of the "Subject:" line should - be interpreted as a control message. - -<span class="h4"><h4><a class="selflink" name="section-2.2.7" href="#section-2.2.7">2.2.7</a>. Distribution</h4></span> - - This line is used to alter the distribution scope of the message. - It is a comma separated list similar to the "Newsgroups" line. User - subscriptions are still controlled by "Newsgroups", but the message - is sent to all systems subscribing to the newsgroups on the - "Distribution" line in addition to the "Newsgroups" line. For the - message to be transmitted, the receiving site must normally receive - one of the specified newsgroups AND must receive one of the - specified distributions. Thus, a message concerning a car for sale - in New Jersey might have headers including: - - Newsgroups: rec.auto,misc.forsale - Distribution: nj,ny - - so that it would only go to persons subscribing to rec.auto or misc. - for sale within New Jersey or New York. The intent of this header - is to restrict the distribution of a newsgroup further, not to - increase it. A local newsgroup, such as nj.crazy-eddie, will - probably not be propagated by hosts outside New Jersey that do not - show such a newsgroup as valid. A follow-up message should default - to the same "Distribution" line as the original message, but the - user can change it to a more limited one, or escalate the - distribution if it was originally restricted and a more widely - distributed reply is appropriate. - -<span class="h4"><h4><a class="selflink" name="section-2.2.8" href="#section-2.2.8">2.2.8</a>. Organization</h4></span> - - The text of this line is a short phrase describing the organization - to which the sender belongs, or to which the machine belongs. The - intent of this line is to help identify the person posting the - message, since host names are often cryptic enough to make it hard - to recognize the organization by the electronic address. - -<span class="h4"><h4><a class="selflink" name="section-2.2.9" href="#section-2.2.9">2.2.9</a>. Keywords</h4></span> - - A few well-selected keywords identifying the message should be on - this line. This is used as an aid in determining if this message is - interesting to the reader. - -<span class="h4"><h4><a class="selflink" name="section-2.2.10" href="#section-2.2.10">2.2.10</a>. Summary</h4></span> - - This line should contain a brief summary of the message. It is - usually used as part of a follow-up to another message. Again, it - - - -<span class="grey">Horton & Adams [Page 10]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - is very useful to the reader in determining whether to read the - message. - -<span class="h4"><h4><a class="selflink" name="section-2.2.11" href="#section-2.2.11">2.2.11</a>. Approved</h4></span> - - This line is required for any message posted to a moderated - newsgroup. It should be added by the moderator and consist of his - mail address. It is also required with certain control messages. - -<span class="h4"><h4><a class="selflink" name="section-2.2.12" href="#section-2.2.12">2.2.12</a>. Lines</h4></span> - - This contains a count of the number of lines in the body of the - message. - -<span class="h4"><h4><a class="selflink" name="section-2.2.13" href="#section-2.2.13">2.2.13</a>. Xref</h4></span> - - This line contains the name of the host (with domains omitted) and a - white space separated list of colon-separated pairs of newsgroup - names and message numbers. These are the newsgroups listed in the - "Newsgroups" line and the corresponding message numbers from the - spool directory. - - This is only of value to the local system, so it should not be - transmitted. For example, in: - - Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid - From: reid@decwrl.DEC.COM (Brian Reid) - Newsgroups: news.lists,news.groups - Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86 - Message-ID: <5658@decwrl.DEC.COM> - Date: 1 Oct 86 11:26:15 GMT - Organization: DEC Western Research Laboratory - Lines: 441 - Approved: reid@decwrl.UUCP - Xref: seismo news.lists:461 news.groups:6378 - - the "Xref" line shows that the message is message number 461 in the - newsgroup news.lists, and message number 6378 in the newsgroup - news.groups, on host seismo. This information may be used by - certain user interfaces. - -<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. Control Messages</h2></span> - - This section lists the control messages currently defined. The body - of the "Control" header line is the control message. Messages are a - sequence of zero or more words, separated by white space (blanks or - tabs). The first word is the name of the control message, remaining - words are parameters to the message. The remainder of the header - - - -<span class="grey">Horton & Adams [Page 11]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - and the body of the message are also potential parameters; for - example, the "From" line might suggest an address to which a - response is to be mailed. - - Implementors and administrators may choose to allow control messages - to be carried out automatically, or to queue them for annual - processing. However, manually processed messages should be dealt - with promptly. - - Failed control messages should NOT be mailed to the originator of - the message, but to the local "usenet" account. - -<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Cancel</h3></span> - - cancel <Message-ID> - - - If a message with the given Message-ID is present on the local - system, the message is cancelled. This mechanism allows a user to - cancel a message after the message has been distributed over the - network. - - If the system is unable to cancel the message as requested, it - should not forward the cancellation request to its neighbor systems. - - Only the author of the message or the local news administrator is - allowed to send this message. The verified sender of a message is - the "Sender" line, or if no "Sender" line is present, the "From" - line. The verified sender of the cancel message must be the same as - either the "Sender" or "From" field of the original message. A - verified sender in the cancel message is allowed to match an - unverified "From" in the original message. - -<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Ihave/Sendme</h3></span> - - ihave <Message-ID list> [<remotesys>] - sendme <Message-ID list> [<remotesys>] - - This message is part of the ihave/sendme protocol, which allows one - host (say A) to tell another host (B) that a particular message has - been received on A. Suppose that host A receives message - "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to - host B. - - A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to - host B (by posting it to newsgroup to.B). B responds with the - control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup - to.A), if it has not already received the message. Upon receiving - - - -<span class="grey">Horton & Adams [Page 12]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - the sendme message, A sends the message to B. - - This protocol can be used to cut down on redundant traffic between - hosts. It is optional and should be used only if the particular - situation makes it worthwhile. Frequently, the outcome is that, - since most original messages are short, and since there is a high - overhead to start sending a new message with UUCP, it costs as much - to send the ihave as it would cost to send the message itself. - - One possible solution to this overhead problem is to batch requests. - Several Message-ID's may be announced or requested in one message. - If no Message-ID's are listed in the control message, the body of - the message should be scanned for Message-ID's, one per line. - -<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Newgroup</h3></span> - - newgroup <groupname> [moderated] - - This control message creates a new newsgroup with the given name. - Since no messages may be posted or forwarded until a newsgroup is - created, this message is required before a newsgroup can be used. - The body of the message is expected to be a short paragraph - describing the intended use of the newsgroup. - - If the second argument is present and it is the keyword moderated, - the group should be created moderated instead of the default of - unmoderated. The newgroup message should be ignored unless there is - an "Approved" line in the same message header. - -<span class="h3"><h3><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Rmgroup</h3></span> - - rmgroup <groupname> - - This message removes a newsgroup with the given name. Since the - newsgroup is removed from every host on the network, this command - should be used carefully by a responsible administrator. The - rmgroup message should be ignored unless there is an "Approved:" - line in the same message header. - - - - - - - - - - - - - -<span class="grey">Horton & Adams [Page 13]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - -<span class="h3"><h3><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Sendsys</h3></span> -<span class="h3"><h3> sendsys (no arguments)</h3></span> - - The sys file, listing all neighbors and the newsgroups to be sent to - each neighbor, will be mailed to the author of the control message - ("Reply-To", if present, otherwise "From"). This information is - considered public information, and it is a requirement of membership - in USENET that this information be provided on request, either - automatically in response to this control message, or manually, by - mailing the requested information to the author of the message. - This information is used to keep the map of USENET up to date, and - to determine where netnews is sent. - - The format of the file mailed back to the author should be the same - as that of the sys file. This format has one line per neighboring - host (plus one line for the local host), containing four colon - separated fields. The first field has the host name of the - neighbor, the second field has a newsgroup pattern describing the - newsgroups sent to the neighbor. The third and fourth fields are - not defined by this standard. The sys file is not the same as the - UUCP L.sys file. A sample response is: - - From: cbosgd!mark (Mark Horton) - Date: Sun, 27 Mar 83 20:39:37 -0500 - Subject: response to your sendsys request - To: mark@cbosgd.ATT.COM - - Responding-System: cbosgd.ATT.COM - cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to, - test - ucbvax:world,comp,to.ucbvax:L: - cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews - /cbosg - cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb - sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews - /sescent - npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois - mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi - -<span class="h3"><h3><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a>. Version</h3></span> - - version (no arguments) - - The name and version of the software running on the local system is - to be mailed back to the author of the message ("Reply-to" if - present, otherwise "From"). - -<span class="h3"><h3><a class="selflink" name="section-3.7" href="#section-3.7">3.7</a>. Checkgroups</h3></span> - - - -<span class="grey">Horton & Adams [Page 14]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - The message body is a list of "official" newsgroups and their - description, one group per line. They are compared against the list - of active newsgroups on the current host. The names of any obsolete - or new newsgroups are mailed to the user "usenet" and descriptions - of the new newsgroups are added to the help file used when posting - news. - -<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. Transmission Methods</h2></span> - - USENET is not a physical network, but rather a logical network - resting on top of several existing physical networks. These - networks include, but are not limited to, UUCP, the Internet, an - Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET. - What is important is that two neighboring systems on USENET have - some method to get a new message, in the format listed here, from - one system to the other, and once on the receiving system, processed - by the netnews software on that system. (On UNIX systems, this - usually means the rnews program being run with the message on the - standard input. <1>) - - It is not a requirement that USENET hosts have mail systems capable - of understanding the Internet mail syntax, but it is strongly - recommended. Since "From", "Reply-To", and "Sender" lines use the - Internet syntax, replies will be difficult or impossible without an - Internet mailer. A host without an Internet mailer can attempt to - use the "Path" header line for replies, but this field is not - guaranteed to be a working path for replies. In any event, any host - generating or forwarding news messages must have an Internet address - that allows them to receive mail from hosts with Internet mailers, - and they must include their Internet address on their From line. - -<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Remote Execution</h3></span> - - Some networks permit direct remote command execution. On these - networks, news may be forwarded by spooling the rnews command with - the message on the standard input. For example, if the remote - system is called remote, news would be sent over a UUCP link - with the command: - - uux - remote!rnews - - and on a Berknet: - - net -mremote rnews - - - - - - - -<span class="grey">Horton & Adams [Page 15]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - It is important that the message be sent via a reliable mechanism, - normally involving the possibility of spooling, rather than direct - real-time remote execution. This is because, if the remote system - is down, a direct execution command will fail, and the message will - never be delivered. If the message is spooled, it will eventually - be delivered when both systems are up. - -<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Transfer by Mail</h3></span> - - On some systems, direct remote spooled execution is not possible. - However, most systems support electronic mail, and a news message - can be sent as mail. One approach is to send a mail message which - is identical to the news message: the mail headers are the news - headers, and the mail body is the news body. By convention, this - mail is sent to the user newsmail on the remote machine. - - One problem with this method is that it may not be possible to - convince the mail system that the "From" line of the message is - valid, since the mail message was generated by a program on a - system different from the source of the news message. Another - problem is that error messages caused by the mail transmission - would be sent to the originator of the news message, who has no - control over news transmission between two cooperating hosts - and does not know whom to contact. Transmission error messages - should be directed to a responsible contact person on the - sending machine. - - A solution to this problem is to encapsulate the news message into a - mail message, such that the entire message (headers and body) are - part of the body of the mail message. The convention here is that - such mail is sent to user rnews on the remote system. A mail - message body is generated by prepending the letter N to each line of - the news message, and then attaching whatever mail headers are - convenient to generate. The N's are attached to prevent any special - lines in the news message from interfering with mail transmission, - and to prevent any extra lines inserted by the mailer (headers, - blank lines, etc.) from becoming part of the news message. A - program on the receiving machine receives mail to rnews, extracting - the message itself and invoking the rnews program. An example in - this format might look like this: - - - - - - - - - - - -<span class="grey">Horton & Adams [Page 16]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - Date: Mon, 3 Jan 83 08:33:47 MST - From: news@cbosgd.ATT.COM - Subject: network news message - To: rnews@npois.ATT.COM - - NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek - NFrom: derek@sask.UUCP (Derek Andrew) - NNewsgroups: misc.test - NSubject: necessary test - NMessage-ID: <176@sask.UUCP> - NDate: Mon, 3 Jan 83 00:59:15 MST - N - NThis really is a test. If anyone out there more than 6 - Nhops away would kindly confirm this note I would - Nappreciate it. We suspect that our news postings - Nare not getting out into the world. - N - - Using mail solves the spooling problem, since mail must always be - spooled if the destination host is down. However, it adds more - overhead to the transmission process (to encapsulate and extract the - message) and makes it harder for software to give different - priorities to news and mail. - -<span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. Batching</h3></span> - - Since news messages are usually short, and since a large number of - messages are often sent between two hosts in a day, it may make - sense to batch news messages. Several messages can be combined into - one large message, using conventions agreed upon in advance by the - two hosts. One such batching scheme is described here; its use is - highly recommended. - - News messages are combined into a script, separated by a header of - the form: - - - #! rnews 1234 - - where 1234 is the length of the message in bytes. Each such line is - followed by a message containing the given number of bytes. (The - newline at the end of each line of the message is counted as one - byte, for purposes of this count, even if it is stored as <CARRIAGE - RETURN><LINE FEED>.) For example, a batch of message might look - like this: - - - - - - -<span class="grey">Horton & Adams [Page 17]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - #! rnews 239 - From: jerry@eagle.ATT.COM (Jerry Schwarz) - Path: cbosgd!mhuxj!mhuxt!eagle!jerry - Newsgroups: news.announce - Subject: Usenet Etiquette -- Please Read - Message-ID: <642@eagle.ATT.COM> - Date: Fri, 19 Nov 82 16:14:55 EST - Approved: mark@cbosgd.ATT.COM - - Here is an important message about USENET Etiquette. - #! rnews 234 - From: jerry@eagle.ATT.COM (Jerry Schwarz) - Path: cbosgd!mhuxj!mhuxt!eagle!jerry - Newsgroups: news.announce - Subject: Notes on Etiquette message - Message-ID: <643@eagle.ATT.COM> - Date: Fri, 19 Nov 82 17:24:12 EST - Approved: mark@cbosgd.ATT.COM - - There was something I forgot to mention in the last - message. - - Batched news is recognized because the first character in the - message is #. The message is then passed to the unbatcher for - interpretation. - - The second argument (in this example rnews) determines which - batching scheme is being used. Cooperating hosts may use whatever - scheme is appropriate for them. - -<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. The News Propagation Algorithm</h2></span> - - This section describes the overall scheme of USENET and the - algorithm followed by hosts in propagating news to the entire - logical network. Since all hosts are affected by incorrectly - formatted messages and by propagation errors, it is important - for the method to be standardized. - - USENET is a directed graph. Each node in the graph is a host - computer, and each arc in the graph is a transmission path from - one host to another host. Each arc is labeled with a newsgroup - pattern, specifying which newsgroup classes are forwarded along - that link. Most arcs are bidirectional, that is, if host A - sends a class of newsgroups to host B, then host B usually sends - the same class of newsgroups to host A. This bidirectionality - is not, however, required. - - USENET is made up of many subnetworks. Each subnet has a name, such - - - -<span class="grey">Horton & Adams [Page 18]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a> -<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span> - - - as comp or btl. Each subnet is a connected graph, that is, a path - exists from every node to every other node in the subnet. In - addition, the entire graph is (theoretically) connected. (In - practice, some political considerations have caused some hosts to be - unable to post messages reaching the rest of the network.) - - A message is posted on one machine to a list of newsgroups. That - machine accepts it locally, then forwards it to all its neighbors - that are interested in at least one of the newsgroups of the - message. (Site A deems host B to be "interested" in a newsgroup if - the newsgroup matches the pattern on the arc from A to B. This - pattern is stored in a file on the A machine.) The hosts receiving - the incoming message examine it to make sure they really want the - message, accept it locally, and then in turn forward the message to - all their interested neighbors. This process continues until the - entire network has seen the message. - - An important part of the algorithm is the prevention of loops. The - above process would cause a message to loop along a cycle forever. - In particular, when host A sends a message to host B, host B will - send it back to host A, which will send it to host B, and so on. - One solution to this is the history mechanism. Each host keeps - track of all messages it has seen (by their Message-ID) and - whenever a message comes in that it has already seen, the incoming - message is discarded immediately. This solution is sufficient to - prevent loops, but additional optimizations can be made to avoid - sending messages to hosts that will simply throw them away. - - One optimization is that a message should never be sent to a machine - listed in the "Path" line of the header. When a machine name is - in the "Path" line, the message is known to have passed through the - machine. Another optimization is that, if the message originated - on host A, then host A has already seen the message. Thus, if a - message is posted to newsgroup misc.misc, it will match the pattern - misc.all (where all is a metasymbol that matches any string), and - will be forwarded to all hosts that subscribe to misc.all (as - determined by what their neighbors send them). These hosts make up - the misc subnetwork. A message posted to btl.general will reach all - hosts receiving btl.all, but will not reach hosts that do not get - btl.all. In effect, the messages reaches the btl subnetwork. A - messages posted to newsgroups misc.misc,btl.general will reach all - hosts subscribing to either of the two classes. - -Notes - - <1> UNIX is a registered trademark of AT&T. - - - - - -Horton & Adams [Page 19] - -</pre><br> -<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.109, available from -<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> -</small></small></span> - -</body></html>
\ No newline at end of file diff --git a/docs/RFC 2821 - Simple Mail Transfer Protocol.html b/docs/RFC 2821 - Simple Mail Transfer Protocol.html deleted file mode 100644 index 19f2bbc..0000000 --- a/docs/RFC 2821 - Simple Mail Transfer Protocol.html +++ /dev/null @@ -1,4495 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> -<meta http-equiv="content-type" content="text/html; charset=UTF-8"> - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - <meta name="robots" content="index,follow"> - <meta name="creator" content="rfcmarkup version 1.109"> - <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> -<meta name="DC.Relation.Replaces" content="rfc821"> -<meta name="DC.Relation.Replaces" content="rfc974"> -<meta name="DC.Relation.Replaces" content="rfc1869"> -<meta name="DC.Identifier" content="urn:ietf:rfc:2821"> -<meta name="DC.Date.Issued" content="April, 2001"> -<meta name="DC.Creator" content="John C. Klensin <klensin@research.att.com>"> -<meta name="DC.Description.Abstract" content="This document is a self-contained specification of the basic protocol -for the Internet electronic mail transport. [STANDARDS-TRACK]"> -<meta name="DC.Title" content="Simple Mail Transfer Protocol"> - - <link rel="icon" href="index_files/rfc.png" type="image/png"> - <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> - <title>RFC 2821 - Simple Mail Transfer Protocol</title> - - - <style type="text/css"><!--
-/* Effective stylesheet produced by snapshot save */
-body { margin: 0px 8px; font-size: 1em; }
-h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
-pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
-.pre { white-space: pre; font-family: monospace; }
-.newpage { page-break-before: always; }
-.invisible { text-decoration: none; color: white; }
-a.selflink { color: black; text-decoration: none; }
-@media print {
- body { font-family: monospace; font-size: 10.5pt; }
- h1, h2, h3, h4, h5, h6 { font-size: 1em; }
- a:link, a:visited { color: inherit; text-decoration: none; }
- .noprint { display: none; }
-}
-@media screen {
- .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
- .docinfo { background-color: rgb(238, 238, 238); }
- .top { border-top: 7px solid rgb(238, 238, 238); }
- .bgbrown { background-color: rgb(136, 68, 0); }
- .legend { font-size: 90%; }
-}
---></style> - <!--[if IE]> - <style> - body { - font-size: 13px; - margin: 10px 10px; - } - </style> - <![endif]--> - - <script type="text/javascript"><!--
-/* Script removed by snapshot save */
---></script> -</head> -<body onload=""> - <div style="height: 13px;"> - <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgbrown" title="Click for colour legend."> </div> - <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> - </div> - </div> -<span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc2821.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc2821" title="PDF version of this document">pdf</a>] [<a href="http://tools.ietf.org/html/draft-ietf-drums-smtpupd" title="draft-ietf-drums-smtpupd">draft-ietf-drums-...</a>] [<a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc2821" title="Inline diff (wdiff)">Diff1</a>] [<a href="http://tools.ietf.org/rfcdiff?url2=rfc2821" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=2821">Errata</a>] </span><br> -<span class="pre noprint docinfo"> </span><br> -<span class="pre noprint docinfo">Obsoleted by: <a href="http://tools.ietf.org/html/rfc5321">5321</a> PROPOSED STANDARD</span><br> -<span class="pre noprint docinfo">Updated by: <a href="http://tools.ietf.org/html/rfc5336">5336</a> <span style="color: #C00;">Errata Exist</span></span><br> -<pre>Network Working Group J. Klensin, Editor -Request for Comments: 2821 AT&T Laboratories -Obsoletes: <a href="http://tools.ietf.org/html/rfc821">821</a>, <a href="http://tools.ietf.org/html/rfc974">974</a>, <a href="http://tools.ietf.org/html/rfc1869">1869</a> April 2001 -Updates: <a href="http://tools.ietf.org/html/rfc1123">1123</a> -Category: Standards Track - - - <span class="h1"><h1>Simple Mail Transfer Protocol</h1></span> - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document is a self-contained specification of the basic protocol - for the Internet electronic mail transport. It consolidates, updates - and clarifies, but doesn't add new or change existing functionality - of the following: - - - the original SMTP (Simple Mail Transfer Protocol) specification of - <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> [<a href="#ref-30" title='"Simple Mail Transfer Protocol"'>30</a>], - - - domain name system requirements and implications for mail - transport from <a href="http://tools.ietf.org/html/rfc1035">RFC 1035</a> [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>] and <a href="http://tools.ietf.org/html/rfc974">RFC 974</a> [<a href="#ref-27" title='"Mail routing and the domain system"'>27</a>], - - - the clarifications and applicability statements in <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a> [<a href="#ref-2" title='"Requirements for Internet hosts - application and support"'>2</a>], - and - - - material drawn from the SMTP Extension mechanisms [<a href="#ref-19" title='"SMTP Service Extensions"'>19</a>]. - - It obsoletes <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>, <a href="http://tools.ietf.org/html/rfc974">RFC 974</a>, and updates <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a> (replaces the - mail transport materials of <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a>). However, <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> specifies - some features that were not in significant use in the Internet by the - mid-1990s and (in appendices) some additional transport models. - Those sections are omitted here in the interest of clarity and - brevity; readers needing them should refer to <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>. - - - - - - -<span class="grey">Klensin Standards Track [Page 1]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - It also includes some additional material from <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a> that required - amplification. This material has been identified in multiple ways, - mostly by tracking flaming on various lists and newsgroups and - problems of unusual readings or interpretations that have appeared as - the SMTP extensions have been deployed. Where this specification - moves beyond consolidation and actually differs from earlier - documents, it supersedes them technically as well as textually. - - Although SMTP was designed as a mail transport and delivery protocol, - this specification also contains information that is important to its - use as a 'mail submission' protocol, as recommended for POP [<a href="#ref-3" title='"Post Office Protocol - version 2"'>3</a>, <a href="#ref-26" title='"Post Office Protocol - Version 3"'>26</a>] - and IMAP [<a href="#ref-6" title='"Internet Message Access Protocol - Version 4"'>6</a>]. Additional submission issues are discussed in <a href="http://tools.ietf.org/html/rfc2476">RFC 2476</a> - [<a href="#ref-15" title='"Message Submission"'>15</a>]. - - <a href="#section-2.3">Section 2.3</a> provides definitions of terms specific to this document. - Except when the historical terminology is necessary for clarity, this - document uses the current 'client' and 'server' terminology to - identify the sending and receiving SMTP processes, respectively. - - A companion document [<a href="#ref-32" title='"Internet Message Format"'>32</a>] discusses message headers, message bodies - and formats and structures for them, and their relationship. - -Table of Contents - - <a href="#section-1">1</a>. Introduction .................................................. <a href="#page-4">4</a> - <a href="#section-2">2</a>. The SMTP Model ................................................ <a href="#page-5">5</a> - <a href="#section-2.1">2.1</a> Basic Structure .............................................. <a href="#page-5">5</a> - <a href="#section-2.2">2.2</a> The Extension Model .......................................... <a href="#page-7">7</a> - <a href="#section-2.2.1">2.2.1</a> Background ................................................. <a href="#page-7">7</a> - <a href="#section-2.2.2">2.2.2</a> Definition and Registration of Extensions .................. <a href="#page-8">8</a> - <a href="#section-2.3">2.3</a> Terminology .................................................. <a href="#page-9">9</a> - <a href="#section-2.3.1">2.3.1</a> Mail Objects ............................................... <a href="#page-10">10</a> - <a href="#section-2.3.2">2.3.2</a> Senders and Receivers ...................................... <a href="#page-10">10</a> - <a href="#section-2.3.3">2.3.3</a> Mail Agents and Message Stores ............................. <a href="#page-10">10</a> - <a href="#section-2.3.4">2.3.4</a> Host ....................................................... <a href="#page-11">11</a> - <a href="#section-2.3.5">2.3.5</a> Domain ..................................................... <a href="#page-11">11</a> - <a href="#section-2.3.6">2.3.6</a> Buffer and State Table ..................................... <a href="#page-11">11</a> - <a href="#section-2.3.7">2.3.7</a> Lines ...................................................... <a href="#page-12">12</a> - <a href="#section-2.3.8">2.3.8</a> Originator, Delivery, Relay, and Gateway Systems ........... <a href="#page-12">12</a> - <a href="#section-2.3.9">2.3.9</a> Message Content and Mail Data .............................. <a href="#page-13">13</a> - <a href="#section-2.3.10">2.3.10</a> Mailbox and Address ....................................... <a href="#page-13">13</a> - <a href="#section-2.3.11">2.3.11</a> Reply ..................................................... <a href="#page-13">13</a> - <a href="#section-2.4">2.4</a> General Syntax Principles and Transaction Model .............. <a href="#page-13">13</a> - <a href="#section-3">3</a>. The SMTP Procedures: An Overview .............................. <a href="#page-15">15</a> - <a href="#section-3.1">3.1</a> Session Initiation ........................................... <a href="#page-15">15</a> - <a href="#section-3.2">3.2</a> Client Initiation ............................................ <a href="#page-16">16</a> - <a href="#section-3.3">3.3</a> Mail Transactions ............................................ <a href="#page-16">16</a> - <a href="#section-3.4">3.4</a> Forwarding for Address Correction or Updating ................ <a href="#page-19">19</a> - - - -<span class="grey">Klensin Standards Track [Page 2]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - <a href="#section-3.5">3.5</a> Commands for Debugging Addresses ............................. <a href="#page-20">20</a> - <a href="#section-3.5.1">3.5.1</a> Overview ................................................... <a href="#page-20">20</a> - <a href="#section-3.5.2">3.5.2</a> VRFY Normal Response ....................................... <a href="#page-22">22</a> - <a href="#section-3.5.3">3.5.3</a> Meaning of VRFY or EXPN Success Response ................... <a href="#page-22">22</a> - <a href="#section-3.5.4">3.5.4</a> Semantics and Applications of EXPN ......................... <a href="#page-23">23</a> - <a href="#section-3.6">3.6</a> Domains ...................................................... <a href="#page-23">23</a> - <a href="#section-3.7">3.7</a> Relaying ..................................................... <a href="#page-24">24</a> - <a href="#section-3.8">3.8</a> Mail Gatewaying .............................................. <a href="#page-25">25</a> - <a href="#section-3.8.1">3.8.1</a> Header Fields in Gatewaying ................................ <a href="#page-26">26</a> - <a href="#section-3.8.2">3.8.2</a> Received Lines in Gatewaying ............................... <a href="#page-26">26</a> - <a href="#section-3.8.3">3.8.3</a> Addresses in Gatewaying .................................... <a href="#page-26">26</a> - <a href="#section-3.8.4">3.8.4</a> Other Header Fields in Gatewaying .......................... <a href="#page-27">27</a> - <a href="#section-3.8.5">3.8.5</a> Envelopes in Gatewaying .................................... <a href="#page-27">27</a> - <a href="#section-3.9">3.9</a> Terminating Sessions and Connections ......................... <a href="#page-27">27</a> - <a href="#section-3.10">3.10</a> Mailing Lists and Aliases ................................... <a href="#page-28">28</a> - <a href="#section-3.10.1">3.10.1</a> Alias ..................................................... <a href="#page-28">28</a> - <a href="#section-3.10.2">3.10.2</a> List ...................................................... <a href="#page-28">28</a> - <a href="#section-4">4</a>. The SMTP Specifications ....................................... <a href="#page-29">29</a> - <a href="#section-4.1">4.1</a> SMTP Commands ................................................ <a href="#page-29">29</a> - <a href="#section-4.1.1">4.1.1</a> Command Semantics and Syntax ............................... <a href="#page-29">29</a> - <a href="#section-4.1.1.1">4.1.1.1</a> Extended HELLO (EHLO) or HELLO (HELO) ................... <a href="#page-29">29</a> - <a href="#section-4.1.1.2">4.1.1.2</a> MAIL (MAIL) .............................................. <a href="#page-31">31</a> - <a href="#section-4.1.1.3">4.1.1.3</a> RECIPIENT (RCPT) ......................................... <a href="#page-31">31</a> - <a href="#section-4.1.1.4">4.1.1.4</a> DATA (DATA) .............................................. <a href="#page-33">33</a> - <a href="#section-4.1.1.5">4.1.1.5</a> RESET (RSET) ............................................. <a href="#page-34">34</a> - <a href="#section-4.1.1.6">4.1.1.6</a> VERIFY (VRFY) ............................................ <a href="#page-35">35</a> - <a href="#section-4.1.1.7">4.1.1.7</a> EXPAND (EXPN) ............................................ <a href="#page-35">35</a> - <a href="#section-4.1.1.8">4.1.1.8</a> HELP (HELP) .............................................. <a href="#page-35">35</a> - <a href="#section-4.1.1.9">4.1.1.9</a> NOOP (NOOP) .............................................. <a href="#page-35">35</a> - <a href="#section-4.1.1.10">4.1.1.10</a> QUIT (QUIT) ............................................. <a href="#page-36">36</a> - <a href="#section-4.1.2">4.1.2</a> Command Argument Syntax .................................... <a href="#page-36">36</a> - <a href="#section-4.1.3">4.1.3</a> Address Literals ........................................... <a href="#page-38">38</a> - <a href="#section-4.1.4">4.1.4</a> Order of Commands .......................................... <a href="#page-39">39</a> - <a href="#section-4.1.5">4.1.5</a> Private-use Commands ....................................... <a href="#page-40">40</a> - <a href="#section-4.2">4.2</a> SMTP Replies ................................................ <a href="#page-40">40</a> - <a href="#section-4.2.1">4.2.1</a> Reply Code Severities and Theory ........................... <a href="#page-42">42</a> - <a href="#section-4.2.2">4.2.2</a> Reply Codes by Function Groups ............................. <a href="#page-44">44</a> - <a href="#section-4.2.3">4.2.3</a> Reply Codes in Numeric Order .............................. <a href="#page-45">45</a> - <a href="#section-4.2.4">4.2.4</a> Reply Code 502 ............................................. <a href="#page-46">46</a> - <a href="#section-4.2.5">4.2.5</a> Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... <a href="#page-46">46</a> - <a href="#section-4.3">4.3</a> Sequencing of Commands and Replies ........................... <a href="#page-47">47</a> - <a href="#section-4.3.1">4.3.1</a> Sequencing Overview ........................................ <a href="#page-47">47</a> - <a href="#section-4.3.2">4.3.2</a> Command-Reply Sequences .................................... <a href="#page-48">48</a> - <a href="#section-4.4">4.4</a> Trace Information ............................................ <a href="#page-49">49</a> - <a href="#section-4.5">4.5</a> Additional Implementation Issues ............................. <a href="#page-53">53</a> - <a href="#section-4.5.1">4.5.1</a> Minimum Implementation ..................................... <a href="#page-53">53</a> - <a href="#section-4.5.2">4.5.2</a> Transparency ............................................... <a href="#page-53">53</a> - <a href="#section-4.5.3">4.5.3</a> Sizes and Timeouts ......................................... <a href="#page-54">54</a> - - - -<span class="grey">Klensin Standards Track [Page 3]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - <a href="#section-4.5.3.1">4.5.3.1</a> Size limits and minimums ................................. <a href="#page-54">54</a> - <a href="#section-4.5.3.2">4.5.3.2</a> Timeouts ................................................. <a href="#page-56">56</a> - <a href="#section-4.5.4">4.5.4</a> Retry Strategies ........................................... <a href="#page-57">57</a> - <a href="#section-4.5.4.1">4.5.4.1</a> Sending Strategy ......................................... <a href="#page-58">58</a> - <a href="#section-4.5.4.2">4.5.4.2</a> Receiving Strategy ....................................... <a href="#page-59">59</a> - <a href="#section-4.5.5">4.5.5</a> Messages with a null reverse-path .......................... <a href="#page-59">59</a> - <a href="#section-5">5</a>. Address Resolution and Mail Handling .......................... <a href="#page-60">60</a> - <a href="#section-6">6</a>. Problem Detection and Handling ................................ <a href="#page-62">62</a> - <a href="#section-6.1">6.1</a> Reliable Delivery and Replies by Email ....................... <a href="#page-62">62</a> - <a href="#section-6.2">6.2</a> Loop Detection ............................................... <a href="#page-63">63</a> - <a href="#section-6.3">6.3</a> Compensating for Irregularities .............................. <a href="#page-63">63</a> - <a href="#section-7">7</a>. Security Considerations ....................................... <a href="#page-64">64</a> - <a href="#section-7.1">7.1</a> Mail Security and Spoofing ................................... <a href="#page-64">64</a> - <a href="#section-7.2">7.2</a> "Blind" Copies ............................................... <a href="#page-65">65</a> - <a href="#section-7.3">7.3</a> VRFY, EXPN, and Security ..................................... <a href="#page-65">65</a> - <a href="#section-7.4">7.4</a> Information Disclosure in Announcements ...................... <a href="#page-66">66</a> - <a href="#section-7.5">7.5</a> Information Disclosure in Trace Fields ....................... <a href="#page-66">66</a> - <a href="#section-7.6">7.6</a> Information Disclosure in Message Forwarding ................. <a href="#page-67">67</a> - <a href="#section-7.7">7.7</a> Scope of Operation of SMTP Servers ........................... <a href="#page-67">67</a> - <a href="#section-8">8</a>. IANA Considerations ........................................... <a href="#page-67">67</a> - <a href="#section-9">9</a>. References .................................................... <a href="#page-68">68</a> - <a href="#section-10">10</a>. Editor's Address ............................................. <a href="#page-70">70</a> - <a href="#section-11">11</a>. Acknowledgments .............................................. <a href="#page-70">70</a> - Appendices ....................................................... <a href="#page-71">71</a> - <a href="#appendix-A">A</a>. TCP Transport Service ......................................... <a href="#page-71">71</a> - <a href="#appendix-B">B</a>. Generating SMTP Commands from <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> Headers ................. <a href="#page-71">71</a> - <a href="#appendix-C">C</a>. Source Routes ................................................. <a href="#page-72">72</a> - <a href="#appendix-D">D</a>. Scenarios ..................................................... <a href="#page-73">73</a> - <a href="#appendix-E">E</a>. Other Gateway Issues .......................................... <a href="#page-76">76</a> - <a href="#appendix-F">F</a>. Deprecated Features of <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> ................................ <a href="#page-76">76</a> - Full Copyright Statement ......................................... <a href="#page-79">79</a> - -<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> - - The objective of the Simple Mail Transfer Protocol (SMTP) is to - transfer mail reliably and efficiently. - - SMTP is independent of the particular transmission subsystem and - requires only a reliable ordered data stream channel. While this - document specifically discusses transport over TCP, other transports - are possible. Appendices to <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> describe some of them. - - An important feature of SMTP is its capability to transport mail - across networks, usually referred to as "SMTP mail relaying" (see - <a href="#section-3.8">section 3.8</a>). A network consists of the mutually-TCP-accessible - hosts on the public Internet, the mutually-TCP-accessible hosts on a - firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN - environment utilizing a non-TCP transport-level protocol. Using - - - -<span class="grey">Klensin Standards Track [Page 4]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - SMTP, a process can transfer mail to another process on the same - network or to some other network via a relay or gateway process - accessible to both networks. - - In this way, a mail message may pass through a number of intermediate - relay or gateway hosts on its path from sender to ultimate recipient. - The Mail eXchanger mechanisms of the domain name system [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>, <a href="#ref-27" title='"Mail routing and the domain system"'>27</a>] (and - <a href="#section-5">section 5</a> of this document) are used to identify the appropriate - next-hop destination for a message being transported. - -<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. The SMTP Model</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a> Basic Structure</h3></span> - - The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Client- |Commands/Replies| Server- | - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - - When an SMTP client has a message to transmit, it establishes a two- - way transmission channel to an SMTP server. The responsibility of an - SMTP client is to transfer mail messages to one or more SMTP servers, - or report its failure to do so. - - The means by which a mail message is presented to an SMTP client, and - how that client determines the domain name(s) to which mail messages - are to be transferred is a local matter, and is not addressed by this - document. In some cases, the domain name(s) transferred to, or - determined by, an SMTP client will identify the final destination(s) - of the mail message. In other cases, common with SMTP clients - associated with implementations of the POP [<a href="#ref-3" title='"Post Office Protocol - version 2"'>3</a>, <a href="#ref-26" title='"Post Office Protocol - Version 3"'>26</a>] or IMAP [<a href="#ref-6" title='"Internet Message Access Protocol - Version 4"'>6</a>] - protocols, or when the SMTP client is inside an isolated transport - service environment, the domain name determined will identify an - intermediate destination through which all mail messages are to be - relayed. SMTP clients that transfer all traffic, regardless of the - target domain names associated with the individual messages, or that - do not maintain queues for retrying message transmissions that - initially cannot be completed, may otherwise conform to this - specification but are not considered fully-capable. Fully-capable - SMTP implementations, including the relays used by these less capable - - - - -<span class="grey">Klensin Standards Track [Page 5]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - ones, and their destinations, are expected to support all of the - queuing, retrying, and alternate address functions discussed in this - specification. - - The means by which an SMTP client, once it has determined a target - domain name, determines the identity of an SMTP server to which a - copy of a message is to be transferred, and then performs that - transfer, is covered by this document. To effect a mail transfer to - an SMTP server, an SMTP client establishes a two-way transmission - channel to that SMTP server. An SMTP client determines the address - of an appropriate host running an SMTP server by resolving a - destination domain name to either an intermediate Mail eXchanger host - or a final target host. - - An SMTP server may be either the ultimate destination or an - intermediate "relay" (that is, it may assume the role of an SMTP - client after receiving the message) or "gateway" (that is, it may - transport the message further using some protocol other than SMTP). - SMTP commands are generated by the SMTP client and sent to the SMTP - server. SMTP replies are sent from the SMTP server to the SMTP - client in response to the commands. - - In other words, message transfer can occur in a single connection - between the original SMTP-sender and the final SMTP-recipient, or can - occur in a series of hops through intermediary systems. In either - case, a formal handoff of responsibility for the message occurs: the - protocol requires that a server accept responsibility for either - delivering a message or properly reporting the failure to do so. - - Once the transmission channel is established and initial handshaking - completed, the SMTP client normally initiates a mail transaction. - Such a transaction consists of a series of commands to specify the - originator and destination of the mail and transmission of the - message content (including any headers or other structure) itself. - When the same message is sent to multiple recipients, this protocol - encourages the transmission of only one copy of the data for all - recipients at the same destination (or intermediate relay) host. - - The server responds to each command with a reply; replies may - indicate that the command was accepted, that additional commands are - expected, or that a temporary or permanent error condition exists. - Commands specifying the sender or recipients may include server- - permitted SMTP service extension requests as discussed in <a href="#section-2.2">section</a> - <a href="#section-2.2">2.2</a>. The dialog is purposely lock-step, one-at-a-time, although this - can be modified by mutually-agreed extension requests such as command - pipelining [<a href="#ref-13" title='"SMTP Service Extension for Command Pipelining"'>13</a>]. - - - - - -<span class="grey">Klensin Standards Track [Page 6]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - Once a given mail message has been transmitted, the client may either - request that the connection be shut down or may initiate other mail - transactions. In addition, an SMTP client may use a connection to an - SMTP server for ancillary services such as verification of email - addresses or retrieval of mailing list subscriber addresses. - - As suggested above, this protocol provides mechanisms for the - transmission of mail. This transmission normally occurs directly - from the sending user's host to the receiving user's host when the - two hosts are connected to the same transport service. When they are - not connected to the same transport service, transmission occurs via - one or more relay SMTP servers. An intermediate host that acts as - either an SMTP relay or as a gateway into some other transmission - environment is usually selected through the use of the domain name - service (DNS) Mail eXchanger mechanism. - - Usually, intermediate hosts are determined via the DNS MX record, not - by explicit "source" routing (see <a href="#section-5">section 5</a> and appendices C and - F.2). - -<span class="h3"><h3><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a> The Extension Model</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-2.2.1" href="#section-2.2.1">2.2.1</a> Background</h4></span> - - In an effort that started in 1990, approximately a decade after <a href="http://tools.ietf.org/html/rfc821">RFC</a> - <a href="http://tools.ietf.org/html/rfc821">821</a> was completed, the protocol was modified with a "service - extensions" model that permits the client and server to agree to - utilize shared functionality beyond the original SMTP requirements. - The SMTP extension mechanism defines a means whereby an extended SMTP - client and server may recognize each other, and the server can inform - the client as to the service extensions that it supports. - - Contemporary SMTP implementations MUST support the basic extension - mechanisms. For instance, servers MUST support the EHLO command even - if they do not implement any specific extensions and clients SHOULD - preferentially utilize EHLO rather than HELO. (However, for - compatibility with older conforming implementations, SMTP clients and - servers MUST support the original HELO mechanisms as a fallback.) - Unless the different characteristics of HELO must be identified for - interoperability purposes, this document discusses only EHLO. - - SMTP is widely deployed and high-quality implementations have proven - to be very robust. However, the Internet community now considers - some services to be important that were not anticipated when the - protocol was first designed. If support for those services is to be - added, it must be done in a way that permits older implementations to - continue working acceptably. The extension framework consists of: - - - - -<span class="grey">Klensin Standards Track [Page 7]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL and RCPT commands, and - - - optional replacements for commands defined in this protocol, such - as for DATA in non-ASCII transmissions [<a href="#ref-33" title='"SMTP Service Extensions for Transmission of Large and Binary MIME Messages"'>33</a>]. - - SMTP's strength comes primarily from its simplicity. Experience with - many protocols has shown that protocols with few options tend towards - ubiquity, whereas protocols with many options tend towards obscurity. - - Each and every extension, regardless of its benefits, must be - carefully scrutinized with respect to its implementation, deployment, - and interoperability costs. In many cases, the cost of extending the - SMTP service will likely outweigh the benefit. - -<span class="h4"><h4><a class="selflink" name="section-2.2.2" href="#section-2.2.2">2.2.2</a> Definition and Registration of Extensions</h4></span> - - The IANA maintains a registry of SMTP service extensions. A - corresponding EHLO keyword value is associated with each extension. - Each service extension registered with the IANA must be defined in a - formal standards-track or IESG-approved experimental protocol - document. The definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension - (additional verbs will usually be, but are not required to be, the - same as the EHLO keyword value); - - - any new parameters the extension associates with the MAIL or RCPT - verbs; - - - a description of how support for the extension affects the - behavior of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL and/or RCPT, over that specified in - this standard. - - - - - -<span class="grey">Klensin Standards Track [Page 8]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - In addition, any EHLO keyword value starting with an upper or lower - case "X" refers to a local SMTP service extension used exclusively - through bilateral agreement. Keywords beginning with "X" MUST NOT be - used in a registered service extension. Conversely, keyword values - presented in the EHLO response that do not begin with "X" MUST - correspond to a standard, standards-track, or IESG-approved - experimental SMTP service extension registered with IANA. A - conforming server MUST NOT offer non-"X"-prefixed keyword values that - are not described in a registered extension. - - Additional verbs and parameter names are bound by the same rules as - EHLO keywords; specifically, verbs beginning with "X" are local - extensions that may not be registered or standardized. Conversely, - verbs not beginning with "X" must always be registered. - -<span class="h3"><h3><a class="selflink" name="section-2.3" href="#section-2.3">2.3</a> Terminology</h3></span> - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described below. - - 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that - the definition is an absolute requirement of the specification. - - 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the - definition is an absolute prohibition of the specification. - - 3. SHOULD This word, or the adjective "RECOMMENDED", mean that - there may exist valid reasons in particular circumstances to - ignore a particular item, but the full implications must be - understood and carefully weighed before choosing a different - course. - - 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean - that there may exist valid reasons in particular circumstances - when the particular behavior is acceptable or even useful, but the - full implications should be understood and the case carefully - weighed before implementing any behavior described with this - label. - - 5. MAY This word, or the adjective "OPTIONAL", mean that an item is - truly optional. One vendor may choose to include the item because - a particular marketplace requires it or because the vendor feels - that it enhances the product while another vendor may omit the - same item. An implementation which does not include a particular - option MUST be prepared to interoperate with another - implementation which does include the option, though perhaps with - reduced functionality. In the same vein an implementation which - - - -<span class="grey">Klensin Standards Track [Page 9]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - does include a particular option MUST be prepared to interoperate - with another implementation which does not include the option - (except, of course, for the feature the option provides.) - -<span class="h4"><h4><a class="selflink" name="section-2.3.1" href="#section-2.3.1">2.3.1</a> Mail Objects</h4></span> - - SMTP transports a mail object. A mail object contains an envelope - and content. - - The SMTP envelope is sent as a series of SMTP protocol units - (described in <a href="#section-3">section 3</a>). It consists of an originator address (to - which error reports should be directed); one or more recipient - addresses; and optional protocol extension material. Historically, - variations on the recipient address specification command (RCPT TO) - could be used to specify alternate delivery modes, such as immediate - display; those variations have now been deprecated (see <a href="#appendix-F">appendix F</a>, - section F.6). - - The SMTP content is sent in the SMTP DATA protocol unit and has two - parts: the headers and the body. If the content conforms to other - contemporary standards, the headers form a collection of field/value - pairs structured as in the message format specification [<a href="#ref-32" title='"Internet Message Format"'>32</a>]; the - body, if structured, is defined according to MIME [<a href="#ref-12" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>12</a>]. The content - is textual in nature, expressed using the US-ASCII repertoire [<a href="#ref-1" title='"USA Code for Information Interchange"'>1</a>]. - Although SMTP extensions (such as "8BITMIME" [<a href="#ref-20" title='"SMTP Service Extension for 8bit-MIMEtransport"'>20</a>]) may relax this - restriction for the content body, the content headers are always - encoded using the US-ASCII repertoire. A MIME extension [<a href="#ref-23" title='"MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"'>23</a>] defines - an algorithm for representing header values outside the US-ASCII - repertoire, while still encoding them using the US-ASCII repertoire. - -<span class="h4"><h4><a class="selflink" name="section-2.3.2" href="#section-2.3.2">2.3.2</a> Senders and Receivers</h4></span> - - In <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>, the two hosts participating in an SMTP transaction were - described as the "SMTP-sender" and "SMTP-receiver". This document - has been changed to reflect current industry terminology and hence - refers to them as the "SMTP client" (or sometimes just "the client") - and "SMTP server" (or just "the server"), respectively. Since a - given host may act both as server and client in a relay situation, - "receiver" and "sender" terminology is still used where needed for - clarity. - -<span class="h4"><h4><a class="selflink" name="section-2.3.3" href="#section-2.3.3">2.3.3</a> Mail Agents and Message Stores</h4></span> - - Additional mail system terminology became common after <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> was - published and, where convenient, is used in this specification. In - particular, SMTP servers and clients provide a mail transport service - and therefore act as "Mail Transfer Agents" (MTAs). "Mail User - Agents" (MUAs or UAs) are normally thought of as the sources and - - - -<span class="grey">Klensin Standards Track [Page 10]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - targets of mail. At the source, an MUA might collect mail to be - transmitted from a user and hand it off to an MTA; the final - ("delivery") MTA would be thought of as handing the mail off to an - MUA (or at least transferring responsibility to it, e.g., by - depositing the message in a "message store"). However, while these - terms are used with at least the appearance of great precision in - other environments, the implied boundaries between MUAs and MTAs - often do not accurately match common, and conforming, practices with - Internet mail. Hence, the reader should be cautious about inferring - the strong relationships and responsibilities that might be implied - if these terms were used elsewhere. - -<span class="h4"><h4><a class="selflink" name="section-2.3.4" href="#section-2.3.4">2.3.4</a> Host</h4></span> - - For the purposes of this specification, a host is a computer system - attached to the Internet (or, in some cases, to a private TCP/IP - network) and supporting the SMTP protocol. Hosts are known by names - (see "domain"); identifying them by numerical address is discouraged. - -<span class="h4"><h4><a class="selflink" name="section-2.3.5" href="#section-2.3.5">2.3.5</a> Domain</h4></span> - - A domain (or domain name) consists of one or more dot-separated - components. These components ("labels" in DNS terminology [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>]) are - restricted for SMTP purposes to consist of a sequence of letters, - digits, and hyphens drawn from the ASCII character set [<a href="#ref-1" title='"USA Code for Information Interchange"'>1</a>]. Domain - names are used as names of hosts and of other entities in the domain - name hierarchy. For example, a domain may refer to an alias (label - of a CNAME RR) or the label of Mail eXchanger records to be used to - deliver mail instead of representing a host name. See [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>] and - <a href="#section-5">section 5</a> of this specification. - - The domain name, as described in this document and in [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>], is the - entire, fully-qualified name (often referred to as an "FQDN"). A - domain name that is not in FQDN form is no more than a local alias. - Local aliases MUST NOT appear in any SMTP transaction. - -<span class="h4"><h4><a class="selflink" name="section-2.3.6" href="#section-2.3.6">2.3.6</a> Buffer and State Table</h4></span> - - SMTP sessions are stateful, with both parties carefully maintaining a - common view of the current state. In this document we model this - state by a virtual "buffer" and a "state table" on the server which - may be used by the client to, for example, "clear the buffer" or - "reset the state table," causing the information in the buffer to be - discarded and the state to be returned to some previous state. - - - - - - - -<span class="grey">Klensin Standards Track [Page 11]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h4"><h4><a class="selflink" name="section-2.3.7" href="#section-2.3.7">2.3.7</a> Lines</h4></span> - - SMTP commands and, unless altered by a service extension, message - data, are transmitted in "lines". Lines consist of zero or more data - characters terminated by the sequence ASCII character "CR" (hex value - 0D) followed immediately by ASCII character "LF" (hex value 0A). - This termination sequence is denoted as <CRLF> in this document. - Conforming implementations MUST NOT recognize or generate any other - character or character sequence as a line terminator. Limits MAY be - imposed on line lengths by servers (see <a href="#section-4.5.3">section 4.5.3</a>). - - In addition, the appearance of "bare" "CR" or "LF" characters in text - (i.e., either without the other) has a long history of causing - problems in mail implementations and applications that use the mail - system as a tool. SMTP client implementations MUST NOT transmit - these characters except when they are intended as line terminators - and then MUST, as indicated above, transmit them only as a <CRLF> - sequence. - -<span class="h4"><h4><a class="selflink" name="section-2.3.8" href="#section-2.3.8">2.3.8</a> Originator, Delivery, Relay, and Gateway Systems</h4></span> - - This specification makes a distinction among four types of SMTP - systems, based on the role those systems play in transmitting - electronic mail. An "originating" system (sometimes called an SMTP - originator) introduces mail into the Internet or, more generally, - into a transport service environment. A "delivery" SMTP system is - one that receives mail from a transport service environment and - passes it to a mail user agent or deposits it in a message store - which a mail user agent is expected to subsequently access. A - "relay" SMTP system (usually referred to just as a "relay") receives - mail from an SMTP client and transmits it, without modification to - the message data other than adding trace information, to another SMTP - server for further relaying or for delivery. - - A "gateway" SMTP system (usually referred to just as a "gateway") - receives mail from a client system in one transport environment and - transmits it to a server system in another transport environment. - Differences in protocols or message semantics between the transport - environments on either side of a gateway may require that the gateway - system perform transformations to the message that are not permitted - to SMTP relay systems. For the purposes of this specification, - firewalls that rewrite addresses should be considered as gateways, - even if SMTP is used on both sides of them (see [<a href="#ref-11" title='"Behavior of and Requirements for Internet Firewalls"'>11</a>]). - - - - - - - - -<span class="grey">Klensin Standards Track [Page 12]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h4"><h4><a class="selflink" name="section-2.3.9" href="#section-2.3.9">2.3.9</a> Message Content and Mail Data</h4></span> - - The terms "message content" and "mail data" are used interchangeably - in this document to describe the material transmitted after the DATA - command is accepted and before the end of data indication is - transmitted. Message content includes message headers and the - possibly-structured message body. The MIME specification [<a href="#ref-12" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>12</a>] - provides the standard mechanisms for structured message bodies. - -<span class="h4"><h4><a class="selflink" name="section-2.3.10" href="#section-2.3.10">2.3.10</a> Mailbox and Address</h4></span> - - As used in this specification, an "address" is a character string - that identifies a user to whom mail will be sent or a location into - which mail will be deposited. The term "mailbox" refers to that - depository. The two terms are typically used interchangeably unless - the distinction between the location in which mail is placed (the - mailbox) and a reference to it (the address) is important. An - address normally consists of user and domain specifications. The - standard mailbox naming convention is defined to be "local- - part@domain": contemporary usage permits a much broader set of - applications than simple "user names". Consequently, and due to a - long history of problems when intermediate hosts have attempted to - optimize transport by modifying them, the local-part MUST be - interpreted and assigned semantics only by the host specified in the - domain part of the address. - -<span class="h4"><h4><a class="selflink" name="section-2.3.11" href="#section-2.3.11">2.3.11</a> Reply</h4></span> - - An SMTP reply is an acknowledgment (positive or negative) sent from - receiver to sender via the transmission channel in response to a - command. The general form of a reply is a numeric completion code - (indicating failure or success) usually followed by a text string. - The codes are for use by programs and the text is usually intended - for human users. Recent work [<a href="#ref-34" title='"Enhanced Mail System Status Codes"'>34</a>] has specified further structuring - of the reply strings, including the use of supplemental and more - specific completion codes. - -<span class="h3"><h3><a class="selflink" name="section-2.4" href="#section-2.4">2.4</a> General Syntax Principles and Transaction Model</h3></span> - - SMTP commands and replies have a rigid syntax. All commands begin - with a command verb. All Replies begin with a three digit numeric - code. In some commands and replies, arguments MUST follow the verb - or reply code. Some commands do not accept arguments (after the - verb), and some reply codes are followed, sometimes optionally, by - free form text. In both cases, where text appears, it is separated - from the verb or reply code by a space character. Complete - definitions of commands and replies appear in <a href="#section-4">section 4</a>. - - - - -<span class="grey">Klensin Standards Track [Page 13]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command - and extension name keywords) are not case sensitive, with the sole - exception in this specification of a mailbox local-part (SMTP - Extensions may explicitly specify case-sensitive elements). That is, - a command verb, an argument value other than a mailbox local-part, - and free form text MAY be encoded in upper case, lower case, or any - mixture of upper and lower case with no impact on its meaning. This - is NOT true of a mailbox local-part. The local-part of a mailbox - MUST BE treated as case sensitive. Therefore, SMTP implementations - MUST take care to preserve the case of mailbox local-parts. Mailbox - domains are not case sensitive. In particular, for some hosts the - user "smith" is different from the user "Smith". However, exploiting - the case sensitivity of mailbox local-parts impedes interoperability - and is discouraged. - - A few SMTP servers, in violation of this specification (and <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>) - require that command verbs be encoded by clients in upper case. - Implementations MAY wish to employ this encoding to accommodate those - servers. - - The argument field consists of a variable length character string - ending with the end of the line, i.e., with the character sequence - <CRLF>. The receiver will take no action until this sequence is - received. - - The syntax for each command is shown with the discussion of that - command. Common elements and parameters are shown in <a href="#section-4.1.2">section 4.1.2</a>. - - Commands and replies are composed of characters from the ASCII - character set [<a href="#ref-1" title='"USA Code for Information Interchange"'>1</a>]. When the transport service provides an 8-bit byte - (octet) transmission channel, each 7-bit character is transmitted - right justified in an octet with the high order bit cleared to zero. - More specifically, the unextended SMTP service provides seven bit - transport only. An originating SMTP client which has not - successfully negotiated an appropriate extension with a particular - server MUST NOT transmit messages with information in the high-order - bit of octets. If such messages are transmitted in violation of this - rule, receiving SMTP servers MAY clear the high-order bit or reject - the message as invalid. In general, a relay SMTP SHOULD assume that - the message content it has received is valid and, assuming that the - envelope permits doing so, relay it without inspecting that content. - Of course, if the content is mislabeled and the data path cannot - accept the actual content, this may result in ultimate delivery of a - severely garbled message to the recipient. Delivery SMTP systems MAY - reject ("bounce") such messages rather than deliver them. No sending - SMTP system is permitted to send envelope commands in any character - - - - - -<span class="grey">Klensin Standards Track [Page 14]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - set other than US-ASCII; receiving systems SHOULD reject such - commands, normally using "500 syntax error - invalid character" - replies. - - Eight-bit message content transmission MAY be requested of the server - by a client using extended SMTP facilities, notably the "8BITMIME" - extension [<a href="#ref-20" title='"SMTP Service Extension for 8bit-MIMEtransport"'>20</a>]. 8BITMIME SHOULD be supported by SMTP servers. - However, it MUST not be construed as authorization to transmit - unrestricted eight bit material. 8BITMIME MUST NOT be requested by - senders for material with the high bit on that is not in MIME format - with an appropriate content-transfer encoding; servers MAY reject - such messages. - - The metalinguistic notation used in this document corresponds to the - "Augmented BNF" used in other Internet mail system documents. The - reader who is not familiar with that syntax should consult the ABNF - specification [<a href="#ref-8" title='"Augmented BNF for Syntax Specifications: ABNF"'>8</a>]. Metalanguage terms used in running text are - surrounded by pointed brackets (e.g., <CRLF>) for clarity. - -<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. The SMTP Procedures: An Overview</h2></span> - - This section contains descriptions of the procedures used in SMTP: - session initiation, the mail transaction, forwarding mail, verifying - mailbox names and expanding mailing lists, and the opening and - closing exchanges. Comments on relaying, a note on mail domains, and - a discussion of changing roles are included at the end of this - section. Several complete scenarios are presented in <a href="#appendix-D">appendix D</a>. - -<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a> Session Initiation</h3></span> - - An SMTP session is initiated when a client opens a connection to a - server and the server responds with an opening message. - - SMTP server implementations MAY include identification of their - software and version information in the connection greeting reply - after the 220 code, a practice that permits more efficient isolation - and repair of any problems. Implementations MAY make provision for - SMTP servers to disable the software and version announcement where - it causes security concerns. While some systems also identify their - contact point for mail problems, this is not a substitute for - maintaining the required "postmaster" address (see <a href="#section-4.5.1">section 4.5.1</a>). - - The SMTP protocol allows a server to formally reject a transaction - while still allowing the initial connection as follows: a 554 - response MAY be given in the initial connection opening message - instead of the 220. A server taking this approach MUST still wait - for the client to send a QUIT (see <a href="#section-4.1.1.10">section 4.1.1.10</a>) before closing - the connection and SHOULD respond to any intervening commands with - - - -<span class="grey">Klensin Standards Track [Page 15]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - "503 bad sequence of commands". Since an attempt to make an SMTP - connection to such a system is probably in error, a server returning - a 554 response on connection opening SHOULD provide enough - information in the reply text to facilitate debugging of the sending - system. - -<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a> Client Initiation</h3></span> - - Once the server has sent the welcoming message and the client has - received it, the client normally sends the EHLO command to the - server, indicating the client's identity. In addition to opening the - session, use of EHLO indicates that the client is able to process - service extensions and requests that the server provide a list of the - extensions it supports. Older SMTP systems which are unable to - support service extensions and contemporary clients which do not - require service extensions in the mail session being initiated, MAY - use HELO instead of EHLO. Servers MUST NOT return the extended - EHLO-style response to a HELO command. For a particular connection - attempt, if the server returns a "command not recognized" response to - EHLO, the client SHOULD be able to fall back and send HELO. - - In the EHLO command the host sending the command identifies itself; - the command may be interpreted as saying "Hello, I am <domain>" (and, - in the case of EHLO, "and I support service extension requests"). - -<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a> Mail Transactions</h3></span> - - There are three steps to SMTP mail transactions. The transaction - starts with a MAIL command which gives the sender identification. - (In general, the MAIL command may be sent only when no mail - transaction is in progress; see <a href="#section-4.1.4">section 4.1.4</a>.) A series of one or - more RCPT commands follows giving the receiver information. Then a - DATA command initiates transfer of the mail data and is terminated by - the "end of mail" data indicator, which also confirms the - transaction. - - The first step in the procedure is the MAIL command. - - MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> - - This command tells the SMTP-receiver that a new mail transaction is - starting and to reset all its state tables and buffers, including any - recipients or mail data. The <reverse-path> portion of the first or - only argument contains the source mailbox (between "<" and ">" - brackets), which can be used to report errors (see <a href="#section-4.2">section 4.2</a> for a - discussion of error reporting). If accepted, the SMTP server returns - a 250 OK reply. If the mailbox specification is not acceptable for - some reason, the server MUST return a reply indicating whether the - - - -<span class="grey">Klensin Standards Track [Page 16]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - failure is permanent (i.e., will occur again if the client tries to - send the same address again) or temporary (i.e., the address might be - accepted if the client tries again later). Despite the apparent - scope of this requirement, there are circumstances in which the - acceptability of the reverse-path may not be determined until one or - more forward-paths (in RCPT commands) can be examined. In those - cases, the server MAY reasonably accept the reverse-path (with a 250 - reply) and then report problems after the forward-paths are received - and examined. Normally, failures produce 550 or 553 replies. - - Historically, the <reverse-path> can contain more than just a - mailbox, however, contemporary systems SHOULD NOT use source routing - (see <a href="#appendix-C">appendix C</a>). - - The optional <mail-parameters> are associated with negotiated SMTP - service extensions (see <a href="#section-2.2">section 2.2</a>). - - The second step in the procedure is the RCPT command. - - RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF> - - The first or only argument to this command includes a forward-path - (normally a mailbox and domain, always surrounded by "<" and ">" - brackets) identifying one recipient. If accepted, the SMTP server - returns a 250 OK reply and stores the forward-path. If the recipient - is known not to be a deliverable address, the SMTP server returns a - 550 reply, typically with a string such as "no such user - " and the - mailbox name (other circumstances and reply codes are possible). - This step of the procedure can be repeated any number of times. - - The <forward-path> can contain more than just a mailbox. - Historically, the <forward-path> can be a source routing list of - hosts and the destination mailbox, however, contemporary SMTP clients - SHOULD NOT utilize source routes (see <a href="#appendix-C">appendix C</a>). Servers MUST be - prepared to encounter a list of source routes in the forward path, - but SHOULD ignore the routes or MAY decline to support the relaying - they imply. Similarly, servers MAY decline to accept mail that is - destined for other hosts or systems. These restrictions make a - server useless as a relay for clients that do not support full SMTP - functionality. Consequently, restricted-capability clients MUST NOT - assume that any SMTP server on the Internet can be used as their mail - processing (relaying) site. If a RCPT command appears without a - previous MAIL command, the server MUST return a 503 "Bad sequence of - commands" response. The optional <rcpt-parameters> are associated - with negotiated SMTP service extensions (see <a href="#section-2.2">section 2.2</a>). - - The third step in the procedure is the DATA command (or some - alternative specified in a service extension). - - - -<span class="grey">Klensin Standards Track [Page 17]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - DATA <CRLF> - - If accepted, the SMTP server returns a 354 Intermediate reply and - considers all succeeding lines up to but not including the end of - mail data indicator to be the message text. When the end of text is - successfully received and stored the SMTP-receiver sends a 250 OK - reply. - - Since the mail data is sent on the transmission channel, the end of - mail data must be indicated so that the command and reply dialog can - be resumed. SMTP indicates the end of the mail data by sending a - line containing only a "." (period or full stop). A transparency - procedure is used to prevent this from interfering with the user's - text (see <a href="#section-4.5.2">section 4.5.2</a>). - - The end of mail data indicator also confirms the mail transaction and - tells the SMTP server to now process the stored recipients and mail - data. If accepted, the SMTP server returns a 250 OK reply. The DATA - command can fail at only two points in the protocol exchange: - - - If there was no MAIL, or no RCPT, command, or all such commands - were rejected, the server MAY return a "command out of sequence" - (503) or "no valid recipients" (554) reply in response to the DATA - command. If one of those replies (or any other 5yz reply) is - received, the client MUST NOT send the message data; more - generally, message data MUST NOT be sent unless a 354 reply is - received. - - - If the verb is initially accepted and the 354 reply issued, the - DATA command should fail only if the mail transaction was - incomplete (for example, no recipients), or if resources were - unavailable (including, of course, the server unexpectedly - becoming unavailable), or if the server determines that the - message should be rejected for policy or other reasons. - - However, in practice, some servers do not perform recipient - verification until after the message text is received. These servers - SHOULD treat a failure for one or more recipients as a "subsequent - failure" and return a mail message as discussed in <a href="#section-6">section 6</a>. Using - a "550 mailbox not found" (or equivalent) reply code after the data - are accepted makes it difficult or impossible for the client to - determine which recipients failed. - - When <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> format [<a href="#ref-7" title='"Standard for the Format of ARPA Internet Text Messages"'>7</a>, <a href="#ref-32" title='"Internet Message Format"'>32</a>] is being used, the mail data include the - memo header items such as Date, Subject, To, Cc, From. Server SMTP - systems SHOULD NOT reject messages based on perceived defects in the - <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> or MIME [<a href="#ref-12" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>12</a>] message header or message body. In particular, - - - - -<span class="grey">Klensin Standards Track [Page 18]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - they MUST NOT reject messages in which the numbers of Resent-fields - do not match or Resent-to appears without Resent-from and/or Resent- - date. - - Mail transaction commands MUST be used in the order discussed above. - -<span class="h3"><h3><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a> Forwarding for Address Correction or Updating</h3></span> - - Forwarding support is most often required to consolidate and simplify - addresses within, or relative to, some enterprise and less frequently - to establish addresses to link a person's prior address with current - one. Silent forwarding of messages (without server notification to - the sender), for security or non-disclosure purposes, is common in - the contemporary Internet. - - In both the enterprise and the "new address" cases, information - hiding (and sometimes security) considerations argue against exposure - of the "final" address through the SMTP protocol as a side-effect of - the forwarding activity. This may be especially important when the - final address may not even be reachable by the sender. Consequently, - the "forwarding" mechanisms described in <a href="http://tools.ietf.org/html/rfc821#section-3.2">section 3.2 of RFC 821</a>, and - especially the 251 (corrected destination) and 551 reply codes from - RCPT must be evaluated carefully by implementers and, when they are - available, by those configuring systems. - - In particular: - - * Servers MAY forward messages when they are aware of an address - change. When they do so, they MAY either provide address-updating - information with a 251 code, or may forward "silently" and return - a 250 code. But, if a 251 code is used, they MUST NOT assume that - the client will actually update address information or even return - that information to the user. - - Alternately, - - * Servers MAY reject or bounce messages when they are not - deliverable when addressed. When they do so, they MAY either - provide address-updating information with a 551 code, or may - reject the message as undeliverable with a 550 code and no - address-specific information. But, if a 551 code is used, they - MUST NOT assume that the client will actually update address - information or even return that information to the user. - - SMTP server implementations that support the 251 and/or 551 reply - codes are strongly encouraged to provide configuration mechanisms so - that sites which conclude that they would undesirably disclose - information can disable or restrict their use. - - - -<span class="grey">Klensin Standards Track [Page 19]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h3"><h3><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a> Commands for Debugging Addresses</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-3.5.1" href="#section-3.5.1">3.5.1</a> Overview</h4></span> - - SMTP provides commands to verify a user name or obtain the content of - a mailing list. This is done with the VRFY and EXPN commands, which - have character string arguments. Implementations SHOULD support VRFY - and EXPN (however, see <a href="#section-3.5.2">section 3.5.2</a> and 7.3). - - For the VRFY command, the string is a user name or a user name and - domain (see below). If a normal (i.e., 250) response is returned, - the response MAY include the full name of the user and MUST include - the mailbox of the user. It MUST be in either of the following - forms: - - User Name <local-part@domain> - local-part@domain - - When a name that is the argument to VRFY could identify more than one - mailbox, the server MAY either note the ambiguity or identify the - alternatives. In other words, any of the following are legitimate - response to VRFY: - - 553 User ambiguous - - or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - - or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - - Under normal circumstances, a client receiving a 553 reply would be - expected to expose the result to the user. Use of exactly the forms - given, and the "user ambiguous" or "ambiguous" keywords, possibly - supplemented by extended reply codes such as those described in [<a href="#ref-34" title='"Enhanced Mail System Status Codes"'>34</a>], - will facilitate automated translation into other languages as needed. - Of course, a client that was highly automated or that was operating - in another language than English, might choose to try to translate - the response, to return some other indication to the user than the - - - - -<span class="grey">Klensin Standards Track [Page 20]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - literal text of the reply, or to take some automated action such as - consulting a directory service for additional information before - reporting to the user. - - For the EXPN command, the string identifies a mailing list, and the - successful (i.e., 250) multiline response MAY include the full name - of the users and MUST give the mailboxes on the mailing list. - - In some hosts the distinction between a mailing list and an alias for - a single mailbox is a bit fuzzy, since a common data structure may - hold both types of entries, and it is possible to have mailing lists - containing only one mailbox. If a request is made to apply VRFY to a - mailing list, a positive response MAY be given if a message so - addressed would be delivered to everyone on the list, otherwise an - error SHOULD be reported (e.g., "550 That is a mailing list, not a - user" or "252 Unable to verify members of mailing list"). If a - request is made to expand a user name, the server MAY return a - positive response consisting of a list containing one name, or an - error MAY be reported (e.g., "550 That is a user name, not a mailing - list"). - - In the case of a successful multiline reply (normal for EXPN) exactly - one mailbox is to be specified on each line of the reply. The case - of an ambiguous request is discussed above. - - "User name" is a fuzzy term and has been used deliberately. An - implementation of the VRFY or EXPN commands MUST include at least - recognition of local mailboxes as "user names". However, since - current Internet practice often results in a single host handling - mail for multiple domains, hosts, especially hosts that provide this - functionality, SHOULD accept the "local-part@domain" form as a "user - name"; hosts MAY also choose to recognize other strings as "user - names". - - The case of expanding a mailbox list requires a multiline reply, such - as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - - or - - C: EXPN Executive-Washroom-List - S: 550 Access Denied to You. - - - - - -<span class="grey">Klensin Standards Track [Page 21]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - The character string arguments of the VRFY and EXPN commands cannot - be further restricted due to the variety of implementations of the - user name and mailbox list concepts. On some systems it may be - appropriate for the argument of the EXPN command to be a file name - for a file containing a mailing list, but again there are a variety - of file naming conventions in the Internet. Similarly, historical - variations in what is returned by these commands are such that the - response SHOULD be interpreted very carefully, if at all, and SHOULD - generally only be used for diagnostic purposes. - -<span class="h4"><h4><a class="selflink" name="section-3.5.2" href="#section-3.5.2">3.5.2</a> VRFY Normal Response</h4></span> - - When normal (2yz or 551) responses are returned from a VRFY or EXPN - request, the reply normally includes the mailbox name, i.e., - "<local-part@domain>", where "domain" is a fully qualified domain - name, MUST appear in the syntax. In circumstances exceptional enough - to justify violating the intent of this specification, free-form text - MAY be returned. In order to facilitate parsing by both computers - and people, addresses SHOULD appear in pointed brackets. When - addresses, rather than free-form debugging information, are returned, - EXPN and VRFY MUST return only valid domain addresses that are usable - in SMTP RCPT commands. Consequently, if an address implies delivery - to a program or other system, the mailbox name used to reach that - target MUST be given. Paths (explicit source routes) MUST NOT be - returned by VRFY or EXPN. - - Server implementations SHOULD support both VRFY and EXPN. For - security reasons, implementations MAY provide local installations a - way to disable either or both of these commands through configuration - options or the equivalent. When these commands are supported, they - are not required to work across relays when relaying is supported. - Since they were both optional in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>, they MUST be listed as - service extensions in an EHLO response, if they are supported. - -<span class="h4"><h4><a class="selflink" name="section-3.5.3" href="#section-3.5.3">3.5.3</a> Meaning of VRFY or EXPN Success Response</h4></span> - - A server MUST NOT return a 250 code in response to a VRFY or EXPN - command unless it has actually verified the address. In particular, - a server MUST NOT return 250 if all it has done is to verify that the - syntax given is valid. In that case, 502 (Command not implemented) - or 500 (Syntax error, command unrecognized) SHOULD be returned. As - stated elsewhere, implementation (in the sense of actually validating - addresses and returning information) of VRFY and EXPN are strongly - recommended. Hence, implementations that return 500 or 502 for VRFY - are not in full compliance with this specification. - - - - - - -<span class="grey">Klensin Standards Track [Page 22]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - There may be circumstances where an address appears to be valid but - cannot reasonably be verified in real time, particularly when a - server is acting as a mail exchanger for another server or domain. - "Apparent validity" in this case would normally involve at least - syntax checking and might involve verification that any domains - specified were ones to which the host expected to be able to relay - mail. In these situations, reply code 252 SHOULD be returned. These - cases parallel the discussion of RCPT verification discussed in - <a href="#section-2.1">section 2.1</a>. Similarly, the discussion in <a href="#section-3.4">section 3.4</a> applies to the - use of reply codes 251 and 551 with VRFY (and EXPN) to indicate - addresses that are recognized but that would be forwarded or bounced - were mail received for them. Implementations generally SHOULD be - more aggressive about address verification in the case of VRFY than - in the case of RCPT, even if it takes a little longer to do so. - -<span class="h4"><h4><a class="selflink" name="section-3.5.4" href="#section-3.5.4">3.5.4</a> Semantics and Applications of EXPN</h4></span> - - EXPN is often very useful in debugging and understanding problems - with mailing lists and multiple-target-address aliases. Some systems - have attempted to use source expansion of mailing lists as a means of - eliminating duplicates. The propagation of aliasing systems with - mail on the Internet, for hosts (typically with MX and CNAME DNS - records), for mailboxes (various types of local host aliases), and in - various proxying arrangements, has made it nearly impossible for - these strategies to work consistently, and mail systems SHOULD NOT - attempt them. - -<span class="h3"><h3><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a> Domains</h3></span> - - Only resolvable, fully-qualified, domain names (FQDNs) are permitted - when domain names are used in SMTP. In other words, names that can - be resolved to MX RRs or A RRs (as discussed in <a href="#section-5">section 5</a>) are - permitted, as are CNAME RRs whose targets can be resolved, in turn, - to MX or A RRs. Local nicknames or unqualified names MUST NOT be - used. There are two exceptions to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary - host name (a domain name that resolves to an A RR) or, if the host - has no name, an address literal as described in <a href="#section-4.1.1.1">section 4.1.1.1</a>. - - - The reserved mailbox name "postmaster" may be used in a RCPT - command without domain qualification (see <a href="#section-4.1.1.3">section 4.1.1.3</a>) and - MUST be accepted if so used. - - - - - - - - -<span class="grey">Klensin Standards Track [Page 23]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h3"><h3><a class="selflink" name="section-3.7" href="#section-3.7">3.7</a> Relaying</h3></span> - - In general, the availability of Mail eXchanger records in the domain - name system [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>, <a href="#ref-27" title='"Mail routing and the domain system"'>27</a>] makes the use of explicit source routes in the - Internet mail system unnecessary. Many historical problems with - their interpretation have made their use undesirable. SMTP clients - SHOULD NOT generate explicit source routes except under unusual - circumstances. SMTP servers MAY decline to act as mail relays or to - accept addresses that specify source routes. When route information - is encountered, SMTP servers are also permitted to ignore the route - information and simply send to the final destination specified as the - last element in the route and SHOULD do so. There has been an - invalid practice of using names that do not appear in the DNS as - destination names, with the senders counting on the intermediate - hosts specified in source routing to resolve any problems. If source - routes are stripped, this practice will cause failures. This is one - of several reasons why SMTP clients MUST NOT generate invalid source - routes or depend on serial resolution of names. - - When source routes are not used, the process described in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> for - constructing a reverse-path from the forward-path is not applicable - and the reverse-path at the time of delivery will simply be the - address that appeared in the MAIL command. - - A relay SMTP server is usually the target of a DNS MX record that - designates it, rather than the final delivery system. The relay - server may accept or reject the task of relaying the mail in the same - way it accepts or rejects mail for a local user. If it accepts the - task, it then becomes an SMTP client, establishes a transmission - channel to the next SMTP server specified in the DNS (according to - the rules in <a href="#section-5">section 5</a>), and sends it the mail. If it declines to - relay mail to a particular address for policy reasons, a 550 response - SHOULD be returned. - - Many mail-sending clients exist, especially in conjunction with - facilities that receive mail via POP3 or IMAP, that have limited - capability to support some of the requirements of this specification, - such as the ability to queue messages for subsequent delivery - attempts. For these clients, it is common practice to make private - arrangements to send all messages to a single server for processing - and subsequent distribution. SMTP, as specified here, is not ideally - suited for this role, and work is underway on standardized mail - submission protocols that might eventually supercede the current - practices. In any event, because these arrangements are private and - fall outside the scope of this specification, they are not described - here. - - - - - -<span class="grey">Klensin Standards Track [Page 24]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - It is important to note that MX records can point to SMTP servers - which act as gateways into other environments, not just SMTP relays - and final delivery systems; see sections <a href="#section-3.8">3.8</a> and <a href="#section-5">5</a>. - - If an SMTP server has accepted the task of relaying the mail and - later finds that the destination is incorrect or that the mail cannot - be delivered for some other reason, then it MUST construct an - "undeliverable mail" notification message and send it to the - originator of the undeliverable mail (as indicated by the reverse- - path). Formats specified for non-delivery reports by other standards - (see, for example, [<a href="#ref-24" title='"SMTP Service Extension for Delivery Status Notifications"'>24</a>, <a href="#ref-25" title='"An Extensible Message Format for Delivery Status Notifications"'>25</a>]) SHOULD be used if possible. - - This notification message must be from the SMTP server at the relay - host or the host that first determines that delivery cannot be - accomplished. Of course, SMTP servers MUST NOT send notification - messages about problems transporting notification messages. One way - to prevent loops in error reporting is to specify a null reverse-path - in the MAIL command of a notification message. When such a message - is transmitted the reverse-path MUST be set to null (see <a href="#section-4.5.5">section</a> - <a href="#section-4.5.5">4.5.5</a> for additional discussion). A MAIL command with a null - reverse-path appears as follows: - - MAIL FROM:<> - - As discussed in <a href="#section-2.4.1">section 2.4.1</a>, a relay SMTP has no need to inspect or - act upon the headers or body of the message data and MUST NOT do so - except to add its own "Received:" header (<a href="#section-4.4">section 4.4</a>) and, - optionally, to attempt to detect looping in the mail system (see - <a href="#section-6.2">section 6.2</a>). - -<span class="h3"><h3><a class="selflink" name="section-3.8" href="#section-3.8">3.8</a> Mail Gatewaying</h3></span> - - While the relay function discussed above operates within the Internet - SMTP transport service environment, MX records or various forms of - explicit routing may require that an intermediate SMTP server perform - a translation function between one transport service and another. As - discussed in <a href="#section-2.3.8">section 2.3.8</a>, when such a system is at the boundary - between two transport service environments, we refer to it as a - "gateway" or "gateway SMTP". - - Gatewaying mail between different mail environments, such as - different mail formats and protocols, is complex and does not easily - yield to standardization. However, some general requirements may be - given for a gateway between the Internet and another mail - environment. - - - - - - -<span class="grey">Klensin Standards Track [Page 25]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h4"><h4><a class="selflink" name="section-3.8.1" href="#section-3.8.1">3.8.1</a> Header Fields in Gatewaying</h4></span> - - Header fields MAY be rewritten when necessary as messages are - gatewayed across mail environment boundaries. This may involve - inspecting the message body or interpreting the local-part of the - destination address in spite of the prohibitions in <a href="#section-2.4.1">section 2.4.1</a>. - - Other mail systems gatewayed to the Internet often use a subset of - <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> headers or provide similar functionality with a different - syntax, but some of these mail systems do not have an equivalent to - the SMTP envelope. Therefore, when a message leaves the Internet - environment, it may be necessary to fold the SMTP envelope - information into the message header. A possible solution would be to - create new header fields to carry the envelope information (e.g., - "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require - changes in mail programs in foreign environments and might risk - disclosure of private information (see <a href="#section-7.2">section 7.2</a>). - -<span class="h4"><h4><a class="selflink" name="section-3.8.2" href="#section-3.8.2">3.8.2</a> Received Lines in Gatewaying</h4></span> - - When forwarding a message into or out of the Internet environment, a - gateway MUST prepend a Received: line, but it MUST NOT alter in any - way a Received: line that is already in the header. - - "Received:" fields of messages originating from other environments - may not conform exactly to this specification. However, the most - important use of Received: lines is for debugging mail faults, and - this debugging can be severely hampered by well-meaning gateways that - try to "fix" a Received: line. As another consequence of trace - fields arising in non-SMTP environments, receiving systems MUST NOT - reject mail based on the format of a trace field and SHOULD be - extremely robust in the light of unexpected information or formats in - those fields. - - The gateway SHOULD indicate the environment and protocol in the "via" - clauses of Received field(s) that it supplies. - -<span class="h4"><h4><a class="selflink" name="section-3.8.3" href="#section-3.8.3">3.8.3</a> Addresses in Gatewaying</h4></span> - - From the Internet side, the gateway SHOULD accept all valid address - formats in SMTP commands and in <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> headers, and all valid <a href="http://tools.ietf.org/html/rfc822">RFC</a> - <a href="http://tools.ietf.org/html/rfc822">822</a> messages. Addresses and headers generated by gateways MUST - conform to applicable Internet standards (including this one and <a href="http://tools.ietf.org/html/rfc822">RFC</a> - <a href="http://tools.ietf.org/html/rfc822">822</a>). Gateways are, of course, subject to the same rules for - handling source routes as those described for other SMTP systems in - <a href="#section-3.3">section 3.3</a>. - - - - - -<span class="grey">Klensin Standards Track [Page 26]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h4"><h4><a class="selflink" name="section-3.8.4" href="#section-3.8.4">3.8.4</a> Other Header Fields in Gatewaying</h4></span> - - The gateway MUST ensure that all header fields of a message that it - forwards into the Internet mail environment meet the requirements for - Internet mail. In particular, all addresses in "From:", "To:", - "Cc:", etc., fields MUST be transformed (if necessary) to satisfy <a href="http://tools.ietf.org/html/rfc822">RFC</a> - <a href="http://tools.ietf.org/html/rfc822">822</a> syntax, MUST reference only fully-qualified domain names, and - MUST be effective and useful for sending replies. The translation - algorithm used to convert mail from the Internet protocols to another - environment's protocol SHOULD ensure that error messages from the - foreign mail environment are delivered to the return path from the - SMTP envelope, not to the sender listed in the "From:" field (or - other fields) of the <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> message. - -<span class="h4"><h4><a class="selflink" name="section-3.8.5" href="#section-3.8.5">3.8.5</a> Envelopes in Gatewaying</h4></span> - - Similarly, when forwarding a message from another environment into - the Internet, the gateway SHOULD set the envelope return path in - accordance with an error message return address, if supplied by the - foreign environment. If the foreign environment has no equivalent - concept, the gateway must select and use a best approximation, with - the message originator's address as the default of last resort. - -<span class="h3"><h3><a class="selflink" name="section-3.9" href="#section-3.9">3.9</a> Terminating Sessions and Connections</h3></span> - - An SMTP connection is terminated when the client sends a QUIT - command. The server responds with a positive reply code, after which - it closes the connection. - - An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shut down the SMTP service and - returning a 421 response code. This response code can be issued - after the server receives any command or, if necessary, - asynchronously from command receipt (on the assumption that the - client will receive it after the next command is issued). - - In particular, a server that closes connections in response to - commands that are not understood is in violation of this - specification. Servers are expected to be tolerant of unknown - commands, issuing a 500 reply and awaiting further instructions from - the client. - - - - - - - -<span class="grey">Klensin Standards Track [Page 27]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - An SMTP server which is forcibly shut down via external means SHOULD - attempt to send a line containing a 421 response code to the SMTP - client before exiting. The SMTP client will normally read the 421 - response code after sending its next command. - - SMTP clients that experience a connection close, reset, or other - communications failure due to circumstances not under their control - (in violation of the intent of this specification but sometimes - unavoidable) SHOULD, to maintain the robustness of the mail system, - treat the mail transaction as if a 451 response had been received and - act accordingly. - -<span class="h3"><h3><a class="selflink" name="section-3.10" href="#section-3.10">3.10</a> Mailing Lists and Aliases</h3></span> - - An SMTP-capable host SHOULD support both the alias and the list - models of address expansion for multiple delivery. When a message is - delivered or forwarded to each address of an expanded list form, the - return address in the envelope ("MAIL FROM:") MUST be changed to be - the address of a person or other entity who administers the list. - However, in this case, the message header [<a href="#ref-32" title='"Internet Message Format"'>32</a>] MUST be left - unchanged; in particular, the "From" field of the message header is - unaffected. - - An important mail facility is a mechanism for multi-destination - delivery of a single message, by transforming (or "expanding" or - "exploding") a pseudo-mailbox address into a list of destination - mailbox addresses. When a message is sent to such a pseudo-mailbox - (sometimes called an "exploder"), copies are forwarded or - redistributed to each mailbox in the expanded list. Servers SHOULD - simply utilize the addresses on the list; application of heuristics - or other matching rules to eliminate some addresses, such as that of - the originator, is strongly discouraged. We classify such a pseudo- - mailbox as an "alias" or a "list", depending upon the expansion - rules. - -<span class="h4"><h4><a class="selflink" name="section-3.10.1" href="#section-3.10.1">3.10.1</a> Alias</h4></span> - - To expand an alias, the recipient mailer simply replaces the pseudo- - mailbox address in the envelope with each of the expanded addresses - in turn; the rest of the envelope and the message body are left - unchanged. The message is then delivered or forwarded to each - expanded address. - -<span class="h4"><h4><a class="selflink" name="section-3.10.2" href="#section-3.10.2">3.10.2</a> List</h4></span> - - A mailing list may be said to operate by "redistribution" rather than - by "forwarding". To expand a list, the recipient mailer replaces the - pseudo-mailbox address in the envelope with all of the expanded - - - -<span class="grey">Klensin Standards Track [Page 28]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - addresses. The return address in the envelope is changed so that all - error messages generated by the final deliveries will be returned to - a list administrator, not to the message originator, who generally - has no control over the contents of the list and will typically find - error messages annoying. - -<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. The SMTP Specifications</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a> SMTP Commands</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-4.1.1" href="#section-4.1.1">4.1.1</a> Command Semantics and Syntax</h4></span> - - The SMTP commands define the mail transfer or the mail system - function requested by the user. SMTP commands are character strings - terminated by <CRLF>. The commands themselves are alphabetic - characters terminated by <SP> if parameters follow and <CRLF> - otherwise. (In the interest of improved interoperability, SMTP - receivers are encouraged to tolerate trailing white space before the - terminating <CRLF>.) The syntax of the local part of a mailbox must - conform to receiver site conventions and the syntax specified in - <a href="#section-4.1.2">section 4.1.2</a>. The SMTP commands are discussed below. The SMTP - replies are discussed in <a href="#section-4.2">section 4.2</a>. - - A mail transaction involves several data objects which are - communicated as arguments to different commands. The reverse-path is - the argument of the MAIL command, the forward-path is the argument of - the RCPT command, and the mail data is the argument of the DATA - command. These arguments or data objects must be transmitted and - held pending the confirmation communicated by the end of mail data - indication which finalizes the transaction. The model for this is - that distinct buffers are provided to hold the types of data objects, - that is, there is a reverse-path buffer, a forward-path buffer, and a - mail data buffer. Specific commands cause information to be appended - to a specific buffer, or cause one or more buffers to be cleared. - - Several commands (RSET, DATA, QUIT) are specified as not permitting - parameters. In the absence of specific extensions offered by the - server and accepted by the client, clients MUST NOT send such - parameters and servers SHOULD reject commands containing them as - having invalid syntax. - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.1" href="#section-4.1.1.1">4.1.1.1</a> Extended HELLO (EHLO) or HELLO (HELO)</h5></span> - - These commands are used to identify the SMTP client to the SMTP - server. The argument field contains the fully-qualified domain name - of the SMTP client if one is available. In situations in which the - SMTP client system does not have a meaningful domain name (e.g., when - its address is dynamically allocated and no reverse mapping record is - - - -<span class="grey">Klensin Standards Track [Page 29]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - available), the client SHOULD send an address literal (see <a href="#section-4.1.3">section</a> - <a href="#section-4.1.3">4.1.3</a>), optionally followed by information that will help to identify - the client system. y The SMTP server identifies itself to the SMTP - client in the connection greeting reply and in the response to this - command. - - A client SMTP SHOULD start an SMTP session by issuing the EHLO - command. If the SMTP server supports the SMTP service extensions it - will give a successful response, a failure response, or an error - response. If the SMTP server, in violation of this specification, - does not support any SMTP service extensions it will generate an - error response. Older client SMTP systems MAY, as discussed above, - use HELO (as specified in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>) instead of EHLO, and servers MUST - support the HELO command and reply properly to it. In any event, a - client MUST issue HELO or EHLO before starting a mail transaction. - - These commands, and a "250 OK" reply to one of them, confirm that - both the SMTP client and the SMTP server are in the initial state, - that is, there is no transaction in progress and all state tables and - buffers are cleared. - - Syntax: - - ehlo = "EHLO" SP Domain CRLF - helo = "HELO" SP Domain CRLF - - Normally, the response to EHLO will be a multiline reply. Each line - of the response contains a keyword and, optionally, one or more - parameters. Following the normal syntax for multiline replies, these - keyworks follow the code (250) and a hyphen for all but the last - line, and the code and a space for the last line. The syntax for a - positive response, using the ABNF notation and terminal symbols of - [<a href="#ref-8" title='"Augmented BNF for Syntax Specifications: ABNF"'>8</a>], is: - - ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) - / ( "250-" domain [ SP ehlo-greet ] CRLF - *( "250-" ehlo-line CRLF ) - "250" SP ehlo-line CRLF ) - - ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) - ; string of any characters other than CR or LF - - ehlo-line = ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; additional syntax of ehlo-params depends on - ; ehlo-keyword - - - - -<span class="grey">Klensin Standards Track [Page 30]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - ehlo-param = 1*(%d33-127) - ; any CHAR excluding <SP> and all - ; control characters (US-ASCII 0-31 inclusive) - - Although EHLO keywords may be specified in upper, lower, or mixed - case, they MUST always be recognized and processed in a case- - insensitive manner. This is simply an extension of practices - specified in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> and <a href="#section-2.4.1">section 2.4.1</a>. - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.2" href="#section-4.1.1.2">4.1.1.2</a> MAIL (MAIL)</h5></span> - - This command is used to initiate a mail transaction in which the mail - data is delivered to an SMTP server which may, in turn, deliver it to - one or more mailboxes or pass it on to another system (possibly using - SMTP). The argument field contains a reverse-path and may contain - optional parameters. In general, the MAIL command may be sent only - when no mail transaction is in progress, see <a href="#section-4.1.4">section 4.1.4</a>. - - The reverse-path consists of the sender mailbox. Historically, that - mailbox might optionally have been preceded by a list of hosts, but - that behavior is now deprecated (see <a href="#appendix-C">appendix C</a>). In some types of - reporting messages for which a reply is likely to cause a mail loop - (for example, mail delivery and nondelivery notifications), the - reverse-path may be null (see <a href="#section-3.7">section 3.7</a>). - - This command clears the reverse-path buffer, the forward-path buffer, - and the mail data buffer; and inserts the reverse-path information - from this command into the reverse-path buffer. - - If service extensions were negotiated, the MAIL command may also - carry parameters associated with a particular service extension. - - Syntax: - - "MAIL FROM:" ("<>" / Reverse-Path) - [SP Mail-parameters] CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.3" href="#section-4.1.1.3">4.1.1.3</a> RECIPIENT (RCPT)</h5></span> - - This command is used to identify an individual recipient of the mail - data; multiple recipients are specified by multiple use of this - command. The argument field contains a forward-path and may contain - optional parameters. - - The forward-path normally consists of the required destination - mailbox. Sending systems SHOULD not generate the optional list of - hosts known as a source route. Receiving systems MUST recognize - - - - -<span class="grey">Klensin Standards Track [Page 31]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - source route syntax but SHOULD strip off the source route - specification and utilize the domain name associated with the mailbox - as if the source route had not been provided. - - Similarly, relay hosts SHOULD strip or ignore source routes, and - names MUST NOT be copied into the reverse-path. When mail reaches - its ultimate destination (the forward-path contains only a - destination mailbox), the SMTP server inserts it into the destination - mailbox in accordance with its host mail conventions. - - For example, mail received at relay host xyz.com with envelope - commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - - will normally be sent directly on to host d.bar.org with envelope - commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<userc@d.bar.org> - - As provided in <a href="#appendix-C">appendix C</a>, xyz.com MAY also choose to relay the - message to hosta.int, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - - or to jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - - Of course, since hosts are not required to relay mail at all, xyz.com - may also reject the message entirely when the RCPT command is - received, using a 550 code (since this is a "policy reason"). - - If service extensions were negotiated, the RCPT command may also - carry parameters associated with a particular service extension - offered by the server. The client MUST NOT transmit parameters other - than those associated with a service extension offered by the server - in its EHLO response. - -Syntax: - "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path) - [SP Rcpt-parameters] CRLF - - - - - -<span class="grey">Klensin Standards Track [Page 32]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.4" href="#section-4.1.1.4">4.1.1.4</a> DATA (DATA)</h5></span> - - The receiver normally sends a 354 response to DATA, and then treats - the lines (strings ending in <CRLF> sequences, as described in - <a href="#section-2.3.7">section 2.3.7</a>) following the command as mail data from the sender. - This command causes the mail data to be appended to the mail data - buffer. The mail data may contain any of the 128 ASCII character - codes, although experience has indicated that use of control - characters other than SP, HT, CR, and LF may cause problems and - SHOULD be avoided when possible. - - The mail data is terminated by a line containing only a period, that - is, the character sequence "<CRLF>.<CRLF>" (see <a href="#section-4.5.2">section 4.5.2</a>). This - is the end of mail data indication. Note that the first <CRLF> of - this terminating sequence is also the <CRLF> that ends the final line - of the data (message text) or, if there was no data, ends the DATA - command itself. An extra <CRLF> MUST NOT be added, as that would - cause an empty line to be added to the message. The only exception - to this rule would arise if the message body were passed to the - originating SMTP-sender with a final "line" that did not end in - <CRLF>; in that case, the originating SMTP system MUST either reject - the message as invalid or add <CRLF> in order to have the receiving - SMTP server recognize the "end of data" condition. - - The custom of accepting lines ending only in <LF>, as a concession to - non-conforming behavior on the part of some UNIX systems, has proven - to cause more interoperability problems than it solves, and SMTP - server systems MUST NOT do this, even in the name of improved - robustness. In particular, the sequence "<LF>.<LF>" (bare line - feeds, without carriage returns) MUST NOT be treated as equivalent to - <CRLF>.<CRLF> as the end of mail data indication. - - Receipt of the end of mail data indication requires the server to - process the stored mail transaction information. This processing - consumes the information in the reverse-path buffer, the forward-path - buffer, and the mail data buffer, and on the completion of this - command these buffers are cleared. If the processing is successful, - the receiver MUST send an OK reply. If the processing fails the - receiver MUST send a failure reply. The SMTP model does not allow - for partial failures at this point: either the message is accepted by - the server for delivery and a positive response is returned or it is - not accepted and a failure reply is returned. In sending a positive - completion reply to the end of data indication, the receiver takes - full responsibility for the message (see <a href="#section-6.1">section 6.1</a>). Errors that - are diagnosed subsequently MUST be reported in a mail message, as - discussed in <a href="#section-4.4">section 4.4</a>. - - - - - -<span class="grey">Klensin Standards Track [Page 33]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - When the SMTP server accepts a message either for relaying or for - final delivery, it inserts a trace record (also referred to - interchangeably as a "time stamp line" or "Received" line) at the top - of the mail data. This trace record indicates the identity of the - host that sent the message, the identity of the host that received - the message (and is inserting this time stamp), and the date and time - the message was received. Relayed messages will have multiple time - stamp lines. Details for formation of these lines, including their - syntax, is specified in <a href="#section-4.4">section 4.4</a>. - - Additional discussion about the operation of the DATA command appears - in <a href="#section-3.3">section 3.3</a>. - - Syntax: - "DATA" CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.5" href="#section-4.1.1.5">4.1.1.5</a> RESET (RSET)</h5></span> - - This command specifies that the current mail transaction will be - aborted. Any stored sender, recipients, and mail data MUST be - discarded, and all buffers and state tables cleared. The receiver - MUST send a "250 OK" reply to a RSET command with no arguments. A - reset command may be issued by the client at any time. It is - effectively equivalent to a NOOP (i.e., if has no effect) if issued - immediately after EHLO, before EHLO is issued in the session, after - an end-of-data indicator has been sent and acknowledged, or - immediately before a QUIT. An SMTP server MUST NOT close the - connection as the result of receiving a RSET; that action is reserved - for QUIT (see <a href="#section-4.1.1.10">section 4.1.1.10</a>). - - Since EHLO implies some additional processing and response by the - server, RSET will normally be more efficient than reissuing that - command, even though the formal semantics are the same. - - There are circumstances, contrary to the intent of this - specification, in which an SMTP server may receive an indication that - the underlying TCP connection has been closed or reset. To preserve - the robustness of the mail system, SMTP servers SHOULD be prepared - for this condition and SHOULD treat it as if a QUIT had been received - before the connection disappeared. - - Syntax: - "RSET" CRLF - - - - - - - - -<span class="grey">Klensin Standards Track [Page 34]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.6" href="#section-4.1.1.6">4.1.1.6</a> VERIFY (VRFY)</h5></span> - - This command asks the receiver to confirm that the argument - identifies a user or mailbox. If it is a user name, information is - returned as specified in <a href="#section-3.5">section 3.5</a>. - - This command has no effect on the reverse-path buffer, the forward- - path buffer, or the mail data buffer. - - Syntax: - "VRFY" SP String CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.7" href="#section-4.1.1.7">4.1.1.7</a> EXPAND (EXPN)</h5></span> - - This command asks the receiver to confirm that the argument - identifies a mailing list, and if so, to return the membership of - that list. If the command is successful, a reply is returned - containing information as described in <a href="#section-3.5">section 3.5</a>. This reply will - have multiple lines except in the trivial case of a one-member list. - - This command has no effect on the reverse-path buffer, the forward- - path buffer, or the mail data buffer and may be issued at any time. - - Syntax: - "EXPN" SP String CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.8" href="#section-4.1.1.8">4.1.1.8</a> HELP (HELP)</h5></span> - - This command causes the server to send helpful information to the - client. The command MAY take an argument (e.g., any command name) - and return more specific information as a response. - - This command has no effect on the reverse-path buffer, the forward- - path buffer, or the mail data buffer and may be issued at any time. - - SMTP servers SHOULD support HELP without arguments and MAY support it - with arguments. - - Syntax: - "HELP" [ SP String ] CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.9" href="#section-4.1.1.9">4.1.1.9</a> NOOP (NOOP)</h5></span> - - This command does not affect any parameters or previously entered - commands. It specifies no action other than that the receiver send - an OK reply. - - - - - -<span class="grey">Klensin Standards Track [Page 35]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - This command has no effect on the reverse-path buffer, the forward- - path buffer, or the mail data buffer and may be issued at any time. - If a parameter string is specified, servers SHOULD ignore it. - - Syntax: - "NOOP" [ SP String ] CRLF - -<span class="h5"><h5><a class="selflink" name="section-4.1.1.10" href="#section-4.1.1.10">4.1.1.10</a> QUIT (QUIT)</h5></span> - - This command specifies that the receiver MUST send an OK reply, and - then close the transmission channel. - - The receiver MUST NOT intentionally close the transmission channel - until it receives and replies to a QUIT command (even if there was an - error). The sender MUST NOT intentionally close the transmission - channel until it sends a QUIT command and SHOULD wait until it - receives the reply (even if there was an error response to a previous - command). If the connection is closed prematurely due to violations - of the above or system or network failure, the server MUST cancel any - pending transaction, but not undo any previously completed - transaction, and generally MUST act as if the command or transaction - in progress had received a temporary error (i.e., a 4yz response). - - The QUIT command may be issued at any time. - - Syntax: - "QUIT" CRLF - -<span class="h4"><h4><a class="selflink" name="section-4.1.2" href="#section-4.1.2">4.1.2</a> Command Argument Syntax</h4></span> - - The syntax of the argument fields of the above commands (using the - syntax specified in [<a href="#ref-8" title='"Augmented BNF for Syntax Specifications: ABNF"'>8</a>] where applicable) is given below. Some of - the productions given below are used only in conjunction with source - routes as described in <a href="#appendix-C">appendix C</a>. Terminals not defined in this - document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in - the "core" syntax [8 (<a href="#section-6">section 6</a>)] or in the message format syntax - [<a href="#ref-32" title='"Internet Message Format"'>32</a>]. - - Reverse-path = Path - Forward-path = Path - Path = "<" [ A-d-l ":" ] Mailbox ">" - A-d-l = At-domain *( "," A-d-l ) - ; Note that this form, the so-called "source route", - ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be - ; ignored. - At-domain = "@" domain - Mail-parameters = esmtp-param *(SP esmtp-param) - Rcpt-parameters = esmtp-param *(SP esmtp-param) - - - -<span class="grey">Klensin Standards Track [Page 36]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - esmtp-param = esmtp-keyword ["=" esmtp-value] - esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - esmtp-value = 1*(%d33-60 / %d62-127) - ; any CHAR excluding "=", SP, and control characters - Keyword = Ldh-str - Argument = Atom - Domain = (sub-domain 1*("." sub-domain)) / address-literal - sub-domain = Let-dig [Ldh-str] - - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / - General-address-literal "]" - ; See <a href="#section-4.1.3">section 4.1.3</a> - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - ; MAY be case-sensitive - - Dot-string = Atom *("." Atom) - - Atom = 1*atext - - Quoted-string = DQUOTE *qcontent DQUOTE - - String = Atom / Quoted-string - - While the above definition for Local-part is relatively permissive, - for maximum interoperability, a host that expects to receive mail - SHOULD avoid defining mailboxes where the Local-part requires (or - uses) the Quoted-string form or where the Local-part is case- - sensitive. For any purposes that require generating or comparing - Local-parts (e.g., to specific mailbox names), all quoted forms MUST - be treated as equivalent and the sending system SHOULD transmit the - form that uses the minimum quoting possible. - - Systems MUST NOT define mailboxes in such a way as to require the use - in SMTP of non-ASCII characters (octets with the high order bit set - to one) or ASCII "control characters" (decimal value 0-31 and 127). - These characters MUST NOT be used in MAIL or RCPT commands or other - commands that require mailbox names. - - Note that the backslash, "\", is a quote character, which is used to - indicate that the next character is to be used literally (instead of - its normal interpretation). For example, "Joe\,Smith" indicates a - single nine character user field with the comma being the fourth - character of the field. - - - - -<span class="grey">Klensin Standards Track [Page 37]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - To promote interoperability and consistent with long-standing - guidance about conservative use of the DNS in naming and applications - (e.g., see <a href="#section-2.3.1">section 2.3.1</a> of the base DNS document, <a href="http://tools.ietf.org/html/rfc1035">RFC1035</a> [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>]), - characters outside the set of alphas, digits, and hyphen MUST NOT - appear in domain name labels for SMTP clients or servers. In - particular, the underscore character is not permitted. SMTP servers - that receive a command in which invalid character codes have been - employed, and for which there are no other reasons for rejection, - MUST reject that command with a 501 response. - -<span class="h4"><h4><a class="selflink" name="section-4.1.3" href="#section-4.1.3">4.1.3</a> Address Literals</h4></span> - - Sometimes a host is not known to the domain name system and - communication (and, in particular, communication to report and repair - the error) is blocked. To bypass this barrier a special literal form - of the address is allowed as an alternative to a domain name. For - IPv4 addresses, this form uses four small decimal integers separated - by dots and enclosed by brackets such as [123.255.37.2], which - indicates an (IPv4) Internet Address in sequence-of-octets form. For - IPv6 and other forms of addressing that might eventually be - standardized, the form consists of a standardized "tag" that - identifies the address syntax, a colon, and the address itself, in a - format specified as part of the IPv6 standards [<a href="#ref-17" title='"IP Version 6 Addressing Architecture"'>17</a>]. - - Specifically: - - IPv4-address-literal = Snum 3("." Snum) - IPv6-address-literal = "IPv6:" IPv6-addr - General-address-literal = Standardized-tag ":" 1*dcontent - Standardized-tag = Ldh-str - ; MUST be specified in a standards-track RFC - ; and registered with IANA - - Snum = 1*3DIGIT ; representing a decimal integer - ; value in the range 0 through 255 - Let-dig = ALPHA / DIGIT - Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig - - IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp - IPv6-hex = 1*4HEXDIG - IPv6-full = IPv6-hex 7(":" IPv6-hex) - IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" - IPv6-hex)] - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 6 groups in addition to the "::" may be - ; present - IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal - IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" - - - -<span class="grey">Klensin Standards Track [Page 38]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 4 groups in addition to the "::" and - ; IPv4-address-literal may be present - -<span class="h4"><h4><a class="selflink" name="section-4.1.4" href="#section-4.1.4">4.1.4</a> Order of Commands</h4></span> - - There are restrictions on the order in which these commands may be - used. - - A session that will contain mail transactions MUST first be - initialized by the use of the EHLO command. An SMTP server SHOULD - accept commands for non-mail transactions (e.g., VRFY or EXPN) - without this initialization. - - An EHLO command MAY be issued by a client later in the session. If - it is issued after the session begins, the SMTP server MUST clear all - buffers and reset the state exactly as if a RSET command had been - issued. In other words, the sequence of RSET followed immediately by - EHLO is redundant, but not harmful other than in the performance cost - of executing unnecessary commands. - - If the EHLO command is not acceptable to the SMTP server, 501, 500, - or 502 failure replies MUST be returned as appropriate. The SMTP - server MUST stay in the same state after transmitting these replies - that it was in before the EHLO was received. - - The SMTP client MUST, if possible, ensure that the domain parameter - to the EHLO command is a valid principal host name (not a CNAME or MX - name) for its host. If this is not possible (e.g., when the client's - address is dynamically assigned and the client does not have an - obvious name), an address literal SHOULD be substituted for the - domain name and supplemental information provided that will assist in - identifying the client. - - An SMTP server MAY verify that the domain name parameter in the EHLO - command actually corresponds to the IP address of the client. - However, the server MUST NOT refuse to accept a message for this - reason if the verification fails: the information about verification - failure is for logging and tracing only. - - The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time - during a session, or without previously initializing a session. SMTP - servers SHOULD process these normally (that is, not return a 503 - code) even if no EHLO command has yet been received; clients SHOULD - open a session with EHLO before sending these commands. - - - - - -<span class="grey">Klensin Standards Track [Page 39]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - If these rules are followed, the example in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> that shows "550 - access denied to you" in response to an EXPN command is incorrect - unless an EHLO command precedes the EXPN or the denial of access is - based on the client's IP address or other authentication or - authorization-determining mechanisms. - - The MAIL command (or the obsolete SEND, SOML, or SAML commands) - begins a mail transaction. Once started, a mail transaction consists - of a transaction beginning command, one or more RCPT commands, and a - DATA command, in that order. A mail transaction may be aborted by - the RSET (or a new EHLO) command. There may be zero or more - transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be - sent if a mail transaction is already open, i.e., it should be sent - only if no mail transaction had been started in the session, or it - the previous one successfully concluded with a successful DATA - command, or if the previous one was aborted with a RSET. - - If the transaction beginning command argument is not acceptable, a - 501 failure reply MUST be returned and the SMTP server MUST stay in - the same state. If the commands in a transaction are out of order to - the degree that they cannot be processed by the server, a 503 failure - reply MUST be returned and the SMTP server MUST stay in the same - state. - - The last command in a session MUST be the QUIT command. The QUIT - command cannot be used at any other time in a session, but SHOULD be - used by the client SMTP to request connection closure, even when no - session opening command was sent and accepted. - -<span class="h4"><h4><a class="selflink" name="section-4.1.5" href="#section-4.1.5">4.1.5</a> Private-use Commands</h4></span> - - As specified in <a href="#section-2.2.2">section 2.2.2</a>, commands starting in "X" may be used - by bilateral agreement between the client (sending) and server - (receiving) SMTP agents. An SMTP server that does not recognize such - a command is expected to reply with "500 Command not recognized". An - extended SMTP server MAY list the feature names associated with these - private commands in the response to the EHLO command. - - Commands sent or accepted by SMTP systems that do not start with "X" - MUST conform to the requirements of <a href="#section-2.2.2">section 2.2.2</a>. - -<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a> SMTP Replies</h3></span> - - Replies to SMTP commands serve to ensure the synchronization of - requests and actions in the process of mail transfer and to guarantee - that the SMTP client always knows the state of the SMTP server. - Every command MUST generate exactly one reply. - - - - -<span class="grey">Klensin Standards Track [Page 40]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - The details of the command-reply sequence are described in <a href="#section-4.3">section</a> - <a href="#section-4.3">4.3</a>. - - An SMTP reply consists of a three digit number (transmitted as three - numeric characters) followed by some text unless specified otherwise - in this document. The number is for use by automata to determine - what state to enter next; the text is for the human user. The three - digits contain enough encoded information that the SMTP client need - not examine the text and may either discard it or pass it on to the - user, as appropriate. Exceptions are as noted elsewhere in this - document. In particular, the 220, 221, 251, 421, and 551 reply codes - are associated with message text that must be parsed and interpreted - by machines. In the general case, the text may be receiver dependent - and context dependent, so there are likely to be varying texts for - each reply code. A discussion of the theory of reply codes is given - in <a href="#section-4.2.1">section 4.2.1</a>. Formally, a reply is defined to be the sequence: a - three-digit code, <SP>, one line of text, and <CRLF>, or a multiline - reply (as defined in <a href="#section-4.2.1">section 4.2.1</a>). Since, in violation of this - specification, the text is sometimes not sent, clients which do not - receive it SHOULD be prepared to process the code alone (with or - without a trailing space character). Only the EHLO, EXPN, and HELP - commands are expected to result in multiline replies in normal - circumstances, however, multiline replies are allowed for any - command. - - In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - - where "Greeting" appears only in the 220 response that announces that - the server is opening its part of the connection. - - An SMTP server SHOULD send only the reply codes listed in this - document. An SMTP server SHOULD use the text shown in the examples - whenever appropriate. - - An SMTP client MUST determine its actions only by the reply code, not - by the text (except for the "change of address" 251 and 551 and, if - necessary, 220, 221, and 421 replies); in the general case, any text, - including no text at all (although senders SHOULD NOT send bare - codes), MUST be acceptable. The space (blank) following the reply - code is considered part of the text. Whenever possible, a receiver- - SMTP SHOULD test the first digit (severity indication) of the reply - code. - - - - - - -<span class="grey">Klensin Standards Track [Page 41]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - The list of codes that appears below MUST NOT be construed as - permanent. While the addition of new codes should be a rare and - significant activity, with supplemental information in the textual - part of the response being preferred, new codes may be added as the - result of new Standards or Standards-track specifications. - Consequently, a sender-SMTP MUST be prepared to handle codes not - specified in this document and MUST do so by interpreting the first - digit only. - -<span class="h4"><h4><a class="selflink" name="section-4.2.1" href="#section-4.2.1">4.2.1</a> Reply Code Severities and Theory</h4></span> - - The three digits of the reply each have a special significance. The - first digit denotes whether the response is good, bad or incomplete. - An unsophisticated SMTP client, or one that receives an unexpected - code, will be able to determine its next action (proceed as planned, - redo, retrench, etc.) by examining this first digit. An SMTP client - that wants to know approximately what kind of error occurred (e.g., - mail system error, command syntax error) may examine the second - digit. The third digit and any supplemental information that may be - present is reserved for the finest gradation of information. - - There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - The command has been accepted, but the requested action is being - held in abeyance, pending confirmation of the information in this - reply. The SMTP client should send another command specifying - whether to continue or abort the action. Note: unextended SMTP - does not have any commands that allow this type of reply, and so - does not have continue or abort commands. - - 2yz Positive Completion reply - The requested action has been successfully completed. A new - request may be initiated. - - 3yz Positive Intermediate reply - The command has been accepted, but the requested action is being - held in abeyance, pending receipt of further information. The - SMTP client should send another command specifying this - information. This reply is used in command sequence groups (i.e., - in DATA). - - 4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not - occur. However, the error condition is temporary and the action - may be requested again. The sender should return to the beginning - of the command sequence (if any). It is difficult to assign a - meaning to "transient" when two different sites (receiver- and - - - -<span class="grey">Klensin Standards Track [Page 42]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - sender-SMTP agents) must agree on the interpretation. Each reply - in this category might have a different time value, but the SMTP - client is encouraged to try again. A rule of thumb to determine - whether a reply fits into the 4yz or the 5yz category (see below) - is that replies are 4yz if they can be successful if repeated - without any change in command form or in properties of the sender - or receiver (that is, the command is repeated identically and the - receiver does not put up a new implementation.) - - 5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not - occur. The SMTP client is discouraged from repeating the exact - request (in the same sequence). Even some "permanent" error - conditions can be corrected, so the human user may want to direct - the SMTP client to reinitiate the command sequence by direct - action at some point in the future (e.g., after the spelling has - been changed, or the user has altered the account status). - - The second digit encodes responses in specific categories: - - x0z Syntax: These replies refer to syntax errors, syntactically - correct commands that do not fit any functional category, and - unimplemented or superfluous commands. - - x1z Information: These are replies to requests for information, - such as status or help. - - x2z Connections: These are replies referring to the transmission - channel. - - x3z Unspecified. - - x4z Unspecified. - - x5z Mail system: These replies indicate the status of the receiver - mail system vis-a-vis the requested transfer or other mail system - action. - - The third digit gives a finer gradation of meaning in each category - specified by the second digit. The list of replies illustrates this. - Each reply text is recommended rather than mandatory, and may even - change according to the command with which it is associated. On the - other hand, the reply codes must strictly follow the specifications - in this section. Receiver implementations should not invent new - codes for slightly different situations from the ones described here, - but rather adapt codes already defined. - - - - - -<span class="grey">Klensin Standards Track [Page 43]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - For example, a command such as NOOP, whose successful execution does - not offer the SMTP client any new information, will return a 250 - reply. The reply is 502 when the command requests an unimplemented - non-site-specific action. A refinement of that is the 504 reply for - a command that is implemented, but that requests an unimplemented - parameter. - - The reply text may be longer than a single line; in these cases the - complete text must be marked so the SMTP client knows when it can - stop reading the reply. This requires a special format to indicate a - multiple line reply. - - The format for multiline replies requires that every line, except the - last, begin with the reply code, followed immediately by a hyphen, - "-" (also known as minus), followed by text. The last line will - begin with the reply code, followed immediately by <SP>, optionally - some text, and <CRLF>. As noted above, servers SHOULD send the <SP> - if subsequent text is not sent, but clients MUST be prepared for it - to be omitted. - - For example: - - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - - In many cases the SMTP client then simply needs to search for a line - beginning with the reply code followed by <SP> or <CRLF> and ignore - all preceding lines. In a few cases, there is important data for the - client in the reply "text". The client will be able to identify - these cases from the current context. - -<span class="h4"><h4><a class="selflink" name="section-4.2.2" href="#section-4.2.2">4.2.2</a> Reply Codes by Function Groups</h4></span> - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see <a href="#section-4.2.4">section 4.2.4</a>) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - - - -<span class="grey">Klensin Standards Track [Page 44]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See <a href="#section-3.4">section 3.4</a>) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See <a href="#section-3.5.3">section 3.5.3</a>) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See <a href="#section-3.4">section 3.4</a>) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -<span class="h4"><h4><a class="selflink" name="section-4.2.3" href="#section-4.2.3">4.2.3</a> Reply Codes in Numeric Order</h4></span> - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See <a href="#section-3.4">section 3.4</a>) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See <a href="#section-3.5.3">section 3.5.3</a>) - - 354 Start mail input; end with <CRLF>.<CRLF> - - - - - - -<span class="grey">Klensin Standards Track [Page 45]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see <a href="#section-4.2.4">section 4.2.4</a>) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See <a href="#section-3.4">section 3.4</a>) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -<span class="h4"><h4><a class="selflink" name="section-4.2.4" href="#section-4.2.4">4.2.4</a> Reply Code 502</h4></span> - - Questions have been raised as to when reply code 502 (Command not - implemented) SHOULD be returned in preference to other codes. 502 - SHOULD be used when the command is actually recognized by the SMTP - server, but not implemented. If the command is not recognized, code - 500 SHOULD be returned. Extended SMTP systems MUST NOT list - capabilities in response to EHLO for which they will return 502 (or - 500) replies. - -<span class="h4"><h4><a class="selflink" name="section-4.2.5" href="#section-4.2.5">4.2.5</a> Reply Codes After DATA and the Subsequent <CRLF>.<CRLF></h4></span> - - When an SMTP server returns a positive completion status (2yz code) - after the DATA command is completed with <CRLF>.<CRLF>, it accepts - responsibility for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient - conditions, retrying delivery some reasonable number of times at - intervals as specified in <a href="#section-4.5.4">section 4.5.4</a>. - - - - - - -<span class="grey">Klensin Standards Track [Page 46]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - - if attempts to deliver the message fail due to permanent - conditions, or if repeated attempts to deliver the message fail - due to transient conditions, returning appropriate notification to - the sender of the original message (using the address in the SMTP - MAIL command). - - When an SMTP server returns a permanent error status (5yz) code after - the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make - any subsequent attempt to deliver that message. The SMTP client - retains responsibility for delivery of that message and may either - return it to the user or requeue it for a subsequent attempt (see - <a href="#section-4.5.4.1">section 4.5.4.1</a>). - - The user who originated the message SHOULD be able to interpret the - return of a transient failure status (by mail message or otherwise) - as a non-delivery indication, just as a permanent failure would be - interpreted. I.e., if the client SMTP successfully handles these - conditions, the user will not receive such a reply. - - When an SMTP server returns a permanent error status (5yz) code after - the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make - any subsequent attempt to deliver the message. As with temporary - error status codes, the SMTP client retains responsibility for the - message, but SHOULD not again attempt delivery to the same server - without user review and intervention of the message. - -<span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a> Sequencing of Commands and Replies</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-4.3.1" href="#section-4.3.1">4.3.1</a> Sequencing Overview</h4></span> - - The communication between the sender and receiver is an alternating - dialogue, controlled by the sender. As such, the sender issues a - command and the receiver responds with a reply. Unless other - arrangements are negotiated through service extensions, the sender - MUST wait for this response before sending further commands. - - One important reply is the connection greeting. Normally, a receiver - will send a 220 "Service ready" reply when the connection is - completed. The sender SHOULD wait for this greeting message before - sending any commands. - - Note: all the greeting-type replies have the official name (the - fully-qualified primary domain name) of the server host as the first - word following the reply code. Sometimes the host will have no - meaningful name. See 4.1.3 for a discussion of alternatives in these - situations. - - - - - -<span class="grey">Klensin Standards Track [Page 47]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - For example, - - 220 ISIF.USC.EDU Service ready - or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready - or - 220 [10.0.0.1] Clueless host service ready - - The table below lists alternative success and failure replies for - each command. These SHOULD be strictly adhered to: a receiver may - substitute text in the replies, but the meaning and action implied by - the code numbers and by the specific command reply sequence cannot be - altered. - -<span class="h4"><h4><a class="selflink" name="section-4.3.2" href="#section-4.3.2">4.3.2</a> Command-Reply Sequences</h4></span> - - Each command is listed with its usual possible replies. The prefixes - used before the possible replies are "I" for intermediate, "S" for - success, and "E" for error. Since some servers may generate other - replies under special circumstances, and to allow for future - extension, SMTP clients SHOULD, when possible, interpret only the - first digit of the reply and MUST be prepared to deal with - unrecognized reply codes by interpreting the first digit only. - Unless extended using the mechanisms described in <a href="#section-2.2">section 2.2</a>, SMTP - servers MUST NOT transmit reply codes to an SMTP client that are - other than three digits or that do not start in a digit between 2 and - 5 inclusive. - - These sequencing rules and, in principle, the codes themselves, can - be extended or modified by SMTP extensions offered by the server and - accepted (requested) by the client. - - In addition to the codes listed below, any SMTP command can return - any of the following codes if the corresponding unusual circumstances - are encountered: - - 500 For the "command line too long" case or if the command name was - not recognized. Note that producing a "command not recognized" - error in response to the required subset of these commands is a - violation of this specification. - - 501 Syntax error in command or arguments. In order to provide for - future extensions, commands that are specified in this document as - not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 - message if arguments are supplied in the absence of EHLO- - advertised extensions. - - 421 Service shutting down and closing transmission channel - - - -<span class="grey">Klensin Standards Track [Page 48]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - Specific sequences are: - - CONNECTION ESTABLISHMENT - S: 220 - E: 554 - EHLO or HELO - S: 250 - E: 504, 550 - MAIL - S: 250 - E: 552, 451, 452, 550, 553, 503 - RCPT - S: 250, 251 (but see <a href="#section-3.4">section 3.4</a> for discussion of 251 and 551) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 - DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 - RSET - S: 250 - VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 - EXPN - S: 250, 252 - E: 550, 500, 502, 504 - HELP - S: 211, 214 - E: 502, 504 - NOOP - S: 250 - QUIT - S: 221 - -<span class="h3"><h3><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a> Trace Information</h3></span> - - When an SMTP server receives a message for delivery or further - processing, it MUST insert trace ("time stamp" or "Received") - information at the beginning of the message content, as discussed in - <a href="#section-4.1.1.4">section 4.1.1.4</a>. - - This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, - SHOULD contain both (1) the name of the source host as presented - in the EHLO command and (2) an address literal containing the IP - address of the source, determined from the TCP connection. - - - - -<span class="grey">Klensin Standards Track [Page 49]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - - The ID field MAY contain an "@" as suggested in <a href="http://tools.ietf.org/html/rfc822">RFC 822</a>, but this - is not required. - - - The FOR field MAY contain a list of <path> entries when multiple - RCPT commands have been given. This may raise some security - issues and is usually not desirable; see <a href="#section-7.2">section 7.2</a>. - - An Internet mail program MUST NOT change a Received: line that was - previously added to the message header. SMTP servers MUST prepend - Received lines to messages; they MUST NOT change the order of - existing lines or insert Received lines in any other location. - - As the Internet grows, comparability of Received fields is important - for detecting problems, especially slow relays. SMTP servers that - create Received fields SHOULD use explicit offsets in the dates - (e.g., -0800), rather than time zone names of any type. Local time - (with an offset) is preferred to UT when feasible. This formulation - allows slightly more information about local circumstances to be - specified. If UT is needed, the receiver need merely do some simple - arithmetic to convert the values. Use of UT loses information about - the time zone-location of the server. If it is desired to supply a - time zone name, it SHOULD be included in a comment. - - When the delivery SMTP server makes the "final delivery" of a - message, it inserts a return-path line at the beginning of the mail - data. This use of return-path is required; mail systems MUST support - it. The return-path line preserves the information in the <reverse- - path> from the MAIL command. Here, final delivery means the message - has left the SMTP environment. Normally, this would mean it had been - delivered to the destination user or an associated mail drop, but in - some cases it may be further processed and transmitted by another - mail system. - - It is possible for the mailbox in the return path to be different - from the actual sender's mailbox, for example, if error responses are - to be delivered to a special error handling mailbox rather than to - the message sender. When mailing lists are involved, this - arrangement is common and useful as a means of directing errors to - the list maintainer rather than the message originator. - - The text above implies that the final mail data will begin with a - return path line, followed by one or more time stamp lines. These - lines will be followed by the mail data headers and body [<a href="#ref-32" title='"Internet Message Format"'>32</a>]. - - It is sometimes difficult for an SMTP server to determine whether or - not it is making final delivery since forwarding or other operations - may occur after the message is accepted for delivery. Consequently, - - - - -<span class="grey">Klensin Standards Track [Page 50]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - any further (forwarding, gateway, or relay) systems MAY remove the - return path and rebuild the MAIL command as needed to ensure that - exactly one such line appears in a delivered message. - - A message-originating SMTP system SHOULD NOT send a message that - already contains a Return-path header. SMTP servers performing a - relay function MUST NOT inspect the message data, and especially not - to the extent needed to determine if Return-path headers are present. - SMTP servers making final delivery MAY remove Return-path headers - before adding their own. - - The primary purpose of the Return-path is to designate the address to - which messages indicating non-delivery or other mail system failures - are to be sent. For this to be unambiguous, exactly one return path - SHOULD be present when the message is delivered. Systems using <a href="http://tools.ietf.org/html/rfc822">RFC</a> - <a href="http://tools.ietf.org/html/rfc822">822</a> syntax with non-SMTP transports SHOULD designate an unambiguous - address, associated with the transport envelope, to which error - reports (e.g., non-delivery messages) should be sent. - - Historical note: Text in <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> that appears to contradict the use - of the Return-path header (or the envelope reverse path address from - the MAIL command) as the destination for error messages is not - applicable on the Internet. The reverse path address (as copied into - the Return-path) MUST be used as the target of any mail containing - delivery error messages. - - In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses - Internet domain addresses and maintains the envelope sender - address separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path - header present in the message, and either copy that information to - the SMTP envelope or combine it with information present in the - envelope of the other transport system to construct the reverse - path argument to the MAIL command in the SMTP envelope. - - The server must give special treatment to cases in which the - processing following the end of mail data indication is only - partially successful. This could happen if, after accepting several - recipients and the mail data, the SMTP server finds that the mail - data could be successfully delivered to some, but not all, of the - recipients. In such cases, the response to the DATA command MUST be - an OK reply. However, the SMTP server MUST compose and send an - "undeliverable mail" notification message to the originator of the - message. - - - -<span class="grey">Klensin Standards Track [Page 51]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - A single notification listing all of the failed recipients or - separate notification messages MUST be sent for each failed - recipient. For economy of processing by the sender, the former is - preferred when possible. All undeliverable mail notification - messages are sent using the MAIL command (even if they result from - processing the obsolete SEND, SOML, or SAML commands) and use a null - return path as discussed in <a href="#section-3.7">section 3.7</a>. - - The time stamp line and the return path line are formally defined as - follows: - -Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - -Time-stamp-line = "Received:" FWS Stamp <CRLF> - -Stamp = From-domain By-domain Opt-info ";" FWS date-time - - ; where "date-time" is as defined in [<a href="#ref-32" title='"Internet Message Format"'>32</a>] - ; but the "obs-" forms, especially two-digit - ; years, are prohibited in SMTP and MUST NOT be used. - -From-domain = "FROM" FWS Extended-Domain CFWS - -By-domain = "BY" FWS Extended-Domain CFWS - -Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" ) - -TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection - ; not client EHLO. - -Opt-info = [Via] [With] [ID] [For] - -Via = "VIA" FWS Link CFWS - -With = "WITH" FWS Protocol CFWS - -ID = "ID" FWS String / msg-id CFWS - -For = "FOR" FWS 1*( Path / Mailbox ) CFWS - -Link = "TCP" / Addtl-Link -Addtl-Link = Atom - ; Additional standard names for links are registered with the - ; Internet Assigned Numbers Authority (IANA). "Via" is - ; primarily of value with non-Internet transports. SMTP - - - -<span class="grey">Klensin Standards Track [Page 52]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - ; servers SHOULD NOT use unregistered names. -Protocol = "ESMTP" / "SMTP" / Attdl-Protocol -Attdl-Protocol = Atom - ; Additional standard names for protocols are registered with the - ; Internet Assigned Numbers Authority (IANA). SMTP servers - ; SHOULD NOT use unregistered names. - -<span class="h3"><h3><a class="selflink" name="section-4.5" href="#section-4.5">4.5</a> Additional Implementation Issues</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-4.5.1" href="#section-4.5.1">4.5.1</a> Minimum Implementation</h4></span> - - In order to make SMTP workable, the following minimum implementation - is required for all receivers. The following commands MUST be - supported to conform to this specification: - - EHLO - HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - VRFY - - Any system that includes an SMTP server supporting mail relaying or - delivery MUST support the reserved mailbox "postmaster" as a case- - insensitive local name. This postmaster address is not strictly - necessary if the server always returns 554 on connection opening (as - described in <a href="#section-3.1">section 3.1</a>). The requirement to accept mail for - postmaster implies that RCPT commands which specify a mailbox for - postmaster at any of the domains for which the SMTP server provides - mail service, as well as the special case of "RCPT TO:<Postmaster>" - (with no domain specification), MUST be supported. - - SMTP systems are expected to make every reasonable effort to accept - mail directed to Postmaster from any other system on the Internet. - In extreme cases --such as to contain a denial of service attack or - other breach of security-- an SMTP server may block mail directed to - Postmaster. However, such arrangements SHOULD be narrowly tailored - so as to avoid blocking messages which are not part of such attacks. - -<span class="h4"><h4><a class="selflink" name="section-4.5.2" href="#section-4.5.2">4.5.2</a> Transparency</h4></span> - - Without some provision for data transparency, the character sequence - "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. - In general, users are not aware of such "forbidden" sequences. To - - - - -<span class="grey">Klensin Standards Track [Page 53]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - allow all user composed text to be transmitted transparently, the - following procedures are used: - - - Before sending a line of mail text, the SMTP client checks the - first character of the line. If it is a period, one additional - period is inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks - the line. If the line is composed of a single period, it is - treated as the end of mail indicator. If the first character is a - period and there are other characters on the line, the first - character is deleted. - - The mail data may contain any of the 128 ASCII characters. All - characters are to be delivered to the recipient's mailbox, including - spaces, vertical and horizontal tabs, and other control characters. - If the transmission channel provides an 8-bit byte (octet) data - stream, the 7-bit ASCII codes are transmitted right justified in the - octets, with the high order bits cleared to zero. See 3.7 for - special treatment of these conditions in SMTP systems serving a relay - function. - - In some systems it may be necessary to transform the data as it is - received and stored. This may be necessary for hosts that use a - different character set than ASCII as their local character set, that - store data in records rather than strings, or which use special - character sequences as delimiters inside mailboxes. If such - transformations are necessary, they MUST be reversible, especially if - they are applied to mail being relayed. - -<span class="h4"><h4><a class="selflink" name="section-4.5.3" href="#section-4.5.3">4.5.3</a> Sizes and Timeouts</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-4.5.3.1" href="#section-4.5.3.1">4.5.3.1</a> Size limits and minimums</h5></span> - - There are several objects that have required minimum/maximum sizes. - Every implementation MUST be able to receive objects of at least - these sizes. Objects larger than these sizes SHOULD be avoided when - possible. However, some Internet mail constructs such as encoded - X.400 addresses [<a href="#ref-16" title='"Mapping between X.400 and RFC822/MIME"'>16</a>] will often require larger objects: clients MAY - attempt to transmit these, but MUST be prepared for a server to - reject them if they cannot be handled by it. To the maximum extent - possible, implementation techniques which impose no limits on the - length of these objects should be used. - - local-part - The maximum total length of a user name or other local-part is 64 - characters. - - - - -<span class="grey">Klensin Standards Track [Page 54]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - domain - The maximum total length of a domain name or number is 255 - characters. - - path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - - command line - The maximum total length of a command line including the command - word and the <CRLF> is 512 characters. SMTP extensions may be - used to increase this limit. - - reply line - The maximum total length of a reply line including the reply code - and the <CRLF> is 512 characters. More information may be - conveyed through multiple-line replies. - - text line - The maximum total length of a text line including the <CRLF> is - 1000 characters (not counting the leading dot duplicated for - transparency). This number may be increased by the use of SMTP - Service Extensions. - - message content - The maximum total length of a message content (including any - message headers as well as the message body) MUST BE at least 64K - octets. Since the introduction of Internet standards for - multimedia mail [<a href="#ref-12" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>12</a>], message lengths on the Internet have grown - dramatically, and message size restrictions should be avoided if - at all possible. SMTP server systems that must impose - restrictions SHOULD implement the "SIZE" service extension [<a href="#ref-18" title='"SMTP Service Extension for Message Size Declaration"'>18</a>], - and SMTP client systems that will send large messages SHOULD - utilize it when possible. - - recipients buffer - The minimum total number of recipients that must be buffered is - 100 recipients. Rejection of messages (for excessive recipients) - with fewer than 100 RCPT commands is a violation of this - specification. The general principle that relaying SMTP servers - MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation - tests on message headers suggests that rejecting a message based - on the total number of recipients shown in header fields is to be - discouraged. A server which imposes a limit on the number of - recipients MUST behave in an orderly fashion, such as to reject - additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - - - - -<span class="grey">Klensin Standards Track [Page 55]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - deliver a message containing over 100 RCPT commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server - declines to accept more than 100 recipients in a single message. - - Errors due to exceeding these limits may be reported by using the - reply codes. Some examples of reply codes are: - - 500 Line too long. - or - 501 Path too long - or - 452 Too many recipients (see below) - or - 552 Too much mail data. - - <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> [<a href="#ref-30" title='"Simple Mail Transfer Protocol"'>30</a>] incorrectly listed the error where an SMTP server - exhausts its implementation limit on the number of RCPT commands - ("too many recipients") as having reply code 552. The correct reply - code for this condition is 452. Clients SHOULD treat a 552 code in - this case as a temporary, rather than permanent, failure so the logic - below works. - - When a conforming SMTP server encounters this condition, it has at - least 100 successful RCPT commands in its recipients buffer. If the - server is able to accept the message, then at least these 100 - addresses will be removed from the SMTP client's queue. When the - client attempts retransmission of those addresses which received 452 - responses, at least 100 of these will be able to fit in the SMTP - server's recipients buffer. Each retransmission attempt which is - able to deliver anything will be able to dispose of at least 100 of - these recipients. - - If an SMTP server has an implementation limit on the number of RCPT - commands and this limit is exhausted, it MUST use a response code of - 452 (but the client SHOULD also be prepared for a 552, as noted - above). If the server has a configured site-policy limitation on the - number of RCPT commands, it MAY instead use a 5XX response code. - This would be most appropriate if the policy limitation was intended - to apply if the total recipient count for a particular message body - were enforced even if that message body was sent in multiple mail - transactions. - -<span class="h5"><h5><a class="selflink" name="section-4.5.3.2" href="#section-4.5.3.2">4.5.3.2</a> Timeouts</h5></span> - - An SMTP client MUST provide a timeout mechanism. It MUST use per- - command timeouts rather than somehow trying to time the entire mail - transaction. Timeouts SHOULD be easily reconfigurable, preferably - without recompiling the SMTP code. To implement this, a timer is set - - - -<span class="grey">Klensin Standards Track [Page 56]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - for each SMTP command and for each buffer of the data transfer. The - latter means that the overall timeout is inherently proportional to - the size of the message. - - Based on extensive experience with busy mail-relay hosts, the minimum - per-command timeout values SHOULD be as follows: - - Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting - message. Many SMTP servers accept a TCP connection but delay - delivery of the 220 message until their system load permits more - mail to be processed. - - MAIL Command: 5 minutes - - RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and - aliases is not deferred until after the message was accepted. - - DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA - command. - - Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call - transmitting a chunk of data. - - DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets - the final period terminating the message data, it typically - performs processing to deliver the message to a user mailbox. A - spurious timeout at this point would be very wasteful and would - typically result in delivery of multiple copies of the message, - since it has been successfully sent and the server has accepted - responsibility for delivery. See <a href="#section-6.1">section 6.1</a> for additional - discussion. - - An SMTP server SHOULD have a timeout of at least 5 minutes while it - is awaiting the next command from the sender. - -<span class="h4"><h4><a class="selflink" name="section-4.5.4" href="#section-4.5.4">4.5.4</a> Retry Strategies</h4></span> - - The common structure of a host SMTP implementation includes user - mailboxes, one or more areas for queuing messages in transit, and one - or more daemon processes for sending and receiving mail. The exact - structure will vary depending on the needs of the users on the host - - - - -<span class="grey">Klensin Standards Track [Page 57]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - and the number and size of mailing lists supported by the host. We - describe several optimizations that have proved helpful, particularly - for mailers supporting high traffic levels. - - Any queuing strategy MUST include timeouts on all activities on a - per-command basis. A queuing strategy MUST NOT send error messages - in response to error messages under any circumstances. - -<span class="h5"><h5><a class="selflink" name="section-4.5.4.1" href="#section-4.5.4.1">4.5.4.1</a> Sending Strategy</h5></span> - - The general model for an SMTP client is one or more processes that - periodically attempt to transmit outgoing mail. In a typical system, - the program that composes a message has some method for requesting - immediate attention for a new piece of outgoing mail, while mail that - cannot be transmitted immediately MUST be queued and periodically - retried by the sender. A mail queue entry will include not only the - message itself but also the envelope information. - - The sender MUST delay retrying a particular destination after one - attempt has failed. In general, the retry interval SHOULD be at - least 30 minutes; however, more sophisticated and variable strategies - will be beneficial when the SMTP client can determine the reason for - non-delivery. - - Retries continue until the message is transmitted or the sender gives - up; the give-up time generally needs to be at least 4-5 days. The - parameters to the retry algorithm MUST be configurable. - - A client SHOULD keep a list of hosts it cannot reach and - corresponding connection timeouts, rather than just retrying queued - mail items. - - Experience suggests that failures are typically transient (the target - system or its connection has crashed), favoring a policy of two - connection attempts in the first hour the message is in the queue, - and then backing off to one every two or three hours. - - The SMTP client can shorten the queuing delay in cooperation with the - SMTP server. For example, if mail is received from a particular - address, it is likely that mail queued for that host can now be sent. - Application of this principle may, in many cases, eliminate the - requirement for an explicit "send queues now" function such as ETRN - [<a href="#ref-9" title='"SMTP Service Extension for Remote Message Queue Starting"'>9</a>]. - - The strategy may be further modified as a result of multiple - addresses per host (see below) to optimize delivery time vs. resource - usage. - - - - -<span class="grey">Klensin Standards Track [Page 58]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - An SMTP client may have a large queue of messages for each - unavailable destination host. If all of these messages were retried - in every retry cycle, there would be excessive Internet overhead and - the sending system would be blocked for a long period. Note that an - SMTP client can generally determine that a delivery attempt has - failed only after a timeout of several minutes and even a one-minute - timeout per connection will result in a very large delay if retries - are repeated for dozens, or even hundreds, of queued messages to the - same host. - - At the same time, SMTP clients SHOULD use great care in caching - negative responses from servers. In an extreme case, if EHLO is - issued multiple times during the same SMTP connection, different - answers may be returned by the server. More significantly, 5yz - responses to the MAIL command MUST NOT be cached. - - When a mail message is to be delivered to multiple recipients, and - the SMTP server to which a copy of the message is to be sent is the - same for multiple recipients, then only one copy of the message - SHOULD be transmitted. That is, the SMTP client SHOULD use the - command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the - sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there - are very many addresses, a limit on the number of RCPT commands per - MAIL command MAY be imposed. Implementation of this efficiency - feature is strongly encouraged. - - Similarly, to achieve timely delivery, the SMTP client MAY support - multiple concurrent outgoing mail transactions. However, some limit - may be appropriate to protect the host from devoting all its - resources to mail. - -<span class="h5"><h5><a class="selflink" name="section-4.5.4.2" href="#section-4.5.4.2">4.5.4.2</a> Receiving Strategy</h5></span> - - The SMTP server SHOULD attempt to keep a pending listen on the SMTP - port at all times. This requires the support of multiple incoming - TCP connections for SMTP. Some limit MAY be imposed but servers that - cannot handle more than one SMTP transaction at a time are not in - conformance with the intent of this specification. - - As discussed above, when the SMTP server receives mail from a - particular host address, it could activate its own SMTP queuing - mechanisms to retry any mail pending for that host address. - -<span class="h4"><h4><a class="selflink" name="section-4.5.5" href="#section-4.5.5">4.5.5</a> Messages with a null reverse-path</h4></span> - - There are several types of notification messages which are required - by existing and proposed standards to be sent with a null reverse - path, namely non-delivery notifications as discussed in <a href="#section-3.7">section 3.7</a>, - - - -<span class="grey">Klensin Standards Track [Page 59]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - other kinds of Delivery Status Notifications (DSNs) [<a href="#ref-24" title='"SMTP Service Extension for Delivery Status Notifications"'>24</a>], and also - Message Disposition Notifications (MDNs) [<a href="#ref-10" title='"An Extensible Message Format for Message Disposition Notifications"'>10</a>]. All of these kinds of - messages are notifications about a previous message, and they are - sent to the reverse-path of the previous mail message. (If the - delivery of such a notification message fails, that usually indicates - a problem with the mail system of the host to which the notification - message is addressed. For this reason, at some hosts the MTA is set - up to forward such failed notification messages to someone who is - able to fix problems with the mail system, e.g., via the postmaster - alias.) - - All other types of messages (i.e., any message which is not required - by a standards-track RFC to have a null reverse-path) SHOULD be sent - with with a valid, non-null reverse-path. - - Implementors of automated email processors should be careful to make - sure that the various kinds of messages with null reverse-path are - handled correctly, in particular such systems SHOULD NOT reply to - messages with null reverse-path. - -<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. Address Resolution and Mail Handling</h2></span> - - Once an SMTP client lexically identifies a domain to which mail will - be delivered for processing (as described in sections <a href="#section-3.6">3.6</a> and <a href="#section-3.7">3.7</a>), a - DNS lookup MUST be performed to resolve the domain name [<a href="#ref-22" title='"Domain names - implementation and specification"'>22</a>]. The - names are expected to be fully-qualified domain names (FQDNs): - mechanisms for inferring FQDNs from partial names or local aliases - are outside of this specification and, due to a history of problems, - are generally discouraged. The lookup first attempts to locate an MX - record associated with the name. If a CNAME record is found instead, - the resulting name is processed as if it were the initial name. If - no MX records are found, but an A RR is found, the A RR is treated as - if it was associated with an implicit MX RR, with a preference of 0, - pointing to that host. If one or more MX RRs are found for a given - name, SMTP systems MUST NOT utilize any A RRs associated with that - name unless they are located using the MX RRs; the "implicit MX" rule - above applies only if there are no MX records present. If MX records - are present, but none of them are usable, this situation MUST be - reported as an error. - - When the lookup succeeds, the mapping can result in a list of - alternative delivery addresses rather than a single address, because - of multiple MX records, multihoming, or both. To provide reliable - mail transmission, the SMTP client MUST be able to try (and retry) - each of the relevant addresses in this list in order, until a - delivery attempt succeeds. However, there MAY also be a configurable - limit on the number of alternate addresses that can be tried. In any - case, the SMTP client SHOULD try at least two addresses. - - - -<span class="grey">Klensin Standards Track [Page 60]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - Two types of information is used to rank the host addresses: multiple - MX records, and multihomed hosts. - - Multiple MX records contain a preference indication that MUST be used - in sorting (see below). Lower numbers are more preferred than higher - ones. If there are multiple destinations with the same preference - and there is no clear reason to favor one (e.g., by recognition of an - easily-reached address), then the sender-SMTP MUST randomize them to - spread the load across multiple mail exchangers for a specific - organization. - - The destination host (perhaps taken from the preferred MX record) may - be multihomed, in which case the domain name resolver will return a - list of alternative IP addresses. It is the responsibility of the - domain name resolver interface to have ordered this list by - decreasing preference if necessary, and SMTP MUST try them in the - order presented. - - Although the capability to try multiple alternative addresses is - required, specific installations may want to limit or disable the use - of alternative addresses. The question of whether a sender should - attempt retries using the different addresses of a multihomed host - has been controversial. The main argument for using the multiple - addresses is that it maximizes the probability of timely delivery, - and indeed sometimes the probability of any delivery; the counter- - argument is that it may result in unnecessary resource use. Note - that resource use is also strongly determined by the sending strategy - discussed in <a href="#section-4.5.4.1">section 4.5.4.1</a>. - - If an SMTP server receives a message with a destination for which it - is a designated Mail eXchanger, it MAY relay the message (potentially - after having rewritten the MAIL FROM and/or RCPT TO addresses), make - final delivery of the message, or hand it off using some mechanism - outside the SMTP-provided transport environment. Of course, neither - of the latter require that the list of MX records be examined - further. - - If it determines that it should relay the message without rewriting - the address, it MUST sort the MX records to determine candidates for - delivery. The records are first ordered by preference, with the - lowest-numbered records being most preferred. The relay host MUST - then inspect the list for any of the names or addresses by which it - might be known in mail transactions. If a matching record is found, - all records at that preference level and higher-numbered ones MUST be - discarded from consideration. If there are no records left at that - point, it is an error condition, and the message MUST be returned as - undeliverable. If records do remain, they SHOULD be tried, best - preference first, as described above. - - - -<span class="grey">Klensin Standards Track [Page 61]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>. Problem Detection and Handling</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-6.1" href="#section-6.1">6.1</a> Reliable Delivery and Replies by Email</h3></span> - - When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" - message in response to DATA), it is accepting responsibility for - delivering or relaying the message. It must take this responsibility - seriously. It MUST NOT lose the message for frivolous reasons, such - as because the host later crashes or because of a predictable - resource shortage. - - If there is a delivery failure after acceptance of a message, the - receiver-SMTP MUST formulate and mail a notification message. This - notification MUST be sent using a null ("<>") reverse path in the - envelope. The recipient of this notification MUST be the address - from the envelope return path (or the Return-Path: line). However, - if this address is null ("<>"), the receiver-SMTP MUST NOT send a - notification. Obviously, nothing in this section can or should - prohibit local decisions (i.e., as part of the same system - environment as the receiver-SMTP) to log or otherwise transmit - information about null address events locally if that is desired. If - the address is an explicit source route, it MUST be stripped down to - its final hop. - - For example, suppose that an error notification must be sent for a - message that arrived with: - - MAIL FROM:<@a,@b:user@d> - - The notification message MUST be sent using: - - RCPT TO:<user@d> - - Some delivery failures after the message is accepted by SMTP will be - unavoidable. For example, it may be impossible for the receiving - SMTP server to validate all the delivery addresses in RCPT command(s) - due to a "soft" domain system error, because the target is a mailing - list (see earlier discussion of RCPT), or because the server is - acting as a relay and has no immediate access to the delivering - system. - - To avoid receiving duplicate messages as the result of timeouts, a - receiver-SMTP MUST seek to minimize the time required to respond to - the final <CRLF>.<CRLF> end of data indicator. See <a href="http://tools.ietf.org/html/rfc1047">RFC 1047</a> [<a href="#ref-28" title='"Duplicate messages and SMTP"'>28</a>] for - a discussion of this problem. - - - - - - -<span class="grey">Klensin Standards Track [Page 62]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h3"><h3><a class="selflink" name="section-6.2" href="#section-6.2">6.2</a> Loop Detection</h3></span> - - Simple counting of the number of "Received:" headers in a message has - proven to be an effective, although rarely optimal, method of - detecting loops in mail systems. SMTP servers using this technique - SHOULD use a large rejection threshold, normally at least 100 - Received entries. Whatever mechanisms are used, servers MUST contain - provisions for detecting and stopping trivial loops. - -<span class="h3"><h3><a class="selflink" name="section-6.3" href="#section-6.3">6.3</a> Compensating for Irregularities</h3></span> - - Unfortunately, variations, creative interpretations, and outright - violations of Internet mail protocols do occur; some would suggest - that they occur quite frequently. The debate as to whether a well- - behaved SMTP receiver or relay should reject a malformed message, - attempt to pass it on unchanged, or attempt to repair it to increase - the odds of successful delivery (or subsequent reply) began almost - with the dawn of structured network mail and shows no signs of - abating. Advocates of rejection claim that attempted repairs are - rarely completely adequate and that rejection of bad messages is the - only way to get the offending software repaired. Advocates of - "repair" or "deliver no matter what" argue that users prefer that - mail go through it if at all possible and that there are significant - market pressures in that direction. In practice, these market - pressures may be more important to particular vendors than strict - conformance to the standards, regardless of the preference of the - actual developers. - - The problems associated with ill-formed messages were exacerbated by - the introduction of the split-UA mail reading protocols [3, 26, 5, - 21]. These protocols have encouraged the use of SMTP as a posting - protocol, and SMTP servers as relay systems for these client hosts - (which are often only intermittently connected to the Internet). - Historically, many of those client machines lacked some of the - mechanisms and information assumed by SMTP (and indeed, by the mail - format protocol [<a href="#ref-7" title='"Standard for the Format of ARPA Internet Text Messages"'>7</a>]). Some could not keep adequate track of time; - others had no concept of time zones; still others could not identify - their own names or addresses; and, of course, none could satisfy the - assumptions that underlay <a href="http://tools.ietf.org/html/rfc822">RFC 822</a>'s conception of authenticated - addresses. - - In response to these weak SMTP clients, many SMTP systems now - complete messages that are delivered to them in incomplete or - incorrect form. This strategy is generally considered appropriate - when the server can identify or authenticate the client, and there - are prior agreements between them. By contrast, there is at best - great concern about fixes applied by a relay or delivery SMTP server - that has little or no knowledge of the user or client machine. - - - -<span class="grey">Klensin Standards Track [Page 63]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - The following changes to a message being processed MAY be applied - when necessary by an originating SMTP server, or one used as the - target of SMTP as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - - The less information the server has about the client, the less likely - these changes are to be correct and the more caution and conservatism - should be applied when considering whether or not to perform fixes - and how. These changes MUST NOT be applied by an SMTP server that - provides an intermediate relay function. - - In all cases, properly-operating clients supplying correct - information are preferred to corrections by the SMTP server. In all - cases, documentation of actions performed by the servers (in trace - fields and/or header comments) is strongly encouraged. - -<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>. Security Considerations</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a> Mail Security and Spoofing</h3></span> - - SMTP mail is inherently insecure in that it is feasible for even - fairly casual users to negotiate directly with receiving and relaying - SMTP servers and create messages that will trick a naive recipient - into believing that they came from somewhere else. Constructing such - a message so that the "spoofed" behavior cannot be detected by an - expert is somewhat more difficult, but not sufficiently so as to be a - deterrent to someone who is determined and knowledgeable. - Consequently, as knowledge of Internet mail increases, so does the - knowledge that SMTP mail inherently cannot be authenticated, or - integrity checks provided, at the transport level. Real mail - security lies only in end-to-end methods involving the message - bodies, such as those which use digital signatures (see [<a href="#ref-14" title='"Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"'>14</a>] and, - e.g., PGP [<a href="#ref-4" title='"OpenPGP Message Format"'>4</a>] or S/MIME [<a href="#ref-31" title='"S/MIME Version 3 Message Specification"'>31</a>]). - - Various protocol extensions and configuration options that provide - authentication at the transport level (e.g., from an SMTP client to - an SMTP server) improve somewhat on the traditional situation - described above. However, unless they are accompanied by careful - handoffs of responsibility in a carefully-designed trust environment, - they remain inherently weaker than end-to-end mechanisms which use - digitally signed messages rather than depending on the integrity of - the transport system. - - - - -<span class="grey">Klensin Standards Track [Page 64]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - Efforts to make it more difficult for users to set envelope return - path and header "From" fields to point to valid addresses other than - their own are largely misguided: they frustrate legitimate - applications in which mail is sent by one user on behalf of another - or in which error (or normal) replies should be directed to a special - address. (Systems that provide convenient ways for users to alter - these fields on a per-message basis should attempt to establish a - primary and permanent mailbox address for the user so that Sender - fields within the message data can be generated sensibly.) - - This specification does not further address the authentication issues - associated with SMTP other than to advocate that useful functionality - not be disabled in the hope of providing some small margin of - protection against an ignorant user who is trying to fake mail. - -<span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a> "Blind" Copies</h3></span> - - Addresses that do not appear in the message headers may appear in the - RCPT commands to an SMTP server for a number of reasons. The two - most common involve the use of a mailing address as a "list exploder" - (a single address that resolves into multiple addresses) and the - appearance of "blind copies". Especially when more than one RCPT - command is present, and in order to avoid defeating some of the - purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy - the full set of RCPT command arguments into the headers, either as - part of trace headers or as informational or private-extension - headers. Since this rule is often violated in practice, and cannot - be enforced, sending SMTP systems that are aware of "bcc" use MAY - find it helpful to send each blind copy as a separate message - transaction containing only a single RCPT command. - - There is no inherent relationship between either "reverse" (from - MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP - transaction ("envelope") and the addresses in the headers. Receiving - systems SHOULD NOT attempt to deduce such relationships and use them - to alter the headers of the message for delivery. The popular - "Apparently-to" header is a violation of this principle as well as a - common source of unintended information disclosure and SHOULD NOT be - used. - -<span class="h3"><h3><a class="selflink" name="section-7.3" href="#section-7.3">7.3</a> VRFY, EXPN, and Security</h3></span> - - As discussed in <a href="#section-3.5">section 3.5</a>, individual sites may want to disable - either or both of VRFY or EXPN for security reasons. As a corollary - to the above, implementations that permit this MUST NOT appear to - have verified addresses that are not, in fact, verified. If a site - - - - - -<span class="grey">Klensin Standards Track [Page 65]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - disables these commands for security reasons, the SMTP server MUST - return a 252 response, rather than a code that could be confused with - successful or unsuccessful verification. - - Returning a 250 reply code with the address listed in the VRFY - command after having checked it only for syntax violates this rule. - Of course, an implementation that "supports" VRFY by always returning - 550 whether or not the address is valid is equally not in - conformance. - - Within the last few years, the contents of mailing lists have become - popular as an address information source for so-called "spammers." - The use of EXPN to "harvest" addresses has increased as list - administrators have installed protections against inappropriate uses - of the lists themselves. Implementations SHOULD still provide - support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. - As authentication mechanisms are introduced into SMTP, some sites may - choose to make EXPN available only to authenticated requestors. - -<span class="h3"><h3><a class="selflink" name="section-7.4" href="#section-7.4">7.4</a> Information Disclosure in Announcements</h3></span> - - There has been an ongoing debate about the tradeoffs between the - debugging advantages of announcing server type and version (and, - sometimes, even server domain name) in the greeting response or in - response to the HELP command and the disadvantages of exposing - information that might be useful in a potential hostile attack. The - utility of the debugging information is beyond doubt. Those who - argue for making it available point out that it is far better to - actually secure an SMTP server rather than hope that trying to - conceal known vulnerabilities by hiding the server's precise identity - will provide more protection. Sites are encouraged to evaluate the - tradeoff with that issue in mind; implementations are strongly - encouraged to minimally provide for making type and version - information available in some way to other network hosts. - -<span class="h3"><h3><a class="selflink" name="section-7.5" href="#section-7.5">7.5</a> Information Disclosure in Trace Fields</h3></span> - - In some circumstances, such as when mail originates from within a LAN - whose hosts are not directly on the public Internet, trace - ("Received") fields produced in conformance with this specification - may disclose host names and similar information that would not - normally be available. This ordinarily does not pose a problem, but - sites with special concerns about name disclosure should be aware of - it. Also, the optional FOR clause should be supplied with caution or - not at all when multiple recipients are involved lest it - inadvertently disclose the identities of "blind copy" recipients to - others. - - - - -<span class="grey">Klensin Standards Track [Page 66]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h3"><h3><a class="selflink" name="section-7.6" href="#section-7.6">7.6</a> Information Disclosure in Message Forwarding</h3></span> - - As discussed in <a href="#section-3.4">section 3.4</a>, use of the 251 or 551 reply codes to - identify the replacement address associated with a mailbox may - inadvertently disclose sensitive information. Sites that are - concerned about those issues should ensure that they select and - configure servers appropriately. - -<span class="h3"><h3><a class="selflink" name="section-7.7" href="#section-7.7">7.7</a> Scope of Operation of SMTP Servers</h3></span> - - It is a well-established principle that an SMTP server may refuse to - accept mail for any operational or technical reason that makes sense - to the site providing the server. However, cooperation among sites - and installations makes the Internet possible. If sites take - excessive advantage of the right to reject traffic, the ubiquity of - email availability (one of the strengths of the Internet) will be - threatened; considerable care should be taken and balance maintained - if a site decides to be selective about the traffic it will accept - and process. - - In recent years, use of the relay function through arbitrary sites - has been used as part of hostile efforts to hide the actual origins - of mail. Some sites have decided to limit the use of the relay - function to known or identifiable sources, and implementations SHOULD - provide the capability to perform this type of filtering. When mail - is rejected for these or other policy reasons, a 550 code SHOULD be - used in response to EHLO, MAIL, or RCPT as appropriate. - -<span class="h2"><h2><a class="selflink" name="section-8" href="#section-8">8</a>. IANA Considerations</h2></span> - - IANA will maintain three registries in support of this specification. - The first consists of SMTP service extensions with the associated - keywords, and, as needed, parameters and verbs. As specified in - <a href="#section-2.2.2">section 2.2.2</a>, no entry may be made in this registry that starts in - an "X". Entries may be made only for service extensions (and - associated keywords, parameters, or verbs) that are defined in - standards-track or experimental RFCs specifically approved by the - IESG for this purpose. - - The second registry consists of "tags" that identify forms of domain - literals other than those for IPv4 addresses (specified in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> - and in this document) and IPv6 addresses (specified in this - document). Additional literal types require standardization before - being used; none are anticipated at this time. - - The third, established by <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> and renewed by this specification, - is a registry of link and protocol identifiers to be used with the - "via" and "with" subclauses of the time stamp ("Received: header") - - - -<span class="grey">Klensin Standards Track [Page 67]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - described in <a href="#section-4.4">section 4.4</a>. Link and protocol identifiers in addition - to those specified in this document may be registered only by - standardization or by way of an RFC-documented, IESG-approved, - Experimental protocol extension. - -<span class="h2"><h2><a class="selflink" name="section-9" href="#section-9">9</a>. References</h2></span> - - [<a name="ref-1" id="ref-1">1</a>] American National Standards Institute (formerly United States of - America Standards Institute), X3.4, 1968, "USA Code for - Information Interchange". ANSI X3.4-1968 has been replaced by - newer versions with slight modifications, but the 1968 version - remains definitive for the Internet. - - [<a name="ref-2" id="ref-2">2</a>] Braden, R., "Requirements for Internet hosts - application and - support", STD 3, <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a>, October 1989. - - [<a name="ref-3" id="ref-3">3</a>] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. - Reynolds, "Post Office Protocol - version 2", <a href="http://tools.ietf.org/html/rfc937">RFC 937</a>, February - 1985. - - [<a name="ref-4" id="ref-4">4</a>] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP - Message Format", <a href="http://tools.ietf.org/html/rfc2440">RFC 2440</a>, November 1998. - - [<a name="ref-5" id="ref-5">5</a>] Crispin, M., "Interactive Mail Access Protocol - Version 2", <a href="http://tools.ietf.org/html/rfc1176">RFC</a> - <a href="http://tools.ietf.org/html/rfc1176">1176</a>, August 1990. - - [<a name="ref-6" id="ref-6">6</a>] Crispin, M., "Internet Message Access Protocol - Version 4", <a href="http://tools.ietf.org/html/rfc2060">RFC</a> - <a href="http://tools.ietf.org/html/rfc2060">2060</a>, December 1996. - - [<a name="ref-7" id="ref-7">7</a>] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", <a href="http://tools.ietf.org/html/rfc822">RFC 822</a>, August 1982. - - [<a name="ref-8" id="ref-8">8</a>] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax - Specifications: ABNF", <a href="http://tools.ietf.org/html/rfc2234">RFC 2234</a>, November 1997. - - [<a name="ref-9" id="ref-9">9</a>] De Winter, J., "SMTP Service Extension for Remote Message Queue - Starting", <a href="http://tools.ietf.org/html/rfc1985">RFC 1985</a>, August 1996. - - [<a name="ref-10" id="ref-10">10</a>] Fajman, R., "An Extensible Message Format for Message - Disposition Notifications", <a href="http://tools.ietf.org/html/rfc2298">RFC 2298</a>, March 1998. - - [<a name="ref-11" id="ref-11">11</a>] Freed, N, "Behavior of and Requirements for Internet Firewalls", - <a href="http://tools.ietf.org/html/rfc2979">RFC 2979</a>, October 2000. - - [<a name="ref-12" id="ref-12">12</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - <a href="http://tools.ietf.org/html/rfc2045">RFC 2045</a>, December 1996. - - - - -<span class="grey">Klensin Standards Track [Page 68]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - [<a name="ref-13" id="ref-13">13</a>] Freed, N., "SMTP Service Extension for Command Pipelining", <a href="http://tools.ietf.org/html/rfc2920">RFC</a> - <a href="http://tools.ietf.org/html/rfc2920">2920</a>, September 2000. - - [<a name="ref-14" id="ref-14">14</a>] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security - Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", - <a href="http://tools.ietf.org/html/rfc1847">RFC 1847</a>, October 1995. - - [<a name="ref-15" id="ref-15">15</a>] Gellens, R. and J. Klensin, "Message Submission", <a href="http://tools.ietf.org/html/rfc2476">RFC 2476</a>, - December 1998. - - [<a name="ref-16" id="ref-16">16</a>] Kille, S., "Mapping between X.400 and <a href="http://tools.ietf.org/html/rfc822">RFC822</a>/MIME", <a href="http://tools.ietf.org/html/rfc2156">RFC 2156</a>, - January 1998. - - [<a name="ref-17" id="ref-17">17</a>] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing - Architecture", <a href="http://tools.ietf.org/html/rfc2373">RFC 2373</a>, July 1998. - - [<a name="ref-18" id="ref-18">18</a>] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for - Message Size Declaration", STD 10, <a href="http://tools.ietf.org/html/rfc1870">RFC 1870</a>, November 1995. - - [<a name="ref-19" id="ref-19">19</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, - "SMTP Service Extensions", STD 10, <a href="http://tools.ietf.org/html/rfc1869">RFC 1869</a>, November 1995. - - [<a name="ref-20" id="ref-20">20</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, - "SMTP Service Extension for 8bit-MIMEtransport", <a href="http://tools.ietf.org/html/rfc1652">RFC 1652</a>, July - 1994. - - [<a name="ref-21" id="ref-21">21</a>] Lambert, M., "PCMAIL: A distributed mail system for personal - computers", <a href="http://tools.ietf.org/html/rfc1056">RFC 1056</a>, July 1988. - - [<a name="ref-22" id="ref-22">22</a>] Mockapetris, P., "Domain names - implementation and - specification", STD 13, <a href="http://tools.ietf.org/html/rfc1035">RFC 1035</a>, November 1987. - - Mockapetris, P., "Domain names - concepts and facilities", STD - 13, <a href="http://tools.ietf.org/html/rfc1034">RFC 1034</a>, November 1987. - - [<a name="ref-23" id="ref-23">23</a>] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part - Three: Message Header Extensions for Non-ASCII Text", <a href="http://tools.ietf.org/html/rfc2047">RFC 2047</a>, - December 1996. - - [<a name="ref-24" id="ref-24">24</a>] Moore, K., "SMTP Service Extension for Delivery Status - Notifications", <a href="http://tools.ietf.org/html/rfc1891">RFC 1891</a>, January 1996. - - [<a name="ref-25" id="ref-25">25</a>] Moore, K., and G. Vaudreuil, "An Extensible Message Format for - Delivery Status Notifications", <a href="http://tools.ietf.org/html/rfc1894">RFC 1894</a>, January 1996. - - [<a name="ref-26" id="ref-26">26</a>] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD - 53, <a href="http://tools.ietf.org/html/rfc1939">RFC 1939</a>, May 1996. - - - - -<span class="grey">Klensin Standards Track [Page 69]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - [<a name="ref-27" id="ref-27">27</a>] Partridge, C., "Mail routing and the domain system", <a href="http://tools.ietf.org/html/rfc974">RFC 974</a>, - January 1986. - - [<a name="ref-28" id="ref-28">28</a>] Partridge, C., "Duplicate messages and SMTP", <a href="http://tools.ietf.org/html/rfc1047">RFC 1047</a>, February - 1988. - - [<a name="ref-29" id="ref-29">29</a>] Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", STD 7, <a href="http://tools.ietf.org/html/rfc793">RFC 793</a>, September 1981. - - [<a name="ref-30" id="ref-30">30</a>] Postel, J., "Simple Mail Transfer Protocol", <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>, August - 1982. - - [<a name="ref-31" id="ref-31">31</a>] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", <a href="http://tools.ietf.org/html/rfc2633">RFC</a> - <a href="http://tools.ietf.org/html/rfc2633">2633</a>, June 1999. - - [<a name="ref-32" id="ref-32">32</a>] Resnick, P., Ed., "Internet Message Format", <a href="http://tools.ietf.org/html/rfc2822">RFC 2822</a>, April - 2001. - - [<a name="ref-33" id="ref-33">33</a>] Vaudreuil, G., "SMTP Service Extensions for Transmission of - Large and Binary MIME Messages", <a href="http://tools.ietf.org/html/rfc1830">RFC 1830</a>, August 1995. - - [<a name="ref-34" id="ref-34">34</a>] Vaudreuil, G., "Enhanced Mail System Status Codes", <a href="http://tools.ietf.org/html/rfc1893">RFC 1893</a>, - January 1996. - -<span class="h2"><h2><a class="selflink" name="section-10" href="#section-10">10</a>. Editor's Address</h2></span> - - John C. Klensin - AT&T Laboratories - 99 Bedford St - Boston, MA 02111 USA - - Phone: 617-574-3076 - EMail: klensin@research.att.com - -<span class="h2"><h2><a class="selflink" name="section-11" href="#section-11">11</a>. Acknowledgments</h2></span> - - Many people worked long and hard on the many iterations of this - document. There was wide-ranging debate in the IETF DRUMS Working - Group, both on its mailing list and in face to face discussions, - about many technical issues and the role of a revised standard for - Internet mail transport, and many contributors helped form the - wording in this specification. The hundreds of participants in the - many discussions since <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> was produced are too numerous to - mention, but they all helped this document become what it is. - - - - - - - -<span class="grey">Klensin Standards Track [Page 70]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -APPENDICES - -<span class="h1"><h1><a class="selflink" name="appendix-A" href="#appendix-A">A</a>. TCP Transport Service</h1></span> - - The TCP connection supports the transmission of 8-bit bytes. The - SMTP data is 7-bit ASCII characters. Each character is transmitted - as an 8-bit byte with the high-order bit cleared to zero. Service - extensions may modify this rule to permit transmission of full 8-bit - data bytes as part of the message body, but not in SMTP commands or - responses. - -<span class="h1"><h1><a class="selflink" name="appendix-B" href="#appendix-B">B</a>. Generating SMTP Commands from <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> Headers</h1></span> - - Some systems use <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> headers (only) in a mail submission - protocol, or otherwise generate SMTP commands from <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> headers - when such a message is handed to an MTA from a UA. While the MTA-UA - protocol is a private matter, not covered by any Internet Standard, - there are problems with this approach. For example, there have been - repeated problems with proper handling of "bcc" copies and - redistribution lists when information that conceptually belongs to a - mail envelopes is not separated early in processing from header - information (and kept separate). - - It is recommended that the UA provide its initial ("submission - client") MTA with an envelope separate from the message itself. - However, if the envelope is not supplied, SMTP commands SHOULD be - generated as follows: - - 1. Each recipient address from a TO, CC, or BCC header field SHOULD - be copied to a RCPT command (generating multiple message copies if - that is required for queuing or delivery). This includes any - addresses listed in a <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> "group". Any BCC fields SHOULD then - be removed from the headers. Once this process is completed, the - remaining headers SHOULD be checked to verify that at least one - To:, Cc:, or Bcc: header remains. If none do, then a bcc: header - with no additional information SHOULD be inserted as specified in - [<a href="#ref-32" title='"Internet Message Format"'>32</a>]. - - 2. The return address in the MAIL command SHOULD, if possible, be - derived from the system's identity for the submitting (local) - user, and the "From:" header field otherwise. If there is a - system identity available, it SHOULD also be copied to the Sender - header field if it is different from the address in the From - header field. (Any Sender field that was already there SHOULD be - removed.) Systems may provide a way for submitters to override - the envelope return address, but may want to restrict its use to - privileged users. This will not prevent mail forgery, but may - lessen its incidence; see <a href="#section-7.1">section 7.1</a>. - - - -<span class="grey">Klensin Standards Track [Page 71]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - When an MTA is being used in this way, it bears responsibility for - ensuring that the message being transmitted is valid. The mechanisms - for checking that validity, and for handling (or returning) messages - that are not valid at the time of arrival, are part of the MUA-MTA - interface and not covered by this specification. - - A submission protocol based on Standard <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> information alone - MUST NOT be used to gateway a message from a foreign (non-SMTP) mail - system into an SMTP environment. Additional information to construct - an envelope must come from some source in the other environment, - whether supplemental headers or the foreign system's envelope. - - Attempts to gateway messages using only their header "to" and "cc" - fields have repeatedly caused mail loops and other behavior adverse - to the proper functioning of the Internet mail environment. These - problems have been especially common when the message originates from - an Internet mailing list and is distributed into the foreign - environment using envelope information. When these messages are then - processed by a header-only remailer, loops back to the Internet - environment (and the mailing list) are almost inevitable. - -<span class="h1"><h1><a class="selflink" name="appendix-C" href="#appendix-C">C</a>. Source Routes</h1></span> - - Historically, the <reverse-path> was a reverse source routing list of - hosts and a source mailbox. The first host in the <reverse-path> - SHOULD be the host sending the MAIL command. Similarly, the - <forward-path> may be a source routing lists of hosts and a - destination mailbox. However, in general, the <forward-path> SHOULD - contain only a mailbox and domain name, relying on the domain name - system to supply routing information if required. The use of source - routes is deprecated; while servers MUST be prepared to receive and - handle them as discussed in <a href="#section-3.3">section 3.3</a> and F.2, clients SHOULD NOT - transmit them and this section was included only to provide context. - - For relay purposes, the forward-path may be a source route of the - form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully- - qualified domain names. This form is used to emphasize the - distinction between an address and a route. The mailbox is an - absolute address, and the route is information about how to get - there. The two concepts should not be confused. - - If source routes are used, <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> and the text below should be - consulted for the mechanisms for constructing and updating the - forward- and reverse-paths. - - - - - - - -<span class="grey">Klensin Standards Track [Page 72]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - The SMTP server transforms the command arguments by moving its own - identifier (its domain name or that of any domain for which it is - acting as a mail exchanger), if it appears, from the forward-path to - the beginning of the reverse-path. - - Notice that the forward-path and reverse-path appear in the SMTP - commands and replies, but not necessarily in the message. That is, - there is no need for these paths and especially this syntax to appear - in the "To:" , "From:", "CC:", etc. fields of the message header. - Conversely, SMTP servers MUST NOT derive final message delivery - information from message header fields. - - When the list of hosts is present, it is a "reverse" source route and - indicates that the mail was relayed through each host on the list - (the first host in the list was the most recent relay). This list is - used as a source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, it MUST - use its name as known in the transport environment to which it is - relaying the mail rather than that of the transport environment from - which the mail came (if they are different). - -<span class="h1"><h1><a class="selflink" name="appendix-D" href="#appendix-D">D</a>. Scenarios</h1></span> - - This section presents complete scenarios of several types of SMTP - sessions. In the examples, "C:" indicates what is said by the SMTP - client, and "S:" indicates what is said by the SMTP server. - -<span class="h1"><h1><a class="selflink" name="appendix-D.1" href="#appendix-D.1">D.1</a> A Typical SMTP Transaction Scenario</h1></span> - - This SMTP example shows mail sent by Smith at host bar.com, to Jones, - Green, and Brown at host foo.com. Here we assume that host bar.com - contacts host foo.com directly. The mail is accepted for Jones and - Brown. Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - - - -<span class="grey">Klensin Standards Track [Page 73]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -<span class="h1"><h1><a class="selflink" name="appendix-D.2" href="#appendix-D.2">D.2</a> Aborted SMTP Transaction Scenario</h1></span> - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -<span class="h1"><h1><a class="selflink" name="appendix-D.3" href="#appendix-D.3">D.3</a> Relayed Mail Scenario</h1></span> - - Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - - - -<span class="grey">Klensin Standards Track [Page 74]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 - C: 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -<span class="h1"><h1><a class="selflink" name="appendix-D.4" href="#appendix-D.4">D.4</a> Verifying and Sending Scenario</h1></span> - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - - - -<span class="grey">Klensin Standards Track [Page 75]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - - S: 250-VRFY - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -<span class="h1"><h1><a class="selflink" name="appendix-E" href="#appendix-E">E</a>. Other Gateway Issues</h1></span> - - In general, gateways between the Internet and other mail systems - SHOULD attempt to preserve any layering semantics across the - boundaries between the two mail systems involved. Gateway- - translation approaches that attempt to take shortcuts by mapping, - (such as envelope information from one system to the message headers - or body of another) have generally proven to be inadequate in - important ways. Systems translating between environments that do not - support both envelopes and headers and Internet mail must be written - with the understanding that some information loss is almost - inevitable. - -<span class="h1"><h1><a class="selflink" name="appendix-F" href="#appendix-F">F</a>. Deprecated Features of <a href="http://tools.ietf.org/html/rfc821">RFC 821</a></h1></span> - - A few features of <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> have proven to be problematic and SHOULD - NOT be used in Internet mail. - -<span class="h1"><h1><a class="selflink" name="appendix-F.1" href="#appendix-F.1">F.1</a> TURN</h1></span> - - This command, described in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a>, raises important security issues - since, in the absence of strong authentication of the host requesting - that the client and server switch roles, it can easily be used to - divert mail from its correct destination. Its use is deprecated; - SMTP systems SHOULD NOT use it unless the server can authenticate the - client. - - - - - - - - -<span class="grey">Klensin Standards Track [Page 76]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h1"><h1><a class="selflink" name="appendix-F.2" href="#appendix-F.2">F.2</a> Source Routing</h1></span> - - <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> utilized the concept of explicit source routing to get mail - from one host to another via a series of relays. The requirement to - utilize source routes in regular mail traffic was eliminated by the - introduction of the domain name system "MX" record and the last - significant justification for them was eliminated by the - introduction, in <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a>, of a clear requirement that addresses - following an "@" must all be fully-qualified domain names. - Consequently, the only remaining justifications for the use of source - routes are support for very old SMTP clients or MUAs and in mail - system debugging. They can, however, still be useful in the latter - circumstance and for routing mail around serious, but temporary, - problems such as problems with the relevant DNS records. - - SMTP servers MUST continue to accept source route syntax as specified - in the main body of this document and in <a href="http://tools.ietf.org/html/rfc1123">RFC 1123</a>. They MAY, if - necessary, ignore the routes and utilize only the target domain in - the address. If they do utilize the source route, the message MUST - be sent to the first domain shown in the address. In particular, a - server MUST NOT guess at shortcuts within the source route. - - Clients SHOULD NOT utilize explicit source routing except under - unusual circumstances, such as debugging or potentially relaying - around firewall or mail system configuration errors. - -<span class="h1"><h1><a class="selflink" name="appendix-F.3" href="#appendix-F.3">F.3</a> HELO</h1></span> - - As discussed in sections <a href="#section-3.1">3.1</a> and <a href="#section-4.1.1">4.1.1</a>, EHLO is strongly preferred to - HELO when the server will accept the former. Servers must continue - to accept and process HELO in order to support older clients. - -<span class="h1"><h1><a class="selflink" name="appendix-F.4" href="#appendix-F.4">F.4</a> #-literals</h1></span> - - <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> provided for specifying an Internet address as a decimal - integer host number prefixed by a pound sign, "#". In practice, that - form has been obsolete since the introduction of TCP/IP. It is - deprecated and MUST NOT be used. - -<span class="h1"><h1><a class="selflink" name="appendix-F.5" href="#appendix-F.5">F.5</a> Dates and Years</h1></span> - - When dates are inserted into messages by SMTP clients or servers - (e.g., in trace fields), four-digit years MUST BE used. Two-digit - years are deprecated; three-digit years were never permitted in the - Internet mail system. - - - - - - -<span class="grey">Klensin Standards Track [Page 77]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -<span class="h1"><h1><a class="selflink" name="appendix-F.6" href="#appendix-F.6">F.6</a> Sending versus Mailing</h1></span> - - In addition to specifying a mechanism for delivering messages to - user's mailboxes, <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> provided additional, optional, commands to - deliver messages directly to the user's terminal screen. These - commands (SEND, SAML, SOML) were rarely implemented, and changes in - workstation technology and the introduction of other protocols may - have rendered them obsolete even where they are implemented. - - Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers - MAY implement them. If they are implemented by servers, the - implementation model specified in <a href="http://tools.ietf.org/html/rfc821">RFC 821</a> MUST be used and the - command names MUST be published in the response to the EHLO command. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<span class="grey">Klensin Standards Track [Page 78]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a> -<span class="grey"><a href="#">RFC 2821</a> Simple Mail Transfer Protocol April 2001</span> - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Klensin Standards Track [Page 79] - -</pre><br> -<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.109, available from -<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> -</small></small></span> - -</body></html>
\ No newline at end of file diff --git a/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html b/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html deleted file mode 100644 index 7ded014..0000000 --- a/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html +++ /dev/null @@ -1,7068 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> -<meta http-equiv="content-type" content="text/html; charset=UTF-8"> - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - <meta name="robots" content="index,follow"> - <meta name="creator" content="rfcmarkup version 1.109"> - <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> -<meta name="DC.Relation.Replaces" content="rfc977"> -<meta name="DC.Identifier" content="urn:ietf:rfc:3977"> -<meta name="DC.Date.Issued" content="October, 2006"> -<meta name="DC.Creator" content="Clive D.W. Feather <clive@demon.net>"> -<meta name="DC.Description.Abstract" content="The Network News Transfer Protocol (NNTP) has been in use in the\nInternet for a decade, and remains one of the most popular protocols\n(by volume) in use today. This document is a replacement for RFC 977,\nand officially updates the protocol specification. It clarifies some\nvagueness in RFC 977, includes some new base functionality, and\nprovides a specific mechanism to add standardized extensions to NNTP.\n[STANDARDS-TRACK]"> -<meta name="DC.Title" content="Network News Transfer Protocol (NNTP)"> - - <link rel="icon" href="index_files/rfc.png" type="image/png"> - <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> - <title>RFC 3977 - Network News Transfer Protocol (NNTP)</title> - - - <style type="text/css"><!--
-/* Effective stylesheet produced by snapshot save */
-body { margin: 0px 8px; font-size: 1em; }
-h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
-pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
-.pre { white-space: pre; font-family: monospace; }
-.newpage { page-break-before: always; }
-.invisible { text-decoration: none; color: white; }
-a.selflink { color: black; text-decoration: none; }
-@media print {
- body { font-family: monospace; font-size: 10.5pt; }
- h1, h2, h3, h4, h5, h6 { font-size: 1em; }
- a:link, a:visited { color: inherit; text-decoration: none; }
- .noprint { display: none; }
-}
-@media screen {
- .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
- .docinfo { background-color: rgb(238, 238, 238); }
- .top { border-top: 7px solid rgb(238, 238, 238); }
- .bgblue { background-color: rgb(102, 102, 255); }
- .legend { font-size: 90%; }
-}
---></style> - <!--[if IE]> - <style> - body { - font-size: 13px; - margin: 10px 10px; - } - </style> - <![endif]--> - - <script type="text/javascript"><!--
-/* Script removed by snapshot save */
---></script> -</head> -<body onload=""> - <div style="height: 13px;"> - <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgblue" title="Click for colour legend."> </div> - <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> - </div> - </div> -<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc3977.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc3977" title="PDF version of this document">pdf</a>] [<a href="https://tools.ietf.org/html/draft-ietf-nntpext-base" title="draft-ietf-nntpext-base">draft-ietf-nntpex...</a>] [<a href="https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc3977" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://tools.ietf.org/rfcdiff?url2=rfc3977" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=3977">Errata</a>] </span><br> -<span class="pre noprint docinfo"> </span><br> -<span class="pre noprint docinfo">Updated by: <a href="https://tools.ietf.org/html/rfc6048">6048</a> PROPOSED STANDARD</span><br> -<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br> -<pre>Network Working Group C. Feather -Request for Comments: 3977 THUS plc -Obsoletes: <a href="https://tools.ietf.org/html/rfc977">977</a> October 2006 -Updates: <a href="https://tools.ietf.org/html/rfc2980">2980</a> -Category: Standards Track - - - <span class="h1"><h1>Network News Transfer Protocol (NNTP)</h1></span> - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Network News Transfer Protocol (NNTP) has been in use in the - Internet for a decade, and remains one of the most popular protocols - (by volume) in use today. This document is a replacement for - <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, and officially updates the protocol specification. It - clarifies some vagueness in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, includes some new base - functionality, and provides a specific mechanism to add standardized - extensions to NNTP. - -Table of Contents - - <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a> - <a href="#section-1.1">1.1</a>. Author's Note . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a> - <a href="#section-2">2</a>. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a> - <a href="#section-3">3</a>. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> - <a href="#section-3.1">3.1</a>. Commands and Responses . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> - <a href="#section-3.1.1">3.1.1</a>. Multi-line Data Blocks . . . . . . . . . . . . . . . . <a href="#page-8">8</a> - <a href="#section-3.2">3.2</a>. Response Codes . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a> - <a href="#section-3.2.1">3.2.1</a>. Generic Response Codes . . . . . . . . . . . . . . . <a href="#page-10">10</a> - <a href="#section-3.2.1.1">3.2.1.1</a>. Examples . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a> - <a href="#section-3.3">3.3</a>. Capabilities and Extensions . . . . . . . . . . . . . . . <a href="#page-14">14</a> - <a href="#section-3.3.1">3.3.1</a>. Capability Descriptions . . . . . . . . . . . . . . . <a href="#page-14">14</a> - <a href="#section-3.3.2">3.3.2</a>. Standard Capabilities . . . . . . . . . . . . . . . . <a href="#page-15">15</a> - <a href="#section-3.3.3">3.3.3</a>. Extensions . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a> - <a href="#section-3.3.4">3.3.4</a>. Initial IANA Register . . . . . . . . . . . . . . . . <a href="#page-18">18</a> - <a href="#section-3.4">3.4</a>. Mandatory and Optional Commands . . . . . . . . . . . . . <a href="#page-20">20</a> - - - -<span class="grey">Feather Standards Track [Page 1]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - <a href="#section-3.4.1">3.4.1</a>. Reading and Transit Servers . . . . . . . . . . . . . <a href="#page-21">21</a> - <a href="#section-3.4.2">3.4.2</a>. Mode Switching . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a> - <a href="#section-3.5">3.5</a>. Pipelining . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> - <a href="#section-3.5.1">3.5.1</a>. Examples . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a> - <a href="#section-3.6">3.6</a>. Articles . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a> - <a href="#section-4">4</a>. The WILDMAT Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a> - <a href="#section-4.1">4.1</a>. Wildmat Syntax . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a> - <a href="#section-4.2">4.2</a>. Wildmat Semantics . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a> - <a href="#section-4.3">4.3</a>. Extensions . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a> - <a href="#section-4.4">4.4</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a> - <a href="#section-5">5</a>. Session Administration Commands . . . . . . . . . . . . . . . <a href="#page-28">28</a> - <a href="#section-5.1">5.1</a>. Initial Connection . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a> - <a href="#section-5.2">5.2</a>. CAPABILITIES . . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a> - <a href="#section-5.3">5.3</a>. MODE READER . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a> - <a href="#section-5.4">5.4</a>. QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a> - <a href="#section-6">6</a>. Article Posting and Retrieval . . . . . . . . . . . . . . . . <a href="#page-35">35</a> - <a href="#section-6.1">6.1</a>. Group and Article Selection . . . . . . . . . . . . . . . <a href="#page-36">36</a> - <a href="#section-6.1.1">6.1.1</a>. GROUP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a> - <a href="#section-6.1.2">6.1.2</a>. LISTGROUP . . . . . . . . . . . . . . . . . . . . . . <a href="#page-39">39</a> - <a href="#section-6.1.3">6.1.3</a>. LAST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-42">42</a> - <a href="#section-6.1.4">6.1.4</a>. NEXT . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-44">44</a> - <a href="#section-6.2">6.2</a>. Retrieval of Articles and Article Sections . . . . . . . <a href="#page-45">45</a> - <a href="#section-6.2.1">6.2.1</a>. ARTICLE . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-46">46</a> - <a href="#section-6.2.2">6.2.2</a>. HEAD . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-49">49</a> - <a href="#section-6.2.3">6.2.3</a>. BODY . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-51">51</a> - <a href="#section-6.2.4">6.2.4</a>. STAT . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-53">53</a> - <a href="#section-6.3">6.3</a>. Article Posting . . . . . . . . . . . . . . . . . . . . . <a href="#page-56">56</a> - <a href="#section-6.3.1">6.3.1</a>. POST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-56">56</a> - <a href="#section-6.3.2">6.3.2</a>. IHAVE . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-58">58</a> - <a href="#section-7">7</a>. Information Commands . . . . . . . . . . . . . . . . . . . . <a href="#page-61">61</a> - <a href="#section-7.1">7.1</a>. DATE . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-61">61</a> - <a href="#section-7.2">7.2</a>. HELP . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-62">62</a> - <a href="#section-7.3">7.3</a>. NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-63">63</a> - <a href="#section-7.4">7.4</a>. NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-64">64</a> - <a href="#section-7.5">7.5</a>. Time . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-65">65</a> - <a href="#section-7.5.1">7.5.1</a>. Examples . . . . . . . . . . . . . . . . . . . . . . <a href="#page-66">66</a> - <a href="#section-7.6">7.6</a>. The LIST Commands . . . . . . . . . . . . . . . . . . . . <a href="#page-66">66</a> - <a href="#section-7.6.1">7.6.1</a>. LIST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-67">67</a> - <a href="#section-7.6.2">7.6.2</a>. Standard LIST Keywords . . . . . . . . . . . . . . . <a href="#page-69">69</a> - <a href="#section-7.6.3">7.6.3</a>. LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . <a href="#page-70">70</a> - <a href="#section-7.6.4">7.6.4</a>. LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . <a href="#page-71">71</a> - <a href="#section-7.6.5">7.6.5</a>. LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . <a href="#page-72">72</a> - <a href="#section-7.6.6">7.6.6</a>. LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . <a href="#page-73">73</a> - <a href="#section-8">8</a>. Article Field Access Commands . . . . . . . . . . . . . . . . <a href="#page-73">73</a> - <a href="#section-8.1">8.1</a>. Article Metadata . . . . . . . . . . . . . . . . . . . . <a href="#page-74">74</a> - <a href="#section-8.1.1">8.1.1</a>. The :bytes Metadata Item . . . . . . . . . . . . . . <a href="#page-74">74</a> - <a href="#section-8.1.2">8.1.2</a>. The :lines Metadata Item . . . . . . . . . . . . . . <a href="#page-75">75</a> - <a href="#section-8.2">8.2</a>. Database Consistency . . . . . . . . . . . . . . . . . . <a href="#page-75">75</a> - - - -<span class="grey">Feather Standards Track [Page 2]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - <a href="#section-8.3">8.3</a>. OVER . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-76">76</a> - <a href="#section-8.4">8.4</a>. LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . <a href="#page-81">81</a> - <a href="#section-8.5">8.5</a>. HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-83">83</a> - <a href="#section-8.6">8.6</a>. LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . <a href="#page-87">87</a> - <a href="#section-9">9</a>. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . . <a href="#page-90">90</a> - <a href="#section-9.1">9.1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . <a href="#page-90">90</a> - <a href="#section-9.2">9.2</a>. Commands . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-92">92</a> - <a href="#section-9.3">9.3</a>. Command Continuation . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> - <a href="#section-9.4">9.4</a>. Responses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> - <a href="#section-9.4.1">9.4.1</a>. Generic Responses . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> - <a href="#section-9.4.2">9.4.2</a>. Initial Response Line Contents . . . . . . . . . . . <a href="#page-94">94</a> - <a href="#section-9.4.3">9.4.3</a>. Multi-line Response Contents . . . . . . . . . . . . <a href="#page-94">94</a> - <a href="#section-9.5">9.5</a>. Capability Lines . . . . . . . . . . . . . . . . . . . . <a href="#page-95">95</a> - <a href="#section-9.6">9.6</a>. LIST Variants . . . . . . . . . . . . . . . . . . . . . . <a href="#page-96">96</a> - <a href="#section-9.7">9.7</a>. Articles . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> - <a href="#section-9.8">9.8</a>. General Non-terminals . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> - <a href="#section-9.9">9.9</a>. Extensions and Validation . . . . . . . . . . . . . . . . <a href="#page-99">99</a> - <a href="#section-10">10</a>. Internationalisation Considerations . . . . . . . . . . . . .<a href="#page-100">100</a> - <a href="#section-10.1">10.1</a>. Introduction and Historical Situation . . . . . . . . . .<a href="#page-100">100</a> - <a href="#section-10.2">10.2</a>. This Specification . . . . . . . . . . . . . . . . . . .<a href="#page-101">101</a> - <a href="#section-10.3">10.3</a>. Outstanding Issues . . . . . . . . . . . . . . . . . . .<a href="#page-102">102</a> - <a href="#section-11">11</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . .<a href="#page-103">103</a> - <a href="#section-12">12</a>. Security Considerations . . . . . . . . . . . . . . . . . . .<a href="#page-103">103</a> - <a href="#section-12.1">12.1</a>. Personal and Proprietary Information . . . . . . . . . .<a href="#page-104">104</a> - <a href="#section-12.2">12.2</a>. Abuse of Server Log Information . . . . . . . . . . . . .<a href="#page-104">104</a> - <a href="#section-12.3">12.3</a>. Weak Authentication and Access Control . . . . . . . . .<a href="#page-104">104</a> - <a href="#section-12.4">12.4</a>. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . .<a href="#page-104">104</a> - <a href="#section-12.5">12.5</a>. UTF-8 Issues . . . . . . . . . . . . . . . . . . . . . .<a href="#page-105">105</a> - <a href="#section-12.6">12.6</a>. Caching of Capability Lists . . . . . . . . . . . . . . .<a href="#page-106">106</a> - <a href="#section-13">13</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .<a href="#page-107">107</a> - <a href="#section-14">14</a>. References . . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> - <a href="#section-14.1">14.1</a>. Normative References . . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> - <a href="#section-14.2">14.2</a>. Informative References . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> - <a href="#appendix-A">A</a>. Interaction with Other Specifications . . . . . . . . . . . .<a href="#page-112">112</a> - <a href="#appendix-A.1">A.1</a>. Header Folding . . . . . . . . . . . . . . . . . . . . .<a href="#page-112">112</a> - <a href="#appendix-A.2">A.2</a>. Message-IDs . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-112">112</a> - <a href="#appendix-A.3">A.3</a>. Article Posting . . . . . . . . . . . . . . . . . . . . .<a href="#page-114">114</a> - <a href="#appendix-B">B</a>. Summary of Commands . . . . . . . . . . . . . . . . . . . . .<a href="#page-115">115</a> - <a href="#appendix-C">C</a>. Summary of Response Codes . . . . . . . . . . . . . . . . . .<a href="#page-117">117</a> - <a href="#appendix-D">D</a>. Changes from <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> . . . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a> - -<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> - - This document specifies the Network News Transfer Protocol (NNTP), - which is used for the distribution, inquiry, retrieval, and posting - of Netnews articles using a reliable stream-based mechanism. For - news-reading clients, NNTP enables retrieval of news articles that - - - - -<span class="grey">Feather Standards Track [Page 3]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - are stored in a central database, giving subscribers the ability to - select only those articles they wish to read. - - The Netnews model provides for indexing, cross-referencing, and - expiration of aged messages. NNTP is designed for efficient - transmission of Netnews articles over a reliable full duplex - communication channel. - - Although the protocol specification in this document is largely - compatible with the version specified in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>], a number - of changes are summarised in <a href="#appendix-D">Appendix D</a>. In particular: - - o the default character set is changed from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to - UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] (note that US-ASCII is a subset of UTF-8); - - o a number of commands that were optional in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> or that have - been taken from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> [<a href="https://tools.ietf.org/html/rfc2980" title='"Common NNTP Extensions"'>RFC2980</a>] are now mandatory; and - - o a CAPABILITIES command has been added to allow clients to - determine what functionality is available from a server. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a> [<a href="https://tools.ietf.org/html/rfc2119" title='"Key words for use in RFCs to Indicate Requirement Levels"'>RFC2119</a>]. - - An implementation is not compliant if it fails to satisfy one or more - of the MUST requirements for this protocol. An implementation that - satisfies all the MUST and all the SHOULD requirements for its - protocols is said to be "unconditionally compliant"; one that - satisfies all the MUST requirements but not all the SHOULD - requirements for NNTP is said to be "conditionally compliant". - - For the remainder of this document, the terms "client" and "client - host" refer to a host making use of the NNTP service, while the terms - "server" and "server host" refer to a host that offers the NNTP - service. - -<span class="h3"><h3><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Author's Note</h3></span> - - This document is written in XML using an NNTP-specific DTD. Custom - software is used to convert this to <a href="https://tools.ietf.org/html/rfc2629">RFC 2629</a> [<a href="https://tools.ietf.org/html/rfc2629" title='"Writing I-Ds and RFCs using XML"'>RFC2629</a>] format, and - then the public "xml2rfc" package to further reduce this to text, - nroff source, and HTML. - - No perl was used in producing this document. - - - - - - -<span class="grey">Feather Standards Track [Page 4]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Notation</h2></span> - - The following notational conventions are used in this document. - - UPPERCASE indicates literal text to be included in the - command. - - lowercase indicates a token described elsewhere. - - [<a name="ref-brackets" id="ref-brackets">brackets</a>] indicate that the enclosed material is optional. - - elliptical indicates that the argument may be repeated any - ... marks number of times (it must occur at least once). - - vertical|bar indicates a choice of two mutually exclusive - arguments (exactly one must be provided). - - The name "message-id" for a command or response argument indicates - that it is the message-id of an article as described in <a href="#section-3.6">Section 3.6</a>, - including the angle brackets. - - The name "wildmat" for an argument indicates that it is a wildmat as - defined in <a href="#section-4">Section 4</a>. If the argument does not meet the requirements - of that section (for example, if it does not fit the grammar of - <a href="#section-4.1">Section 4.1</a>), the NNTP server MAY place some interpretation on it - (not specified by this document) or otherwise MUST treat it as a - syntax error. - - Responses for each command will be described in tables listing the - required format of a response followed by the meaning that should be - ascribed to that response. - - The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets - %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets - with those codes in US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] and thus in UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]). - The term "CRLF" or "CRLF pair" means the sequence CR immediately - followed by LF (that is, %x0D.0A). A "printable US-ASCII character" - is an octet in the range %x21-7E. Quoted characters refer to the - octets with those codes in US-ASCII (so "." and "<" refer to %x2E and - %x3C) and will always be printable US-ASCII characters; similarly, - "digit" refers to the octets %x30-39. - - A "keyword" MUST consist only of US-ASCII letters, digits, and the - characters dot (".") and dash ("-") and MUST begin with a letter. - Keywords MUST be at least three characters in length. - - - - - - -<span class="grey">Feather Standards Track [Page 5]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Examples in this document are not normative but serve to illustrate - usages, arguments, and responses. In the examples, a "[<a href="#ref-C" title='"Demo User"'>C</a>]" will be - used to represent the client host and an "[S]" will be used to - represent the server host. Most of the examples do not rely on a - particular server state. In some cases, however, they do assume that - the currently selected newsgroup (see the GROUP command, - <a href="#section-6.1.1">Section 6.1.1</a>) is invalid; when so, this is indicated at the start of - the example. Examples may use commands or other keywords not defined - in this specification (such as an XENCRYPT command). These will be - used to illustrate some point and do not imply that any such command - is defined elsewhere or needs to exist in any particular - implementation. - - Terms that might be read as specifying details of a client or server - implementation, such as "database", are used simply to ease - description. Provided that implementations conform to the protocol - and format specifications in this document, no specific technique is - mandated. - -<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. Basic Concepts</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Commands and Responses</h3></span> - - NNTP operates over any reliable bi-directional 8-bit-wide data stream - channel. When the connection is established, the NNTP server host - MUST send a greeting. The client host and server host then exchange - commands and responses (respectively) until the connection is closed - or aborted. If the connection used is TCP, then the server host - starts the NNTP service by listening on a TCP port. When a client - host wishes to make use of the service, it MUST establish a TCP - connection with the server host by connecting to that host on the - same port on which the server is listening. - - The character set for all NNTP commands is UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]. Commands - in NNTP MUST consist of a keyword, which MAY be followed by one or - more arguments. A CRLF pair MUST terminate all commands. Multiple - commands MUST NOT be on the same line. Unless otherwise noted - elsewhere in this document, arguments SHOULD consist of printable US- - ASCII characters. Keywords and arguments MUST each be separated by - one or more space or TAB characters. Command lines MUST NOT exceed - 512 octets, which includes the terminating CRLF pair. The arguments - MUST NOT exceed 497 octets. A server MAY relax these limits for - commands defined in an extension. - - Where this specification permits UTF-8 characters outside the range - of U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark - (U+FEFF, encoding %xEF.BB.BF) and MUST use the Word Joiner (U+2060, - encoding %xE2.91.A0) for the meaning Zero Width No-Break Space in - - - -<span class="grey">Feather Standards Track [Page 6]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - command lines and the initial lines of responses. Implementations - SHOULD apply these same principles throughout. - - The term "character" means a single Unicode code point. - Implementations are not required to carry out Unicode normalisation. - Thus, U+0084 (A-dieresis) is one character, while U+0041 U+0308 (A - composed with dieresis) is two; the two need not be treated as - equivalent. - - Commands may have variants; if so, they use a second keyword - immediately after the first to indicate which variant is required. - The only such commands in this specification are LIST and MODE. Note - that such variants are sometimes referred to as if they were commands - in their own right: "the LIST ACTIVE" command should be read as - shorthand for "the ACTIVE variant of the LIST command". - - Keywords are case insensitive; the case of keywords for commands MUST - be ignored by the server. Command and response arguments are case or - language specific only when stated, either in this document or in - other relevant specifications. - - In some cases, a command involves more data than just a single line. - The further data may be sent either immediately after the command - line (there are no instances of this in this specification, but there - are in extensions such as [<a href="#ref-NNTP-STREAM" title='"Network News Transfer Protocol (NNTP) Extension for Streaming Feeds"'>NNTP-STREAM</a>]) or following a request from - the server (indicated by a 3xx response). - - Each response MUST start with a three-digit response code that is - sufficient to distinguish all responses. Certain valid responses are - defined to be multi-line; for all others, the response is contained - in a single line. The initial line of the response MUST NOT exceed - 512 octets, which includes the response code and the terminating CRLF - pair; an extension MAY specify a greater maximum for commands that it - defines, but not for any other command. Single-line responses - consist of an initial line only. Multi-line responses consist of an - initial line followed by a multi-line data block. - - An NNTP server MAY have an inactivity autologout timer. Such a timer - SHOULD be of at least three minutes' duration, with the exception - that there MAY be a shorter limit on how long the server is willing - to wait for the first command from the client. The receipt of any - command from the client during the timer interval SHOULD suffice to - reset the autologout timer. Similarly, the receipt of any - significant amount of data from a client that is sending a multi-line - data block (such as during a POST or IHAVE command) SHOULD suffice to - reset the autologout timer. When the timer expires, the server - SHOULD close the connection without sending any response to the - client. - - - -<span class="grey">Feather Standards Track [Page 7]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Multi-line Data Blocks</h4></span> - - A multi-line data block is used in certain commands and responses. - It MUST adhere to the following rules: - - 1. The block consists of a sequence of zero or more "lines", each - being a stream of octets ending with a CRLF pair. Apart from - those line endings, the stream MUST NOT include the octets NUL, - LF, or CR. - - 2. In a multi-line response, the block immediately follows the CRLF - at the end of the initial line of the response. When used in any - other context, the specific command will define when the block is - sent. - - 3. If any line of the data block begins with the "termination octet" - ("." or %x2E), that line MUST be "dot-stuffed" by prepending an - additional termination octet to that line of the block. - - 4. The lines of the block MUST be followed by a terminating line - consisting of a single termination octet followed by a CRLF pair - in the normal way. Thus, unless it is empty, a multi-line block - is always terminated with the five octets CRLF "." CRLF - (%x0D.0A.2E.0D.0A). - - 5. When a multi-line block is interpreted, the "dot-stuffing" MUST - be undone; i.e., the recipient MUST ensure that, in any line - beginning with the termination octet followed by octets other - than a CRLF pair, that initial termination octet is disregarded. - - 6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT - be considered part of the multi-line block; i.e., the recipient - MUST ensure that any line beginning with the termination octet - followed immediately by a CRLF pair is disregarded. (The first - CRLF pair of the terminating CRLF "." CRLF of a non-empty block - is, of course, part of the last line of the block.) - - Note that texts using an encoding (such as UTF-16 or UTF-32) that may - contain the octets NUL, LF, or CR other than a CRLF pair cannot be - reliably conveyed in the above format (that is, they violate the MUST - requirement above). However, except when stated otherwise, this - specification does not require the content to be UTF-8, and therefore - (subject to that same requirement) it MAY include octets above and - below 128 mixed arbitrarily. - - This document does not place any limit on the length of a line in a - multi-line block. However, the standards that define the format of - articles may do so. - - - -<span class="grey">Feather Standards Track [Page 8]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Response Codes</h3></span> - - Each response MUST begin with a three-digit status indicator. These - are status reports from the server and indicate the response to the - last command received from the client. - - The first digit of the response broadly indicates the success, - failure, or progress of the previous command: - - 1xx - Informative message - 2xx - Command completed OK - 3xx - Command OK so far; send the rest of it - 4xx - Command was syntactically correct but failed for some reason - 5xx - Command unknown, unsupported, unavailable, or syntax error - - The next digit in the code indicates the function response category: - - x0x - Connection, setup, and miscellaneous messages - x1x - Newsgroup selection - x2x - Article selection - x3x - Distribution functions - x4x - Posting - x8x - Reserved for authentication and privacy extensions - x9x - Reserved for private use (non-standard extensions) - - Certain responses contain arguments such as numbers and names in - addition to the status indicator. In those cases, to simplify - interpretation by the client, the number and type of such arguments - is fixed for each response code, as is whether the code is - single-line or multi-line. Any extension MUST follow this principle - as well. Note that, for historical reasons, the 211 response code is - an exception to this in that the response may be single-line or - multi-line depending on the command (GROUP or LISTGROUP) that - generated it. In all other cases, the client MUST only use the - status indicator itself to determine the nature of the response. The - exact response codes that can be returned by any given command are - detailed in the description of that command. - - Arguments MUST be separated from the numeric status indicator and - from each other by a single space. All numeric arguments MUST be in - base 10 (decimal) format and MAY have leading zeros. String - arguments MUST contain at least one character and MUST NOT contain - TAB, LF, CR, or space. The server MAY add any text after the - response code or last argument, as appropriate, and the client MUST - NOT make decisions based on this text. Such text MUST be separated - from the numeric status indicator or the last argument by at least - one space. - - - - -<span class="grey">Feather Standards Track [Page 9]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The server MUST respond to any command with the appropriate generic - response (given in <a href="#section-3.2.1">Section 3.2.1</a>) if it represents the situation. - Otherwise, each recognized command MUST return one of the response - codes specifically listed in its description or in an extension. A - server MAY provide extensions to this specification, including new - commands, new variants or features of existing commands, and other - ways of changing the internal state of the server. However, the - server MUST NOT produce any other responses to a client that does not - invoke any of the additional features. (Therefore, a client that - restricts itself to this specification will only receive the - responses that are listed.) - - If a client receives an unexpected response, it SHOULD use the first - digit of the response to determine the result. For example, an - unexpected 2xx should be taken as success, and an unexpected 4xx or - 5xx as failure. - - Response codes not specified in this document MAY be used for any - installation-specific additional commands also not specified. These - SHOULD be chosen to fit the pattern of x9x specified above. - - Neither this document nor any registered extension (see - <a href="#section-3.3.3">Section 3.3.3</a>) will specify any response codes of the x9x pattern. - (Implementers of extensions are accordingly cautioned not to use such - responses for extensions that may subsequently be submitted for - registration.) - -<span class="h4"><h4><a class="selflink" name="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Generic Response Codes</h4></span> - - The server MUST respond to any command with the appropriate one of - the following generic responses if it represents the situation. - - If the command is not recognized, or if it is an optional command - that is not implemented by the server, the response code 500 MUST be - returned. - - If there is a syntax error in the arguments of a recognized command, - including the case where more arguments are provided than the command - specifies or the command line is longer than the server accepts, the - response code 501 MUST be returned. The line MUST NOT be truncated - or split and then interpreted. Note that where a command has - variants depending on a second keyword (e.g., LIST ACTIVE and LIST - NEWSGROUPS), 501 MUST be used when the base command is implemented - but the requested variant is not, and 500 MUST be used only when the - base command itself is not implemented. - - If an argument is required to be a base64-encoded string [<a href="https://tools.ietf.org/html/rfc4648" title='"The Base16, Base32, and Base64 Data Encodings"'>RFC4648</a>] - (there are no such arguments in this specification, but there may be - - - -<span class="grey">Feather Standards Track [Page 10]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - in extensions) and is not validly encoded, the response code 504 MUST - be returned. - - If the server experiences an internal fault or problem that means it - is unable to carry out the command (for example, a necessary file is - missing or a necessary service could not be contacted), the response - code 403 MUST be returned. If the server recognizes the command but - does not provide an optional feature (for example, because it does - not store the required information), or if it only handles a subset - of legitimate cases (see the HDR command, <a href="#section-8.5">Section 8.5</a>, for an - example), the response code 503 MUST be returned. - - If the client is not authorized to use the specified facility when - the server is in its current state, then the appropriate one of the - following response codes MUST be used. - - 502: It is necessary to terminate the connection and to start a new - one with the appropriate authority before the command can be used. - Historically, some mode-switching servers (see <a href="#section-3.4.1">Section 3.4.1</a>) used - this response to indicate that this command will become available - after the MODE READER command (<a href="#section-5.3">Section 5.3</a>) is used, but this - usage does not conform to this specification and MUST NOT be used. - Note that the server MUST NOT close the connection immediately - after a 502 response except at the initial connection - (<a href="#section-5.1">Section 5.1</a>) and with the MODE READER command. - - 480: The client must authenticate itself to the server (that is, it - must provide information as to the identity of the client) before - the facility can be used on this connection. This will involve - the use of an authentication extension such as [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>]. - - 483: The client must negotiate appropriate privacy protection on the - connection. This will involve the use of a privacy extension such - as [<a href="#ref-NNTP-TLS" title='"Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)"'>NNTP-TLS</a>]. - - 401: The client must change the state of the connection in some other - manner. The first argument of the response MUST be the capability - label (see <a href="#section-5.2">Section 5.2</a>) of the facility that provides the - necessary mechanism (usually an extension, which may be a private - extension). The server MUST NOT use this response code except as - specified by the definition of the capability in question. - - If the server has to terminate the connection for some reason, it - MUST give a 400 response code to the next command and then - immediately close the connection. Following a 400 response, clients - SHOULD NOT simply reconnect immediately and retry the same actions. - Rather, a client SHOULD either use an exponentially increasing delay - between retries (e.g., double the waiting time after each 400 - - - -<span class="grey">Feather Standards Track [Page 11]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - response) or present any associated text to the user for them to - decide whether and when to retry. - - The client MUST be prepared to receive any of these responses for any - command (except, of course, that the server MUST NOT generate a 500 - response code for mandatory commands). - -<span class="h5"><h5><a class="selflink" name="section-3.2.1.1" href="#section-3.2.1.1">3.2.1.1</a>. Examples</h5></span> - - Example of an unknown command: - - [<a name="ref-C" id="ref-C">C</a>] MAIL - [S] 500 Unknown command - - Example of an unsupported command: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] NEWNEWS - [S] LIST ACTIVE NEWSGROUPS - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER - [S] 500 Unknown command - - Example of an unsupported variant: - - [<a name="ref-C" id="ref-C">C</a>] MODE POSTER - [S] 501 Unknown MODE option - - Example of a syntax error: - - [<a name="ref-C" id="ref-C">C</a>] ARTICLE a.message.id@no.angle.brackets - [S] 501 Syntax error - - Example of an overlong command line: - - [<a name="ref-C" id="ref-C">C</a>] HEAD 53 54 55 - [S] 501 Too many arguments - - Example of a bad wildmat: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE u[ks].* - [S] 501 Syntax error - - - - - - -<span class="grey">Feather Standards Track [Page 12]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of a base64-encoding error (the second argument is meant to - be base64 encoded): - - [<a name="ref-C" id="ref-C">C</a>] XENCRYPT RSA abcd=efg - [S] 504 Base64 encoding error - - Example of an attempt to access a facility not available to this - connection: - - [<a name="ref-C" id="ref-C">C</a>] MODE READER - [S] 200 Reader mode, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] IHAVE <i.am.an.article.you.will.want@example.com> - [S] 500 Permission denied - - Example of an attempt to access a facility requiring authentication: - - [<a name="ref-C" id="ref-C">C</a>] GROUP secret.group - [S] 480 Permission denied - - Example of a successful attempt following such authentication: - - [<a name="ref-C" id="ref-C">C</a>] XSECRET fred flintstone - [S] 290 Password for fred accepted - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP secret.group - [S] 211 5 1 20 secret.group selected - - Example of an attempt to access a facility requiring privacy: - - [<a name="ref-C" id="ref-C">C</a>] GROUP secret.group - [S] 483 Secure connection required - [<a href="#ref-C" title='"Demo User"'>C</a>] XENCRYPT - [Client and server negotiate encryption on the link] - [S] 283 Encrypted link established - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP secret.group - [S] 211 5 1 20 secret.group selected - - Example of a need to change mode before a facility is used: - - [<a name="ref-C" id="ref-C">C</a>] GROUP binary.group - [S] 401 XHOST Not on this virtual host - [<a href="#ref-C" title='"Demo User"'>C</a>] XHOST binary.news.example.org - [S] 290 binary.news.example.org virtual host selected - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP binary.group - [S] 211 5 1 77 binary.group selected - - - - - - - -<span class="grey">Feather Standards Track [Page 13]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of a temporary failure: - - [<a name="ref-C" id="ref-C">C</a>] GROUP archive.local - [S] 403 Archive server temporarily offline - - Example of the server needing to close down immediately: - - [<a name="ref-C" id="ref-C">C</a>] ARTICLE 123 - [S] 400 Power supply failed, running on UPS - [Server closes connection.] - -<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Capabilities and Extensions</h3></span> - - Not all NNTP servers provide exactly the same facilities, both - because this specification allows variation and because servers may - provide extensions. A set of facilities that are related are called - a "capability". This specification provides a way to determine what - capabilities are available, includes a list of standard capabilities, - and includes a mechanism (the extension mechanism) for defining new - capabilities. - -<span class="h4"><h4><a class="selflink" name="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Capability Descriptions</h4></span> - - A client can determine the available capabilities of the server by - using the CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>). This returns a - capability list, which is a list of capability lines. Each line - describes one available capability. - - Each capability line consists of one or more tokens, which MUST be - separated by one or more space or TAB characters. A token is a - string of 1 or more printable UTF-8 characters (that is, either - printable US-ASCII characters or any UTF-8 sequence outside the US- - ASCII range, but not space or TAB). Unless stated otherwise, tokens - are case insensitive. Each capability line consists of the - following: - - o The capability label, which is a keyword indicating the - capability. A capability label may be defined by this - specification or a successor, or by an extension. - - o The label is then followed by zero or more tokens, which are - arguments of the capability. The form and meaning of these tokens - is specific to each capability. - - The server MUST ensure that the capability list accurately reflects - the capabilities (including extensions) currently available. If a - capability is only available with the server in a certain state (for - example, only after authentication), the list MUST only include the - - - -<span class="grey">Feather Standards Track [Page 14]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - capability label when the server is in that state. Similarly, if - only some of the commands in an extension will be available, or if - the behaviour of the extension will change in some other manner, - according to the state of the server, this MUST be indicated by - different arguments in the capability line. - - Note that a capability line can only begin with a letter. Lines - beginning with other characters are reserved for future versions of - this specification. In order to interoperate with such versions, - clients MUST be prepared to receive lines beginning with other - characters and MUST ignore any they do not understand. - -<span class="h4"><h4><a class="selflink" name="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Standard Capabilities</h4></span> - - The following capabilities are defined by this specification. - - VERSION - This capability MUST be advertised by all servers and MUST be the - first capability in the capability list; it indicates the - version(s) of NNTP that the server supports. There must be at - least one argument; each argument is a decimal number and MUST NOT - have a leading zero. Version numbers are assigned only in RFCs - that update or replace this specification; servers MUST NOT create - their own version numbers. - - The version number of this specification is 2. - - READER - This capability indicates that the server implements the various - commands useful for reading clients. - - IHAVE - This capability indicates that the server implements the IHAVE - command. - - POST - This capability indicates that the server implements the POST - command. - - NEWNEWS - This capability indicates that the server implements the NEWNEWS - command. - - HDR - This capability indicates that the server implements the header - access commands (HDR and LIST HEADERS). - - - - - -<span class="grey">Feather Standards Track [Page 15]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - OVER - This capability indicates that the server implements the overview - access commands (OVER and LIST OVERVIEW.FMT). If and only if the - server supports the message-id form of the OVER command, there - must be a single argument MSGID. - - LIST - This capability indicates that the server implements at least one - variant of the LIST command. There MUST be one argument for each - variant of the LIST command supported by the server, giving the - keyword for that variant. - - IMPLEMENTATION - This capability MAY be provided by a server. If so, the arguments - SHOULD be used to provide information such as the server software - name and version number. The client MUST NOT use this line to - determine capabilities of the server. (While servers often - provide this information in the initial greeting, clients need to - guess whether this is the case; this capability makes it clear - what the information is.) - - MODE-READER - This capability indicates that the server is mode-switching - (<a href="#section-3.4.2">Section 3.4.2</a>) and that the MODE READER command needs to be used - to enable the READER capability. - -<span class="h4"><h4><a class="selflink" name="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Extensions</h4></span> - - Although NNTP is widely and robustly deployed, some parts of the - Internet community might wish to extend the NNTP service. It must be - emphasized that any extension to NNTP should not be considered - lightly. NNTP's strength comes primarily from its simplicity. - Experience with many protocols has shown that: - - Protocols with few options tend towards ubiquity, whilst protocols - with many options tend towards obscurity. - - This means that each and every extension, regardless of its benefits, - must be carefully scrutinized with respect to its implementation, - deployment, and interoperability costs. In many cases, the cost of - extending the NNTP service will likely outweigh the benefit. - - An extension is a package of associated facilities, often but not - always including one or more new commands. Each extension MUST - define at least one new capability label (this will often, but need - not, be the name of one of these new commands). While any additional - capability information can normally be specified using arguments to - - - - -<span class="grey">Feather Standards Track [Page 16]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - that label, an extension MAY define more than one capability label. - However, this SHOULD be limited to exceptional circumstances. - - An extension is either a private extension, or its capabilities are - included in the IANA registry of capabilities (see <a href="#section-3.3.4">Section 3.3.4</a>) and - it is defined in an RFC (in which case it is a "registered - extension"). Such RFCs either must be on the standards track or must - define an IESG-approved experimental protocol. - - The definition of an extension must include the following: - - o a descriptive name for the extension. - - o the capability label or labels defined by the extension (the - capability label of a registered extension MUST NOT begin with - "X"). - - o The syntax, values, and meanings of any arguments for each - capability label defined by the extension. - - o Any new NNTP commands associated with the extension (the names of - commands associated with registered extensions MUST NOT begin with - "X"). - - o The syntax and possible values of arguments associated with the - new NNTP commands. - - o The response codes and possible values of arguments for the - responses of the new NNTP commands. - - o Any new arguments the extension associates with any other - pre-existing NNTP commands. - - o Any increase in the maximum length of commands and initial - response lines over the value specified in this document. - - o A specific statement about the effect on pipelining that this - extension may have (if any). - - o A specific statement about the circumstances when use of this - extension can alter the contents of the capabilities list (other - than the new capability labels it defines). - - o A specific statement about the circumstances under which the - extension can cause any pre-existing command to produce a 401, - 480, or 483 response. - - - - - -<span class="grey">Feather Standards Track [Page 17]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - o A description of how the use of MODE READER on a mode-switching - server interacts with the extension. - - o A description of how support for the extension affects the - behaviour of a server and NNTP client in any other manner not - outlined above. - - o Formal syntax as described in <a href="#section-9.9">Section 9.9</a>. - - A private extension MAY or MAY NOT be included in the capabilities - list. If it is, the capability label MUST begin with "X". A server - MAY provide additional keywords (for new commands and also for new - variants of existing commands) as part of a private extension. To - avoid the risk of a clash with a future registered extension, these - keywords SHOULD begin with "X". - - If the server advertises a capability defined by a registered - extension, it MUST implement the extension so as to fully conform - with the specification (for example, it MUST implement all the - commands that the extension describes as mandatory). If it does not - implement the extension as specified, it MUST NOT list the extension - in the capabilities list under its registered name. In that case, it - MAY, but SHOULD NOT, provide a private extension (not listed, or - listed with a different name) that implements part of the extension - or implements the commands of the extension with a different meaning. - - A server MUST NOT send different response codes to basic NNTP - commands documented here or to commands documented in registered - extensions in response to the availability or use of a private - extension. - -<span class="h4"><h4><a class="selflink" name="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Initial IANA Register</h4></span> - - IANA will maintain a registry of NNTP capability labels. All - capability labels in the registry MUST be keywords and MUST NOT begin - with X. - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 18]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The initial content of the registry consists of these entries: - - +-------------------+--------------------------+--------------------+ - | Label | Meaning | Definition | - +-------------------+--------------------------+--------------------+ - | AUTHINFO | Authentication | [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>] | - | | | | - | HDR | Batched header retrieval | <a href="#section-3.3.2">Section 3.3.2</a>, | - | | | <a href="#section-8.5">Section 8.5</a>, and | - | | | <a href="#section-8.6">Section 8.6</a> | - | | | | - | IHAVE | IHAVE command available | <a href="#section-3.3.2">Section 3.3.2</a> and | - | | | <a href="#section-6.3.2">Section 6.3.2</a> | - | | | | - | IMPLEMENTATION | Server | <a href="#section-3.3.2">Section 3.3.2</a> | - | | implementation-specific | | - | | information | | - | | | | - | LIST | LIST command variants | <a href="#section-3.3.2">Section 3.3.2</a> and | - | | | <a href="#section-7.6.1">Section 7.6.1</a> | - | | | | - | MODE-READER | Mode-switching server | <a href="#section-3.4.2">Section 3.4.2</a> | - | | and MODE READER command | | - | | available | | - | | | | - | NEWNEWS | NEWNEWS command | <a href="#section-3.3.2">Section 3.3.2</a> and | - | | available | <a href="#section-7.4">Section 7.4</a> | - | | | | - | OVER | Overview support | <a href="#section-3.3.2">Section 3.3.2</a>, | - | | | <a href="#section-8.3">Section 8.3</a>, and | - | | | <a href="#section-8.4">Section 8.4</a> | - | | | | - | POST | POST command available | <a href="#section-3.3.2">Section 3.3.2</a> and | - | | | <a href="#section-6.3.1">Section 6.3.1</a> | - | | | | - | READER | Reader commands | <a href="#section-3.3.2">Section 3.3.2</a> | - | | available | | - | | | | - | SASL | Supported SASL | [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>] | - | | mechanisms | | - | | | | - | STARTTLS | Transport layer security | [<a href="#ref-NNTP-TLS" title='"Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)"'>NNTP-TLS</a>] | - | | | | - | STREAMING | Streaming feeds | [<a href="#ref-NNTP-STREAM" title='"Network News Transfer Protocol (NNTP) Extension for Streaming Feeds"'>NNTP-STREAM</a>] | - | | | | - | VERSION | Supported NNTP versions | <a href="#section-3.3.2">Section 3.3.2</a> | - +-------------------+--------------------------+--------------------+ - - - - -<span class="grey">Feather Standards Track [Page 19]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Mandatory and Optional Commands</h3></span> - - For a number of reasons, not all the commands in this specification - are mandatory. However, it is equally undesirable for every command - to be optional, since this means that a client will have no idea what - facilities are available. Therefore, as a compromise, some of the - commands in this specification are mandatory (they must be supported - by all servers) while the remainder are not. The latter are then - subdivided into bundles, each indicated by a single capability label. - - o If the label is included in the capability list returned by the - server, the server MUST support all commands in that bundle. - - o If the label is not included, the server MAY support none or some - of the commands but SHOULD NOT support all of them. In general, - there will be no way for a client to determine which commands are - supported without trying them. - - The bundles have been chosen to provide useful functionality, and - therefore server authors are discouraged from implementing only part - of a bundle. - - The description of each command will either indicate that it is - mandatory, or will give, using the term "indicating capability", the - capability label indicating whether the bundle including this command - is available. - - Where a server does not implement a command, it MUST always generate - a 500 generic response code (or a 501 generic response code in the - case of a variant of a command depending on a second keyword where - the base command is recognised). Otherwise, the command MUST be - fully implemented as specified; a server MUST NOT only partially - implement any of the commands in this specification. (Client authors - should note that some servers not conforming to this specification - will return a 502 generic response code to some commands that are not - implemented.) - - Note: some commands have cases that require other commands to be used - first. If the former command is implemented but the latter is not, - the former MUST still generate the relevant specific response code. - For example, if ARTICLE (<a href="#section-6.2.1">Section 6.2.1</a>) is implemented but GROUP - (<a href="#section-6.1.1">Section 6.1.1</a>) is not, the correct response to "ARTICLE 1234" - remains 412. - - - - - - - - -<span class="grey">Feather Standards Track [Page 20]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Reading and Transit Servers</h4></span> - - NNTP is traditionally used in two different ways. The first use is - "reading", where the client fetches articles from a large store - maintained by the server for immediate or later presentation to a - user and sends articles created by that user back to the server (an - action called "posting") to be stored and distributed to other stores - and users. The second use is for the bulk transfer of articles from - one store to another. Since the hosts making this transfer tend to - be peers in a network that transmit articles among one another, and - not end-user systems, this process is called "peering" or "transit". - (Even so, one host is still the client and the other is the server). - - In practice, these two uses are so different that some server - implementations are optimised for reading or for transit and, as a - result, do not offer the other facility or only offer limited - features. Other implementations are more general and offer both. - This specification allows for this by bundling the relevant commands - accordingly: the IHAVE command is designed for transit, while the - commands indicated by the READER capability are designed for reading - clients. - - Except as an effect of the MODE READER command (<a href="#section-5.3">Section 5.3</a>) on a - mode-switching server, once a server advertises either or both of the - IHAVE or READER capabilities, it MUST continue to advertise them for - the entire session. - - A server MAY provide different modes of behaviour (transit, reader, - or a combination) to different client connections and MAY use - external information, such as the IP address of the client, to - determine which mode to provide to any given connection. - - The official TCP port for the NNTP service is 119. However, if a - host wishes to offer separate servers for transit and reading - clients, port 433 SHOULD be used for the transit server and 119 for - the reading server. - -<span class="h4"><h4><a class="selflink" name="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Mode Switching</h4></span> - - An implementation MAY, but SHOULD NOT, provide both transit and - reader facilities on the same server but require the client to select - which it wishes to use. Such an arrangement is called a - "mode-switching" server. - - - - - - - - -<span class="grey">Feather Standards Track [Page 21]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - A mode-switching server has two modes: - - o Transit mode, which applies after the initial connection. - - * It MUST advertise the MODE-READER capability. - - * It MUST NOT advertise the READER capability. - - However, the server MAY cease to advertise the MODE-READER - capability after the client uses any command except CAPABILITIES. - - o Reading mode, after a successful MODE READER command (see <a href="#section-5.3">Section</a> - <a href="#section-5.3">5.3</a>). - - * It MUST NOT advertise the MODE-READER capability. - - * It MUST advertise the READER capability. - - * It MAY NOT advertise the IHAVE capability, even if it was - advertising it in transit mode. - - A client SHOULD only issue a MODE READER command to a server if it is - advertising the MODE-READER capability. If the server does not - support CAPABILITIES (and therefore does not conform to this - specification), the client MAY use the following heuristic: - - o If the client wishes to use any "reader" commands, it SHOULD use - the MODE READER command immediately after the initial connection. - - o Otherwise, it SHOULD NOT use the MODE READER command. - - In each case, it should be prepared for some commands to be - unavailable that would have been available if it had made the other - choice. - -<span class="h3"><h3><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Pipelining</h3></span> - - NNTP is designed to operate over a reliable bi-directional - connection, such as TCP. Therefore, if a command does not depend on - the response to the previous one, it should not matter if it is sent - before that response is received. Doing this is called "pipelining". - However, certain server implementations throw away all text received - from the client following certain commands before sending their - response. If this happens, pipelining will be affected because one - or more commands will have been ignored or misinterpreted, and the - client will be matching the wrong responses to each command. Since - there are significant benefits to pipelining, but also circumstances - where it is reasonable or common for servers to behave in the above - - - -<span class="grey">Feather Standards Track [Page 22]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - manner, this document puts certain requirements on both clients and - servers. - - Except where stated otherwise, a client MAY use pipelining. That is, - it may send a command before receiving the response for the previous - command. The server MUST allow pipelining and MUST NOT throw away - any text received after a command. Irrespective of whether - pipelining is used, the server MUST process commands in the order - they are sent. - - If the specific description of a command says it "MUST NOT be - pipelined", that command MUST end any pipeline of commands. That is, - the client MUST NOT send any following command until it receives the - CRLF at the end of the response from the command. The server MAY - ignore any data received after the command and before the CRLF at the - end of the response is sent to the client. - - The initial connection must not be part of a pipeline; that is, the - client MUST NOT send any command until it receives the CRLF at the - end of the greeting. - - If the client uses blocking system calls to send commands, it MUST - ensure that the amount of text sent in pipelining does not cause a - deadlock between transmission and reception. The amount of text - involved will depend on window sizes in the transmission layer; - typically, it is 4k octets for TCP. (Since the server only sends - data in response to commands from the client, the converse problem - does not occur.) - -<span class="h4"><h4><a class="selflink" name="section-3.5.1" href="#section-3.5.1">3.5.1</a>. Examples</h4></span> - - Example of correct use of pipelining: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 211 1234 3000234 3002322 misc.test - [S] 223 3000234 <45223423@example.com> retrieved - [S] 223 3000237 <668929@example.org> retrieved - - Example of incorrect use of pipelining (the MODE READER command may - not be pipelined): - - [<a name="ref-C" id="ref-C">C</a>] MODE READER - [<a href="#ref-C" title='"Demo User"'>C</a>] DATE - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 200 Server ready, posting allowed - [S] 223 3000237 <668929@example.org> retrieved - - - -<span class="grey">Feather Standards Track [Page 23]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The DATE command has been thrown away by the server, so there is no - 111 response to match it. - -<span class="h3"><h3><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a>. Articles</h3></span> - - NNTP is intended to transfer articles between clients and servers. - For the purposes of this specification, articles are required to - conform to the rules in this section, and clients and servers MUST - correctly process any article received from the other that does so. - Note that this requirement applies only to the contents of - communications over NNTP; it does not prevent the client or server - from subsequently rejecting an article for reasons of local policy. - Also see <a href="#appendix-A">Appendix A</a> for further restrictions on the format of - articles in some uses of NNTP. - - An article consists of two parts: the headers and the body. They are - separated by a single empty line, or in other words by two - consecutive CRLF pairs (if there is more than one empty line, the - second and subsequent ones are part of the body). In order to meet - the general requirements of NNTP, an article MUST NOT include the - octet NUL, MUST NOT contain the octets LF and CR other than as part - of a CRLF pair, and MUST end with a CRLF pair. This specification - puts no further restrictions on the body; in particular, it MAY be - empty. - - The headers of an article consist of one or more header lines. Each - header line consists of a header name, a colon, a space, the header - content, and a CRLF, in that order. The name consists of one or more - printable US-ASCII characters other than colon and, for the purposes - of this specification, is not case sensitive. There MAY be more than - one header line with the same name. The content MUST NOT contain - CRLF; it MAY be empty. A header may be "folded"; that is, a CRLF - pair may be placed before any TAB or space in the line. There MUST - still be some other octet between any two CRLF pairs in a header - line. (Note that folding means that the header line occupies more - than one line when displayed or transmitted; nevertheless, it is - still referred to as "a" header line.) The presence or absence of - folding does not affect the meaning of the header line; that is, the - CRLF pairs introduced by folding are not considered part of the - header content. Header lines SHOULD NOT be folded before the space - after the colon that follows the header name and SHOULD include at - least one octet other than %x09 or %x20 between CRLF pairs. However, - if an article that fails to satisfy this requirement has been - received from elsewhere, clients and servers MAY transfer it to each - other without re-folding it. - - - - - - -<span class="grey">Feather Standards Track [Page 24]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The content of a header SHOULD be in UTF-8. However, if an - implementation receives an article from elsewhere that uses octets in - the range 128 to 255 in some other manner, it MAY pass it to a client - or server without modification. Therefore, implementations MUST be - prepared to receive such headers, and data derived from them (e.g., - in the responses from the OVER command, <a href="#section-8.3">Section 8.3</a>), and MUST NOT - assume that they are always UTF-8. Any external processing of those - headers, including identifying the encoding used, is outside the - scope of this document. - - Each article MUST have a unique message-id; two articles offered by - an NNTP server MUST NOT have the same message-id. For the purposes - of this specification, message-ids are opaque strings that MUST meet - the following requirements: - - o A message-id MUST begin with "<", end with ">", and MUST NOT - contain the latter except at the end. - - o A message-id MUST be between 3 and 250 octets in length. - - o A message-id MUST NOT contain octets other than printable US-ASCII - characters. - - Two message-ids are the same if and only if they consist of the same - sequence of octets. - - This specification does not describe how the message-id of an article - is determined. If the server does not have any way to determine a - message-id from the article itself, it MUST synthesize one (this - specification does not require that the article be changed as a - result). See also <a href="#appendix-A.2">Appendix A.2</a>. - -<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. The WILDMAT Format</h2></span> - - The WILDMAT format described here is based on the version first - developed by Rich Salz [<a href="#ref-SALZ1992" title='"Manual Page for wildmat(3) from the INN 1.4 distribution, Revision 1.10"'>SALZ1992</a>], which was in turn derived from the - format used in the UNIX "find" command to articulate file names. It - was developed to provide a uniform mechanism for matching patterns in - the same manner that the UNIX shell matches filenames. - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 25]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Wildmat Syntax</h3></span> - - A wildmat is described by the following ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] syntax, which - is an extract of that in <a href="#section-9.8">Section 9.8</a>. - - wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) - wildmat-pattern = 1*wildmat-item - wildmat-item = wildmat-exact / wildmat-wild - wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / - UTF8-non-ascii ; exclude ! * , ? [ \ ] - wildmat-wild = "*" / "?" - - Note: the characters ",", "\", "[", and "]" are not allowed in - wildmats, while * and ? are always wildcards. This should not be a - problem, since these characters cannot occur in newsgroup names, - which is the only current use of wildmats. Backslash is commonly - used to suppress the special meaning of characters, whereas brackets - are used to introduce sets. However, these usages are not universal, - and interpretation of these characters in the context of UTF-8 - strings is potentially complex and differs from existing practice, so - they were omitted from this specification. A future extension to - this specification may provide semantics for these characters. - -<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Wildmat Semantics</h3></span> - - A wildmat is tested against a string and either matches or does not - match. To do this, each constituent <wildmat-pattern> is matched - against the string, and the rightmost pattern that matches is - identified. If that <wildmat-pattern> is not preceded with "!", the - whole wildmat matches. If it is preceded by "!", or if no <wildmat- - pattern> matches, the whole wildmat does not match. - - For example, consider the wildmat "a*,!*b,*c*": - - o The string "aaa" matches because the rightmost match is with "a*". - - o The string "abb" does not match because the rightmost match is - with "*b". - - o The string "ccb" matches because the rightmost match is with - "*c*". - - o The string "xxx" does not match because no <wildmat-pattern> - matches. - - A <wildmat-pattern> matches a string if the string can be broken into - components, each of which matches the corresponding <wildmat-item> in - the pattern. The matches must be in the same order, and the whole - - - -<span class="grey">Feather Standards Track [Page 26]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - string must be used in the match. The pattern is "anchored"; that - is, the first and last characters in the string must match the first - and last item, respectively (unless that item is an asterisk matching - zero characters). - - A <wildmat-exact> matches the same character (which may be more than - one octet in UTF-8). - - "?" matches exactly one character (which may be more than one octet). - - "*" matches zero or more characters. It can match an empty string, - but it cannot match a subsequence of a UTF-8 sequence that is not - aligned to the character boundaries. - -<span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. Extensions</h3></span> - - An NNTP server or extension MAY extend the syntax or semantics of - wildmats provided that all wildmats that meet the requirements of - <a href="#section-4.1">Section 4.1</a> have the meaning ascribed to them by <a href="#section-4.2">Section 4.2</a>. Future - editions of this document may also extend wildmats. - -<span class="h3"><h3><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a>. Examples</h3></span> - - In these examples, $ and @ are used to represent the two octets %xC2 - and %xA3, respectively; $@ is thus the UTF-8 encoding for the pound - sterling symbol, shown as # in the descriptions. - - Wildmat Description of strings that match - abc The one string "abc" - abc,def The two strings "abc" and "def" - $@ The one character string "#" - a* Any string that begins with "a" - a*b Any string that begins with "a" and ends with "b" - a*,*b Any string that begins with "a" or ends with "b" - a*,!*b Any string that begins with "a" and does not end with - "b" - a*,!*b,c* Any string that begins with "a" and does not end with - "b", and any string that begins with "c" no matter - what it ends with - a*,c*,!*b Any string that begins with "a" or "c" and does not - end with "b" - ?a* Any string with "a" as its second character - ??a* Any string with "a" as its third character - *a? Any string with "a" as its penultimate character - *a?? Any string with "a" as its antepenultimate character - - - - - - -<span class="grey">Feather Standards Track [Page 27]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. Session Administration Commands</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. Initial Connection</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Usage</h4></span> - - This command MUST NOT be pipelined. - - Responses [<a href="#ref-1">1</a>] - 200 Service available, posting allowed - 201 Service available, posting prohibited - 400 Service temporarily unavailable [<a href="#ref-2">2</a>] - 502 Service permanently unavailable [<a href="#ref-2">2</a>] - - [<a name="ref-1" id="ref-1">1</a>] These are the only valid response codes for the initial greeting; - the server MUST not return any other generic response code. - - [<a name="ref-2" id="ref-2">2</a>] Following a 400 or 502 response, the server MUST immediately - close the connection. - -<span class="h4"><h4><a class="selflink" name="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Description</h4></span> - - There is no command presented by the client upon initial connection - to the server. The server MUST present an appropriate response code - as a greeting to the client. This response informs the client - whether service is available and whether the client is permitted to - post. - - If the server will accept further commands from the client including - POST, the server MUST present a 200 greeting code. If the server - will accept further commands from the client, but the client is not - authorized to post articles using the POST command, the server MUST - present a 201 greeting code. - - Otherwise, the server MUST present a 400 or 502 greeting code and - then immediately close the connection. 400 SHOULD be used if the - issue is only temporary (for example, because of load) and the client - can expect to be able to connect successfully at some point in the - future without making any changes. 502 MUST be used if the client is - not permitted under any circumstances to interact with the server, - and MAY be used if the server has insufficient information to - determine whether the issue is temporary or permanent. - - Note: the distinction between the 200 and 201 response codes has - turned out in practice to be insufficient; for example, some servers - do not allow posting until the client has authenticated, while other - clients assume that a 201 response means that posting will never be - possible even after authentication. Therefore, clients SHOULD use - - - -<span class="grey">Feather Standards Track [Page 28]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - the CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>) rather than rely on this - response. - -<span class="h4"><h4><a class="selflink" name="section-5.1.3" href="#section-5.1.3">5.1.3</a>. Examples</h4></span> - - Example of a normal connection from an authorized client that then - terminates the session (see <a href="#section-5.4">Section 5.4</a>): - - [Initial connection set-up completed.] - [S] 200 NNTP Service Ready, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] QUIT - [S] 205 NNTP Service exits normally - [Server closes connection.] - - Example of a normal connection from an authorized client that is not - permitted to post, which also immediately terminates the session: - - [Initial connection set-up completed.] - [S] 201 NNTP Service Ready, posting prohibited - [<a href="#ref-C" title='"Demo User"'>C</a>] QUIT - [S] 205 NNTP Service exits normally - [Server closes connection.] - - Example of a normal connection from an unauthorized client: - - [Initial connection set-up completed.] - [S] 502 NNTP Service permanently unavailable - [Server closes connection.] - - Example of a connection from a client if the server is unable to - provide service: - - [Initial connection set-up completed.] - [S] 400 NNTP Service temporarily unavailable - [Server closes connection.] - -<span class="h3"><h3><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. CAPABILITIES</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Usage</h4></span> - - This command is mandatory. - - Syntax - CAPABILITIES [keyword] - - Responses - 101 Capability list follows (multi-line) - - - - -<span class="grey">Feather Standards Track [Page 29]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Parameters - keyword additional feature, see description - -<span class="h4"><h4><a class="selflink" name="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Description</h4></span> - - The CAPABILITIES command allows a client to determine the - capabilities of the server at any given time. - - This command MAY be issued at any time; the server MUST NOT require - it to be issued in order to make use of any capability. The response - generated by this command MAY change during a session because of - other state information (which, in turn, may be changed by the - effects of other commands or by external events). An NNTP client is - only able to get the current and correct information concerning - available capabilities at any point during a session by issuing a - CAPABILITIES command at that point of that session and processing the - response. - - The capability list is returned as a multi-line data block following - the 101 response code. Each capability is described by a separate - capability line. The server MUST NOT list the same capability twice - in the response, even with different arguments. Except that the - VERSION capability MUST be the first line, the order in which the - capability lines appears is not significant; the server need not even - consistently return the same order. - - While some capabilities are likely to be always available or never - available, others (notably extensions) will appear and disappear - depending on server state changes within the session or on external - events between sessions. An NNTP client MAY cache the results of - this command, but MUST NOT rely on the correctness of any cached - results, whether from earlier in this session or from a previous - session, MUST cope gracefully with the cached status being out of - date, and SHOULD (if caching results) provide a way to force the - cached information to be refreshed. Furthermore, a client MUST NOT - use cached results in relation to security, privacy, and - authentication extensions. See <a href="#section-12.6">Section 12.6</a> for further discussion - of this topic. - - The keyword argument is not used by this specification. It is - provided so that extensions or revisions to this specification can - include extra features for this command without requiring the - CAPABILITIES command to be used twice (once to determine if the extra - features are available, and a second time to make use of them). If - the server does not recognise the argument (and it is a keyword), it - MUST respond with the 101 response code as if the argument had been - omitted. If an argument is provided that the server does recognise, - it MAY use the 101 response code or MAY use some other response code - - - -<span class="grey">Feather Standards Track [Page 30]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - (which will be defined in the specification of that feature). If the - argument is not a keyword, the 501 generic response code MUST be - returned. The server MUST NOT generate any other response code to - the CAPABILITIES command. - -<span class="h4"><h4><a class="selflink" name="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Examples</h4></span> - - Example of a minimal response (a read-only server): - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] LIST ACTIVE NEWSGROUPS - [S] . - - Example of a response from a server that has a range of facilities - and that also describes itself: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] IHAVE - [S] POST - [S] NEWNEWS - [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT - [S] IMPLEMENTATION INN 4.2 2004-12-25 - [S] OVER MSGID - [S] STREAMING - [S] XSECRET - [S] . - - Example of a server that supports more than one version of NNTP: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 3 - [S] READER - [S] LIST ACTIVE NEWSGROUPS - [S] . - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 31]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of a client attempting to use a feature of the CAPABILITIES - command that the server does not support: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES AUTOUPDATE - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] IHAVE - [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS - [S] OVER MSGID - [S] HDR - [S] NEWNEWS - [S] . - -<span class="h3"><h3><a class="selflink" name="section-5.3" href="#section-5.3">5.3</a>. MODE READER</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Usage</h4></span> - - Indicating capability: MODE-READER - - This command MUST NOT be pipelined. - - Syntax - MODE READER - - Responses - 200 Posting allowed - 201 Posting prohibited - 502 Reading service permanently unavailable [<a href="#ref-1">1</a>] - - [<a name="ref-1" id="ref-1">1</a>] Following a 502 response the server MUST immediately close the - connection. - -<span class="h4"><h4><a class="selflink" name="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Description</h4></span> - - The MODE READER command instructs a mode-switching server to switch - modes, as described in <a href="#section-3.4.2">Section 3.4.2</a>. - - If the server is mode-switching, it switches from its transit mode to - its reader mode, indicating this by changing the capability list - accordingly. It MUST then return a 200 or 201 response with the same - meaning as for the initial greeting (as described in <a href="#section-5.1.1">Section 5.1.1</a>). - Note that the response need not be the same as that presented during - the initial greeting. The client MUST NOT issue MODE READER more - than once in a session or after any security or privacy commands are - issued. When the MODE READER command is issued, the server MAY reset - its state to that immediately after the initial connection before - switching mode. - - - -<span class="grey">Feather Standards Track [Page 32]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - If the server is not mode-switching, then the following apply: - - o If it advertises the READER capability, it MUST return a 200 or - 201 response with the same meaning as for the initial greeting; in - this case, the command MUST NOT affect the server state in any - way. - - o If it does not advertise the READER capability, it MUST return a - 502 response and then immediately close the connection. - -<span class="h4"><h4><a class="selflink" name="section-5.3.3" href="#section-5.3.3">5.3.3</a>. Examples</h4></span> - - Example of use of the MODE READER command on a transit-only server - (which therefore does not providing reading facilities): - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] IHAVE - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER - [S] 502 Transit service only - [Server closes connection.] - - Example of use of the MODE READER command on a server that provides - reading facilities: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] LIST ACTIVE NEWSGROUPS - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER - [S] 200 Reader mode, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] IHAVE <i.am.an.article.you.have@example.com> - [S] 500 Permission denied - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - - Note that in both of these situations, the client SHOULD NOT use MODE - READER. - - - - - - - - - -<span class="grey">Feather Standards Track [Page 33]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of use of the MODE READER command on a mode-switching server: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] IHAVE - [S] MODE-READER - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER - [S] 200 Reader mode, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] NEWNEWS - [S] LIST ACTIVE NEWSGROUPS - [S] STARTTLS - [S] . - - In this case, the server offers (but does not require) TLS privacy in - its reading mode but not in its transit mode. - - Example of use of the MODE READER command where the client is not - permitted to post: - - [<a name="ref-C" id="ref-C">C</a>] MODE READER - [S] 201 NNTP Service Ready, posting prohibited - -<span class="h3"><h3><a class="selflink" name="section-5.4" href="#section-5.4">5.4</a>. QUIT</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Usage</h4></span> - - This command is mandatory. - - Syntax - QUIT - - Responses - 205 Connection closing - -<span class="h4"><h4><a class="selflink" name="section-5.4.2" href="#section-5.4.2">5.4.2</a>. Description</h4></span> - - The client uses the QUIT command to terminate the session. The - server MUST acknowledge the QUIT command and then close the - connection to the client. This is the preferred method for a client - to indicate that it has finished all of its transactions with the - NNTP server. - - - - -<span class="grey">Feather Standards Track [Page 34]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - If a client simply disconnects (or if the connection times out or - some other fault occurs), the server MUST gracefully cease its - attempts to service the client, disconnecting from its end if - necessary. - - The server MUST NOT generate any response code to the QUIT command - other than 205 or, if any arguments are provided, 501. - -<span class="h4"><h4><a class="selflink" name="section-5.4.3" href="#section-5.4.3">5.4.3</a>. Examples</h4></span> - - [<a name="ref-C" id="ref-C">C</a>] QUIT - [S] 205 closing connection - [Server closes connection.] - -<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>. Article Posting and Retrieval</h2></span> - - News-reading clients have available a variety of mechanisms to - retrieve articles via NNTP. The news articles are stored and indexed - using three types of keys. The first type of key is the message-id - of an article and is globally unique. The second type of key is - composed of a newsgroup name and an article number within that - newsgroup. On a particular server, there MUST only be one article - with a given number within any newsgroup, and an article MUST NOT - have two different numbers in the same newsgroup. An article can be - cross-posted to multiple newsgroups, so there may be multiple keys - that point to the same article on the same server; these MAY have - different numbers in each newsgroup. However, this type of key is - not required to be globally unique, so the same key MAY refer to - different articles on different servers. (Note that the terms - "group" and "newsgroup" are equivalent.) - - The final type of key is the arrival timestamp, giving the time that - the article arrived at the server. The server MUST ensure that - article numbers are issued in order of arrival timestamp; that is, - articles arriving later MUST have higher numbers than those that - arrive earlier. The server SHOULD allocate the next sequential - unused number to each new article. - - Article numbers MUST lie between 1 and 2,147,483,647, inclusive. The - client and server MAY use leading zeroes in specifying article - numbers but MUST NOT use more than 16 digits. In some situations, - the value zero replaces an article number to show some special - situation. - - Note that it is likely that the article number limit of 2,147,483,647 - will be increased by a future revision or extension to this - specification. While servers MUST NOT send article numbers greater - than this current limit, client and server developers are advised to - - - -<span class="grey">Feather Standards Track [Page 35]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - use internal structures and datatypes capable of handling larger - values in anticipation of such a change. - -<span class="h3"><h3><a class="selflink" name="section-6.1" href="#section-6.1">6.1</a>. Group and Article Selection</h3></span> - - The following commands are used to set the "currently selected - newsgroup" and the "current article number", which are used by - various commands. At the start of an NNTP session, both of these - values are set to the special value "invalid". - -<span class="h4"><h4><a class="selflink" name="section-6.1.1" href="#section-6.1.1">6.1.1</a>. GROUP</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.1.1.1" href="#section-6.1.1.1">6.1.1.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - GROUP group - - Responses - 211 number low high group Group successfully selected - 411 No such newsgroup - - Parameters - group Name of newsgroup - number Estimated number of articles in the group - low Reported low water mark - high Reported high water mark - -<span class="h5"><h5><a class="selflink" name="section-6.1.1.2" href="#section-6.1.1.2">6.1.1.2</a>. Description</h5></span> - - The GROUP command selects a newsgroup as the currently selected - newsgroup and returns summary information about it. - - The required argument is the name of the newsgroup to be selected - (e.g., "news.software.nntp"). A list of valid newsgroups may be - obtained by using the LIST ACTIVE command (see <a href="#section-7.6.3">Section 7.6.3</a>). - - The successful selection response will return the article numbers of - the first and last articles in the group at the moment of selection - (these numbers are referred to as the "reported low water mark" and - the "reported high water mark") and an estimate of the number of - articles in the group currently available. - - If the group is not empty, the estimate MUST be at least the actual - number of articles available and MUST be no greater than one more - than the difference between the reported low and high water marks. - (Some implementations will actually count the number of articles - - - -<span class="grey">Feather Standards Track [Page 36]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - currently stored. Others will just subtract the low water mark from - the high water mark and add one to get an estimate.) - - If the group is empty, one of the following three situations will - occur. Clients MUST accept all three cases; servers MUST NOT - represent an empty group in any other way. - - o The high water mark will be one less than the low water mark, and - the estimated article count will be zero. Servers SHOULD use this - method to show an empty group. This is the only time that the - high water mark can be less than the low water mark. - - o All three numbers will be zero. - - o The high water mark is greater than or equal to the low water - mark. The estimated article count might be zero or non-zero; if - it is non-zero, the same requirements apply as for a non-empty - group. - - The set of articles in a group may change after the GROUP command is - carried out: - - o Articles may be removed from the group. - - o Articles may be reinstated in the group with the same article - number, but those articles MUST have numbers no less than the - reported low water mark (note that this is a reinstatement of the - previous article, not a new article reusing the number). - - o New articles may be added with article numbers greater than the - reported high water mark. (If an article that was the one with - the highest number has been removed and the high water mark has - been adjusted accordingly, the next new article will not have the - number one greater than the reported high water mark.) - - Except when the group is empty and all three numbers are zero, - whenever a subsequent GROUP command for the same newsgroup is issued, - either by the same client or a different client, the reported low - water mark in the response MUST be no less than that in any previous - response for that newsgroup in this session, and it SHOULD be no less - than that in any previous response for that newsgroup ever sent to - any client. Any failure to meet the latter condition SHOULD be - transient only. The client may make use of the low water mark to - remove all remembered information about articles with lower numbers, - as these will never recur. This includes the situation when the high - water mark is one less than the low water mark. No similar - assumption can be made about the high water mark, as this can - - - - -<span class="grey">Feather Standards Track [Page 37]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - decrease if an article is removed and then increase again if it is - reinstated or if new articles arrive. - - When a valid group is selected by means of this command, the - currently selected newsgroup MUST be set to that group, and the - current article number MUST be set to the first article in the group - (this applies even if the group is already the currently selected - newsgroup). If an empty newsgroup is selected, the current article - number is made invalid. If an invalid group is specified, the - currently selected newsgroup and current article number MUST NOT be - changed. - - The GROUP or LISTGROUP command (see <a href="#section-6.1.2">Section 6.1.2</a>) MUST be used by a - client, and a successful response received, before any other command - is used that depends on the value of the currently selected newsgroup - or current article number. - - If the group specified is not available on the server, a 411 response - MUST be returned. - -<span class="h5"><h5><a class="selflink" name="section-6.1.1.3" href="#section-6.1.1.3">6.1.1.3</a>. Examples</h5></span> - - Example for a group known to the server: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - - Example for a group unknown to the server: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.is.sob.bradner.or.barber - [S] 411 example.is.sob.bradner.or.barber is unknown - - Example of an empty group using the preferred response: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup - [S] 211 0 4000 3999 example.currently.empty.newsgroup - - Example of an empty group using an alternative response: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup - [S] 211 0 0 0 example.currently.empty.newsgroup - - Example of an empty group using a different alternative response: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup - [S] 211 0 4000 4321 example.currently.empty.newsgroup - - - - - -<span class="grey">Feather Standards Track [Page 38]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example reselecting the currently selected newsgroup: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 234 567 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 444 - [S] 223 444 <123456@example.net> retrieved - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP misc.test - [S] 211 1234 234 567 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [S] 223 234 <different@example.net> retrieved - -<span class="h4"><h4><a class="selflink" name="section-6.1.2" href="#section-6.1.2">6.1.2</a>. LISTGROUP</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.1.2.1" href="#section-6.1.2.1">6.1.2.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - LISTGROUP [group [range]] - - Responses - 211 number low high group Article numbers follow (multi-line) - 411 No such newsgroup - 412 No newsgroup selected [<a href="#ref-1">1</a>] - - Parameters - group Name of newsgroup - range Range of articles to report - number Estimated number of articles in the group - low Reported low water mark - high Reported high water mark - - [<a name="ref-1" id="ref-1">1</a>] The 412 response can only occur if no group has been specified. - -<span class="h5"><h5><a class="selflink" name="section-6.1.2.2" href="#section-6.1.2.2">6.1.2.2</a>. Description</h5></span> - - The LISTGROUP command selects a newsgroup in the same manner as the - GROUP command (see <a href="#section-6.1.1">Section 6.1.1</a>) but also provides a list of article - numbers in the newsgroup. If no group is specified, the currently - selected newsgroup is used. - - On success, a list of article numbers is returned as a multi-line - data block following the 211 response code (the arguments on the - initial response line are the same as for the GROUP command). The - list contains one number per line and is in numerical order. It - lists precisely those articles that exist in the group at the moment - of selection (therefore, an empty group produces an empty list). If - the optional range argument is specified, only articles within the - - - -<span class="grey">Feather Standards Track [Page 39]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - range are included in the list (therefore, the list MAY be empty even - if the group is not). - - The range argument may be any of the following: - - o An article number. - - o An article number followed by a dash to indicate all following. - - o An article number followed by a dash followed by another article - number. - - In the last case, if the second number is less than the first number, - then the range contains no articles. Omitting the range is - equivalent to the range 1- being specified. - - If the group specified is not available on the server, a 411 response - MUST be returned. If no group is specified and the currently - selected newsgroup is invalid, a 412 response MUST be returned. - - Except that the group argument is optional, that a range argument can - be specified, and that a multi-line data block follows the 211 - response code, the LISTGROUP command is identical to the GROUP - command. In particular, when successful, the command sets the - current article number to the first article in the group, if any, - even if this is not within the range specified by the second - argument. - - Note that the range argument is a new feature in this specification - and servers that do not support CAPABILITIES (and therefore do not - conform to this specification) are unlikely to support it. - -<span class="h5"><h5><a class="selflink" name="section-6.1.2.3" href="#section-6.1.2.3">6.1.2.3</a>. Examples</h5></span> - - Example of LISTGROUP being used to select a group: - - [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test - [S] 211 2000 3000234 3002322 misc.test list follows - [S] 3000234 - [S] 3000237 - [S] 3000238 - [S] 3000239 - [S] 3002322 - [S] . - - - - - - - -<span class="grey">Feather Standards Track [Page 40]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of LISTGROUP on an empty group: - - [<a name="ref-C" id="ref-C">C</a>] LISTGROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup list follows - [S] . - - Example of LISTGROUP on a valid, currently selected newsgroup: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 2000 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] LISTGROUP - [S] 211 2000 3000234 3002322 misc.test list follows - [S] 3000234 - [S] 3000237 - [S] 3000238 - [S] 3000239 - [S] 3002322 - [S] . - - Example of LISTGROUP with a range: - - [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 3000238-3000248 - [S] 211 2000 3000234 3002322 misc.test list follows - [S] 3000238 - [S] 3000239 - [S] . - - Example of LISTGROUP with an empty range: - - [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 12345678- - [S] 211 2000 3000234 3002322 misc.test list follows - [S] . - - Example of LISTGROUP with an invalid range: - - [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 9999-111 - [S] 211 2000 3000234 3002322 misc.test list follows - [S] . - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 41]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-6.1.3" href="#section-6.1.3">6.1.3</a>. LAST</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.1.3.1" href="#section-6.1.3.1">6.1.3.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - LAST - - Responses - 223 n message-id Article found - 412 No newsgroup selected - 420 Current article number is invalid - 422 No previous article in this group - - Parameters - n Article number - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.1.3.2" href="#section-6.1.3.2">6.1.3.2</a>. Description</h5></span> - - If the currently selected newsgroup is valid, the current article - number MUST be set to the previous article in that newsgroup (that - is, the highest existing article number less than the current article - number). If successful, a response indicating the new current - article number and the message-id of that article MUST be returned. - No article text is sent in response to this command. - - There MAY be no previous article in the group, although the current - article number is not the reported low water mark. There MUST NOT be - a previous article when the current article number is the reported - low water mark. - - Because articles can be removed and added, the results of multiple - LAST and NEXT commands MAY not be consistent over the life of a - particular NNTP session. - - If the current article number is already the first article of the - newsgroup, a 422 response MUST be returned. If the current article - number is invalid, a 420 response MUST be returned. If the currently - selected newsgroup is invalid, a 412 response MUST be returned. In - all three cases, the currently selected newsgroup and current article - number MUST NOT be altered. - - - - - - - - -<span class="grey">Feather Standards Track [Page 42]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h5"><h5><a class="selflink" name="section-6.1.3.3" href="#section-6.1.3.3">6.1.3.3</a>. Examples</h5></span> - - Example of a successful article retrieval using LAST: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 223 3000237 <668929@example.org> retrieved - [<a href="#ref-C" title='"Demo User"'>C</a>] LAST - [S] 223 3000234 <45223423@example.com> retrieved - - Example of an attempt to retrieve an article without having selected - a group (via the GROUP command) first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] LAST - [S] 412 no newsgroup selected - - Example of an attempt to retrieve an article using the LAST command - when the current article number is that of the first article in the - group: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] LAST - [S] 422 No previous article to retrieve - - Example of an attempt to retrieve an article using the LAST command - when the currently selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] LAST - [S] 420 No current article selected - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 43]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-6.1.4" href="#section-6.1.4">6.1.4</a>. NEXT</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.1.4.1" href="#section-6.1.4.1">6.1.4.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - NEXT - - Responses - 223 n message-id Article found - 412 No newsgroup selected - 420 Current article number is invalid - 421 No next article in this group - - Parameters - n Article number - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.1.4.2" href="#section-6.1.4.2">6.1.4.2</a>. Description</h5></span> - - If the currently selected newsgroup is valid, the current article - number MUST be set to the next article in that newsgroup (that is, - the lowest existing article number greater than the current article - number). If successful, a response indicating the new current - article number and the message-id of that article MUST be returned. - No article text is sent in response to this command. - - If the current article number is already the last article of the - newsgroup, a 421 response MUST be returned. In all other aspects - (apart, of course, from the lack of 422 response), this command is - identical to the LAST command (<a href="#section-6.1.3">Section 6.1.3</a>). - -<span class="h5"><h5><a class="selflink" name="section-6.1.4.3" href="#section-6.1.4.3">6.1.4.3</a>. Examples</h5></span> - - Example of a successful article retrieval using NEXT: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 223 3000237 <668929@example.org> retrieved - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 44]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an attempt to retrieve an article without having selected - a group (via the GROUP command) first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 412 no newsgroup selected - - Example of an attempt to retrieve an article using the NEXT command - when the current article number is that of the last article in the - group: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 3002322 - [S] 223 3002322 <411@example.net> retrieved - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 421 No next article to retrieve - - Example of an attempt to retrieve an article using the NEXT command - when the currently selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT - [S] 420 No current article selected - -<span class="h3"><h3><a class="selflink" name="section-6.2" href="#section-6.2">6.2</a>. Retrieval of Articles and Article Sections</h3></span> - - The ARTICLE, BODY, HEAD, and STAT commands are very similar. They - differ only in the parts of the article that are presented to the - client and in the successful response code. The ARTICLE command is - described here in full, while the other three commands are described - in terms of the differences. As specified in <a href="#section-3.6">Section 3.6</a>, an article - consists of two parts: the article headers and the article body. - - When responding to one of these commands, the server MUST present the - entire article or appropriate part and MUST NOT attempt to alter or - translate it in any way. - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 45]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-6.2.1" href="#section-6.2.1">6.2.1</a>. ARTICLE</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.2.1.1" href="#section-6.2.1.1">6.2.1.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - ARTICLE message-id - ARTICLE number - ARTICLE - - Responses - - First form (message-id specified) - 220 0|n message-id Article follows (multi-line) - 430 No article with that message-id - - Second form (article number specified) - 220 n message-id Article follows (multi-line) - 412 No newsgroup selected - 423 No article with that number - - Third form (current article number used) - 220 n message-id Article follows (multi-line) - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - number Requested article number - n Returned article number - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.2.1.2" href="#section-6.2.1.2">6.2.1.2</a>. Description</h5></span> - - The ARTICLE command selects an article according to the arguments and - presents the entire article (that is, the headers, an empty line, and - the body, in that order) to the client. The command has three forms. - - In the first form, a message-id is specified, and the server presents - the article with that message-id. In this case, the server MUST NOT - alter the currently selected newsgroup or current article number. - This is both to facilitate the presentation of articles that may be - referenced within another article being read, and because of the - semantic difficulties of determining the proper sequence and - membership of an article that may have been cross-posted to more than - one newsgroup. - - - - - -<span class="grey">Feather Standards Track [Page 46]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - In the response, the article number MUST be replaced with zero, - unless there is a currently selected newsgroup and the article is - present in that group, in which case the server MAY use the article's - number in that group. (The server is not required to determine - whether the article is in the currently selected newsgroup or, if so, - what article number it has; the client MUST always be prepared for - zero to be specified.) The server MUST NOT provide an article number - unless use of that number in a second ARTICLE command immediately - following this one would return the same article. Even if the server - chooses to return article numbers in these circumstances, it need not - do so consistently; it MAY return zero to any such command (also see - the STAT examples, <a href="#section-6.2.4.3">Section 6.2.4.3</a>). - - In the second form, an article number is specified. If there is an - article with that number in the currently selected newsgroup, the - server MUST set the current article number to that number. - - In the third form, the article indicated by the current article - number in the currently selected newsgroup is used. - - Note that a previously valid article number MAY become invalid if the - article has been removed. A previously invalid article number MAY - become valid if the article has been reinstated, but this article - number MUST be no less than the reported low water mark for that - group. - - The server MUST NOT change the currently selected newsgroup as a - result of this command. The server MUST NOT change the current - article number except when an article number argument was provided - and the article exists; in particular, it MUST NOT change it - following an unsuccessful response. - - Since the message-id is unique for each article, it may be used by a - client to skip duplicate displays of articles that have been posted - more than once, or to more than one newsgroup. - - The article is returned as a multi-line data block following the 220 - response code. - - If the argument is a message-id and no such article exists, a 430 - response MUST be returned. If the argument is a number or is omitted - and the currently selected newsgroup is invalid, a 412 response MUST - be returned. If the argument is a number and that article does not - exist in the currently selected newsgroup, a 423 response MUST be - returned. If the argument is omitted and the current article number - is invalid, a 420 response MUST be returned. - - - - - -<span class="grey">Feather Standards Track [Page 47]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h5"><h5><a class="selflink" name="section-6.2.1.3" href="#section-6.2.1.3">6.2.1.3</a>. Examples</h5></span> - - Example of a successful retrieval of an article (explicitly not using - an article number): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE - [S] 220 3000234 <45223423@example.com> - [S] Path: pathost!demo!whitehouse!not-for-mail - [S] From: "Demo User" <nobody@example.net> - [S] Newsgroups: misc.test - [S] Subject: I am just a test article - [S] Date: 6 Oct 1998 04:38:40 -0500 - [S] Organization: An Example Net, Uncertain, Texas - [S] Message-ID: <45223423@example.com> - [S] - [S] This is just a test article. - [S] . - - Example of a successful retrieval of an article by message-id: - - [<a name="ref-C" id="ref-C">C</a>] ARTICLE <45223423@example.com> - [S] 220 0 <45223423@example.com> - [S] Path: pathost!demo!whitehouse!not-for-mail - [S] From: "Demo User" <nobody@example.net> - [S] Newsgroups: misc.test - [S] Subject: I am just a test article - [S] Date: 6 Oct 1998 04:38:40 -0500 - [S] Organization: An Example Net, Uncertain, Texas - [S] Message-ID: <45223423@example.com> - [S] - [S] This is just a test article. - [S] . - - Example of an unsuccessful retrieval of an article by message-id: - - [<a name="ref-C" id="ref-C">C</a>] ARTICLE <i.am.not.there@example.com> - [S] 430 No Such Article Found - - Example of an unsuccessful retrieval of an article by number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 news.groups - [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE 300256 - [S] 423 No article with that number - - - - - -<span class="grey">Feather Standards Track [Page 48]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an unsuccessful retrieval of an article by number because - no newsgroup was selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE 300256 - [S] 412 No newsgroup selected - - Example of an attempt to retrieve an article when the currently - selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE - [S] 420 No current article selected - -<span class="h4"><h4><a class="selflink" name="section-6.2.2" href="#section-6.2.2">6.2.2</a>. HEAD</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.2.2.1" href="#section-6.2.2.1">6.2.2.1</a>. Usage</h5></span> - - This command is mandatory. - - Syntax - HEAD message-id - HEAD number - HEAD - - Responses - - First form (message-id specified) - 221 0|n message-id Headers follow (multi-line) - 430 No article with that message-id - - Second form (article number specified) - 221 n message-id Headers follow (multi-line) - 412 No newsgroup selected - 423 No article with that number - - Third form (current article number used) - 221 n message-id Headers follow (multi-line) - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - number Requested article number - n Returned article number - message-id Article message-id - - - - - -<span class="grey">Feather Standards Track [Page 49]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h5"><h5><a class="selflink" name="section-6.2.2.2" href="#section-6.2.2.2">6.2.2.2</a>. Description</h5></span> - - The HEAD command behaves identically to the ARTICLE command except - that, if the article exists, the response code is 221 instead of 220 - and only the headers are presented (the empty line separating the - headers and body MUST NOT be included). - -<span class="h5"><h5><a class="selflink" name="section-6.2.2.3" href="#section-6.2.2.3">6.2.2.3</a>. Examples</h5></span> - - Example of a successful retrieval of the headers of an article - (explicitly not using an article number): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD - [S] 221 3000234 <45223423@example.com> - [S] Path: pathost!demo!whitehouse!not-for-mail - [S] From: "Demo User" <nobody@example.net> - [S] Newsgroups: misc.test - [S] Subject: I am just a test article - [S] Date: 6 Oct 1998 04:38:40 -0500 - [S] Organization: An Example Net, Uncertain, Texas - [S] Message-ID: <45223423@example.com> - [S] . - - Example of a successful retrieval of the headers of an article by - message-id: - - [<a name="ref-C" id="ref-C">C</a>] HEAD <45223423@example.com> - [S] 221 0 <45223423@example.com> - [S] Path: pathost!demo!whitehouse!not-for-mail - [S] From: "Demo User" <nobody@example.net> - [S] Newsgroups: misc.test - [S] Subject: I am just a test article - [S] Date: 6 Oct 1998 04:38:40 -0500 - [S] Organization: An Example Net, Uncertain, Texas - [S] Message-ID: <45223423@example.com> - [S] . - - Example of an unsuccessful retrieval of the headers of an article by - message-id: - - [<a name="ref-C" id="ref-C">C</a>] HEAD <i.am.not.there@example.com> - [S] 430 No Such Article Found - - - - - - - -<span class="grey">Feather Standards Track [Page 50]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an unsuccessful retrieval of the headers of an article by - number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD 300256 - [S] 423 No article with that number - - Example of an unsuccessful retrieval of the headers of an article by - number because no newsgroup was selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD 300256 - [S] 412 No newsgroup selected - - Example of an attempt to retrieve the headers of an article when the - currently selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD - [S] 420 No current article selected - -<span class="h4"><h4><a class="selflink" name="section-6.2.3" href="#section-6.2.3">6.2.3</a>. BODY</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.2.3.1" href="#section-6.2.3.1">6.2.3.1</a>. Usage</h5></span> - - Indicating capability: READER - - Syntax - BODY message-id - BODY number - BODY - - Responses - - First form (message-id specified) - 222 0|n message-id Body follows (multi-line) - 430 No article with that message-id - - Second form (article number specified) - 222 n message-id Body follows (multi-line) - 412 No newsgroup selected - 423 No article with that number - - - - - - - -<span class="grey">Feather Standards Track [Page 51]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Third form (current article number used) - 222 n message-id Body follows (multi-line) - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - number Requested article number - n Returned article number - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.2.3.2" href="#section-6.2.3.2">6.2.3.2</a>. Description</h5></span> - - The BODY command behaves identically to the ARTICLE command except - that, if the article exists, the response code is 222 instead of 220 - and only the body is presented (the empty line separating the headers - and body MUST NOT be included). - -<span class="h5"><h5><a class="selflink" name="section-6.2.3.3" href="#section-6.2.3.3">6.2.3.3</a>. Examples</h5></span> - - Example of a successful retrieval of the body of an article - (explicitly not using an article number): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] BODY - [S] 222 3000234 <45223423@example.com> - [S] This is just a test article. - [S] . - - Example of a successful retrieval of the body of an article by - message-id: - - [<a name="ref-C" id="ref-C">C</a>] BODY <45223423@example.com> - [S] 222 0 <45223423@example.com> - [S] This is just a test article. - [S] . - - Example of an unsuccessful retrieval of the body of an article by - message-id: - - [<a name="ref-C" id="ref-C">C</a>] BODY <i.am.not.there@example.com> - [S] 430 No Such Article Found - - - - - - - - - -<span class="grey">Feather Standards Track [Page 52]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an unsuccessful retrieval of the body of an article by - number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] BODY 300256 - [S] 423 No article with that number - - Example of an unsuccessful retrieval of the body of an article by - number because no newsgroup was selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] BODY 300256 - [S] 412 No newsgroup selected - - Example of an attempt to retrieve the body of an article when the - currently selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] BODY - [S] 420 No current article selected - -<span class="h4"><h4><a class="selflink" name="section-6.2.4" href="#section-6.2.4">6.2.4</a>. STAT</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.2.4.1" href="#section-6.2.4.1">6.2.4.1</a>. Usage</h5></span> - - This command is mandatory. - - Syntax - STAT message-id - STAT number - STAT - - Responses - - First form (message-id specified) - 223 0|n message-id Article exists - 430 No article with that message-id - - Second form (article number specified) - 223 n message-id Article exists - 412 No newsgroup selected - 423 No article with that number - - - - - - - -<span class="grey">Feather Standards Track [Page 53]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Third form (current article number used) - 223 n message-id Article exists - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - number Requested article number - n Returned article number - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.2.4.2" href="#section-6.2.4.2">6.2.4.2</a>. Description</h5></span> - - The STAT command behaves identically to the ARTICLE command except - that, if the article exists, it is NOT presented to the client and - the response code is 223 instead of 220. Note that the response is - NOT multi-line. - - This command allows the client to determine whether an article exists - and, in the second and third forms, what its message-id is, without - having to process an arbitrary amount of text. - -<span class="h5"><h5><a class="selflink" name="section-6.2.4.3" href="#section-6.2.4.3">6.2.4.3</a>. Examples</h5></span> - - Example of STAT on an existing article (explicitly not using an - article number): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [S] 223 3000234 <45223423@example.com> - - Example of STAT on an existing article by message-id: - - [<a name="ref-C" id="ref-C">C</a>] STAT <45223423@example.com> - [S] 223 0 <45223423@example.com> - - Example of STAT on an article not on the server by message-id: - - [<a name="ref-C" id="ref-C">C</a>] STAT <i.am.not.there@example.com> - [S] 430 No Such Article Found - - Example of STAT on an article not in the server by number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 300256 - [S] 423 No article with that number - - - - -<span class="grey">Feather Standards Track [Page 54]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of STAT on an article by number when no newsgroup was - selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 300256 - [S] 412 No newsgroup selected - - Example of STAT on an article when the currently selected newsgroup - is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [S] 420 No current article selected - - Example of STAT by message-id on a server that sometimes reports the - actual article number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [S] 223 3000234 <45223423@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> - [S] 223 0 <45223423@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> - [S] 223 3000234 <45223423@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> - [S] 223 0 <45223423@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP alt.crossposts - [S] 211 9999 111111 222222 alt.crossposts - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> - [S] 223 123456 <45223423@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] STAT - [S] 223 111111 <23894720@example.com> - - The first STAT command establishes the identity of an article in the - group. The second and third show that the server may, but need not, - give the article number when the message-id is specified. The fourth - STAT command shows that zero must be specified if the article isn't - in the currently selected newsgroup. The fifth shows that the - number, if provided, must be that relating to the currently selected - newsgroup. The last one shows that the current article number is - still not changed by the use of STAT with a message-id even if it - returns an article number. - - - - - -<span class="grey">Feather Standards Track [Page 55]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-6.3" href="#section-6.3">6.3</a>. Article Posting</h3></span> - - Article posting is done in one of two ways: individual article - posting from news-reading clients using POST, and article transfer - from other news servers using IHAVE. - -<span class="h4"><h4><a class="selflink" name="section-6.3.1" href="#section-6.3.1">6.3.1</a>. POST</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.3.1.1" href="#section-6.3.1.1">6.3.1.1</a>. Usage</h5></span> - - Indicating capability: POST - - This command MUST NOT be pipelined. - - Syntax - POST - - Responses - - Initial responses - 340 Send article to be posted - 440 Posting not permitted - - Subsequent responses - 240 Article received OK - 441 Posting failed - -<span class="h5"><h5><a class="selflink" name="section-6.3.1.2" href="#section-6.3.1.2">6.3.1.2</a>. Description</h5></span> - - If posting is allowed, a 340 response MUST be returned to indicate - that the article to be posted should be sent. If posting is - prohibited for some installation-dependent reason, a 440 response - MUST be returned. - - If posting is permitted, the article MUST be in the format specified - in <a href="#section-3.6">Section 3.6</a> and MUST be sent by the client to the server as a - multi-line data block (see <a href="#section-3.1.1">Section 3.1.1</a>). Thus a single dot (".") - on a line indicates the end of the text, and lines starting with a - dot in the original text have that dot doubled during transmission. - - Following the presentation of the termination sequence by the client, - the server MUST return a response indicating success or failure of - the article transfer. Note that response codes 340 and 440 are used - in direct response to the POST command while 240 and 441 are returned - after the article is sent. - - - - - - -<span class="grey">Feather Standards Track [Page 56]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - A response of 240 SHOULD indicate that, barring unforeseen server - errors, the posted article will be made available on the server - and/or transferred to other servers, as appropriate, possibly - following further processing. In other words, articles not wanted by - the server SHOULD be rejected with a 441 response, rather than being - accepted and then discarded silently. However, the client SHOULD NOT - assume that the article has been successfully transferred unless it - receives an affirmative response from the server and SHOULD NOT - assume that it is being made available to other clients without - explicitly checking (for example, using the STAT command). - - If the session is interrupted before the response is received, it is - possible that an affirmative response was sent but has been lost. - Therefore, in any subsequent session, the client SHOULD either check - whether the article was successfully posted before resending or - ensure that the server will allocate the same message-id to the new - attempt (see <a href="#appendix-A.2">Appendix A.2</a>). The latter approach is preferred since - the article might not have been made available for reading yet (for - example, it may have to go through a moderation process). - -<span class="h5"><h5><a class="selflink" name="section-6.3.1.3" href="#section-6.3.1.3">6.3.1.3</a>. Examples</h5></span> - - Example of a successful posting: - - [<a name="ref-C" id="ref-C">C</a>] POST - [S] 340 Input article; end with <CR-LF>.<CR-LF> - [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.net> - [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article - [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Net - [<a href="#ref-C" title='"Demo User"'>C</a>] - [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. - [<a href="#ref-C" title='"Demo User"'>C</a>] . - [S] 240 Article received OK - - Example of an unsuccessful posting: - - [<a name="ref-C" id="ref-C">C</a>] POST - [S] 340 Input article; end with <CR-LF>.<CR-LF> - [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.net> - [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article - [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Net - [<a href="#ref-C" title='"Demo User"'>C</a>] - [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. - [<a href="#ref-C" title='"Demo User"'>C</a>] . - [S] 441 Posting failed - - - - -<span class="grey">Feather Standards Track [Page 57]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an attempt to post when posting is not allowed: - - [Initial connection set-up completed.] - [S] 201 NNTP Service Ready, posting prohibited - [<a href="#ref-C" title='"Demo User"'>C</a>] POST - [S] 440 Posting not permitted - -<span class="h4"><h4><a class="selflink" name="section-6.3.2" href="#section-6.3.2">6.3.2</a>. IHAVE</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-6.3.2.1" href="#section-6.3.2.1">6.3.2.1</a>. Usage</h5></span> - - Indicating capability: IHAVE - - This command MUST NOT be pipelined. - - Syntax - IHAVE message-id - - Responses - - Initial responses - 335 Send article to be transferred - 435 Article not wanted - 436 Transfer not possible; try again later - - Subsequent responses - 235 Article transferred OK - 436 Transfer failed; try again later - 437 Transfer rejected; do not retry - - Parameters - message-id Article message-id - -<span class="h5"><h5><a class="selflink" name="section-6.3.2.2" href="#section-6.3.2.2">6.3.2.2</a>. Description</h5></span> - - The IHAVE command informs the server that the client has an article - with the specified message-id. If the server desires a copy of that - article, a 335 response MUST be returned, instructing the client to - send the entire article. If the server does not want the article - (if, for example, the server already has a copy of it), a 435 - response MUST be returned, indicating that the article is not wanted. - Finally, if the article isn't wanted immediately but the client - should retry later if possible (if, for example, another client is in - the process of sending the same article to the server), a 436 - response MUST be returned. - - - - - - -<span class="grey">Feather Standards Track [Page 58]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - If transmission of the article is requested, the client MUST send the - entire article, including headers and body, to the server as a - multi-line data block (see <a href="#section-3.1.1">Section 3.1.1</a>). Thus, a single dot (".") - on a line indicates the end of the text, and lines starting with a - dot in the original text have that dot doubled during transmission. - The server MUST return a 235 response, indicating that the article - was successfully transferred; a 436 response, indicating that the - transfer failed but should be tried again later; or a 437 response, - indicating that the article was rejected. - - This function differs from the POST command in that it is intended - for use in transferring already-posted articles between hosts. It - SHOULD NOT be used when the client is a personal news-reading - program, since use of this command indicates that the article has - already been posted at another site and is simply being forwarded - from another host. However, despite this, the server MAY elect not - to post or forward the article if, after further examination of the - article, it deems it inappropriate to do so. Reasons for such - subsequent rejection of an article may include problems such as - inappropriate newsgroups or distributions, disc space limitations, - article lengths, garbled headers, and the like. These are typically - restrictions enforced by the server host's news software and not - necessarily by the NNTP server itself. - - The client SHOULD NOT assume that the article has been successfully - transferred unless it receives an affirmative response from the - server. A lack of response (such as a dropped network connection or - a network timeout) SHOULD be treated the same as a 436 response. - - Because some news server software may not immediately be able to - determine whether an article is suitable for posting or forwarding, - an NNTP server MAY acknowledge the successful transfer of the article - (with a 235 response) but later silently discard it. - - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 59]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h5"><h5><a class="selflink" name="section-6.3.2.3" href="#section-6.3.2.3">6.3.2.3</a>. Examples</h5></span> - - Example of successfully sending an article to another site: - - [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> - [S] 335 Send it; end with <CR-LF>.<CR-LF> - [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail - [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article - [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 - [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA - [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.will.want@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] - [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. - [<a href="#ref-C" title='"Demo User"'>C</a>] . - [S] 235 Article transferred OK - - Example of sending an article to another site that rejects it. Note - that the message-id in the IHAVE command is not the same as the one - in the article headers; while this is bad practice and SHOULD NOT be - done, it is not forbidden. - - [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> - [S] 335 Send it; end with <CR-LF>.<CR-LF> - [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail - [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article - [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 - [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA - [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.have@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] - [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. - [<a href="#ref-C" title='"Demo User"'>C</a>] . - [S] 437 Article rejected; don't send again - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 60]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of sending an article to another site where the transfer - fails: - - [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> - [S] 335 Send it; end with <CR-LF>.<CR-LF> - [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail - [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article - [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 - [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA - [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.will.want@example.com> - [<a href="#ref-C" title='"Demo User"'>C</a>] - [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. - [<a href="#ref-C" title='"Demo User"'>C</a>] . - [S] 436 Transfer failed - - Example of sending an article to a site that already has it: - - [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.have@example.com> - [S] 435 Duplicate - - Example of sending an article to a site that requests that the - article be tried again later: - - [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.defer@example.com> - [S] 436 Retry later - -<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>. Information Commands</h2></span> - - This section lists other commands that may be used at any time - between the beginning of a session and its termination. Using these - commands does not alter any state information, but the response - generated from their use may provide useful information to clients. - -<span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. DATE</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-7.1.1" href="#section-7.1.1">7.1.1</a>. Usage</h4></span> - - Indicating capability: READER - - Syntax - DATE - - Responses - 111 yyyymmddhhmmss Server date and time - - - - - -<span class="grey">Feather Standards Track [Page 61]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Parameters - yyyymmddhhmmss Current UTC date and time on server - -<span class="h4"><h4><a class="selflink" name="section-7.1.2" href="#section-7.1.2">7.1.2</a>. Description</h4></span> - - This command exists to help clients find out the current Coordinated - Universal Time [<a href="#ref-TF.686-1" title='"Glossary, ITU-R Recommendation TF.686-1"'>TF.686-1</a>] from the server's perspective. This - command SHOULD NOT be used as a substitute for NTP [<a href="https://tools.ietf.org/html/rfc1305" title='"Network Time Protocol (Version 3) Specification, Implementation and Analysis"'>RFC1305</a>] but to - provide information that might be useful when using the NEWNEWS - command (see <a href="#section-7.4">Section 7.4</a>). - - The DATE command MUST return a timestamp from the same clock as is - used for determining article arrival and group creation times (see - <a href="#section-6">Section 6</a>). This clock SHOULD be monotonic, and adjustments SHOULD - be made by running it fast or slow compared to "real" time rather - than by making sudden jumps. A system providing NNTP service SHOULD - keep the system clock as accurate as possible, either with NTP or by - some other method. - - The server MUST return a 111 response specifying the date and time on - the server in the form yyyymmddhhmmss. This date and time is in - Coordinated Universal Time. - -<span class="h4"><h4><a class="selflink" name="section-7.1.3" href="#section-7.1.3">7.1.3</a>. Examples</h4></span> - - [<a name="ref-C" id="ref-C">C</a>] DATE - [S] 111 19990623135624 - -<span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. HELP</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-7.2.1" href="#section-7.2.1">7.2.1</a>. Usage</h4></span> - - This command is mandatory. - - Syntax - HELP - - Responses - 100 Help text follows (multi-line) - -<span class="h4"><h4><a class="selflink" name="section-7.2.2" href="#section-7.2.2">7.2.2</a>. Description</h4></span> - - This command provides a short summary of the commands that are - understood by this implementation of the server. The help text will - be presented as a multi-line data block following the 100 response - code. - - - - - -<span class="grey">Feather Standards Track [Page 62]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - This text is not guaranteed to be in any particular format (but must - be UTF-8) and MUST NOT be used by clients as a replacement for the - CAPABILITIES command described in <a href="#section-5.2">Section 5.2</a>. - -<span class="h4"><h4><a class="selflink" name="section-7.2.3" href="#section-7.2.3">7.2.3</a>. Examples</h4></span> - - [<a name="ref-C" id="ref-C">C</a>] HELP - [S] 100 Help text follows - [S] This is some help text. There is no specific - [S] formatting requirement for this test, though - [S] it is customary for it to list the valid commands - [S] and give a brief definition of what they do. - [S] . - -<span class="h3"><h3><a class="selflink" name="section-7.3" href="#section-7.3">7.3</a>. NEWGROUPS</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-7.3.1" href="#section-7.3.1">7.3.1</a>. Usage</h4></span> - - Indicating capability: READER - - Syntax - NEWGROUPS date time [GMT] - - Responses - 231 List of new newsgroups follows (multi-line) - - Parameters - date Date in yymmdd or yyyymmdd format - time Time in hhmmss format - -<span class="h4"><h4><a class="selflink" name="section-7.3.2" href="#section-7.3.2">7.3.2</a>. Description</h4></span> - - This command returns a list of newsgroups created on the server since - the specified date and time. The results are in the same format as - the LIST ACTIVE command (see <a href="#section-7.6.3">Section 7.6.3</a>). However, they MAY - include groups not available on the server (and so not returned by - LIST ACTIVE) and MAY omit groups for which the creation date is not - available. - - The date is specified as 6 or 8 digits in the format [xx]yymmdd, - where xx is the first two digits of the year (19-99), yy is the last - two digits of the year (00-99), mm is the month (01-12), and dd is - the day of the month (01-31). Clients SHOULD specify all four digits - of the year. If the first two digits of the year are not specified - (this is supported only for backward compatibility), the year is to - be taken from the current century if yy is smaller than or equal to - the current year, and the previous century otherwise. - - - - -<span class="grey">Feather Standards Track [Page 63]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The time is specified as 6 digits in the format hhmmss, where hh is - the hours in the 24-hour clock (00-23), mm is the minutes (00-59), - and ss is the seconds (00-60, to allow for leap seconds). The token - "GMT" specifies that the date and time are given in Coordinated - Universal Time [<a href="#ref-TF.686-1" title='"Glossary, ITU-R Recommendation TF.686-1"'>TF.686-1</a>]; if it is omitted, then the date and time - are specified in the server's local timezone. Note that there is no - way of using the protocol specified in this document to establish the - server's local timezone. - - Note that an empty list is a possible valid response and indicates - that there are no new newsgroups since that date-time. - - Clients SHOULD make all queries using Coordinated Universal Time - (i.e., by including the "GMT" argument) when possible. - -<span class="h4"><h4><a class="selflink" name="section-7.3.3" href="#section-7.3.3">7.3.3</a>. Examples</h4></span> - - Example where there are new groups: - - [<a name="ref-C" id="ref-C">C</a>] NEWGROUPS 19990624 000000 GMT - [S] 231 list of new newsgroups follows - [S] alt.rfc-writers.recovery 4 1 y - [S] tx.natives.recovery 89 56 y - [S] . - - Example where there are no new groups: - - [<a name="ref-C" id="ref-C">C</a>] NEWGROUPS 19990624 000000 GMT - [S] 231 list of new newsgroups follows - [S] . - -<span class="h3"><h3><a class="selflink" name="section-7.4" href="#section-7.4">7.4</a>. NEWNEWS</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-7.4.1" href="#section-7.4.1">7.4.1</a>. Usage</h4></span> - - Indicating capability: NEWNEWS - - Syntax - NEWNEWS wildmat date time [GMT] - - Responses - 230 List of new articles follows (multi-line) - - Parameters - wildmat Newsgroups of interest - date Date in yymmdd or yyyymmdd format - time Time in hhmmss format - - - - -<span class="grey">Feather Standards Track [Page 64]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-7.4.2" href="#section-7.4.2">7.4.2</a>. Description</h4></span> - - This command returns a list of message-ids of articles posted or - received on the server, in the newsgroups whose names match the - wildmat, since the specified date and time. One message-id is sent - on each line; the order of the response has no specific significance - and may vary from response to response in the same session. A - message-id MAY appear more than once; if it does, it has the same - meaning as if it appeared only once. - - Date and time are in the same format as the NEWGROUPS command (see - <a href="#section-7.3">Section 7.3</a>). - - Note that an empty list is a possible valid response and indicates - that there is currently no new news in the relevant groups. - - Clients SHOULD make all queries in Coordinated Universal Time (i.e., - by using the "GMT" argument) when possible. - -<span class="h4"><h4><a class="selflink" name="section-7.4.3" href="#section-7.4.3">7.4.3</a>. Examples</h4></span> - - Example where there are new articles: - - [<a name="ref-C" id="ref-C">C</a>] NEWNEWS news.*,sci.* 19990624 000000 GMT - [S] 230 list of new articles by message-id follows - [S] <i.am.a.new.article@example.com> - [S] <i.am.another.new.article@example.com> - [S] . - - Example where there are no new articles: - - [<a name="ref-C" id="ref-C">C</a>] NEWNEWS alt.* 19990624 000000 GMT - [S] 230 list of new articles by message-id follows - [S] . - -<span class="h3"><h3><a class="selflink" name="section-7.5" href="#section-7.5">7.5</a>. Time</h3></span> - - As described in <a href="#section-6">Section 6</a>, each article has an arrival timestamp. - Each newsgroup also has a creation timestamp. These timestamps are - used by the NEWNEWS and NEWGROUP commands to construct their - responses. - - Clients can ensure that they do not have gaps in lists of articles or - groups by using the DATE command in the following manner: - - First session: - Issue DATE command and record result. - Issue NEWNEWS command using a previously chosen timestamp. - - - -<span class="grey">Feather Standards Track [Page 65]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Subsequent sessions: - Issue DATE command and hold result in temporary storage. - Issue NEWNEWS command using timestamp saved from previous session. - Overwrite saved timestamp with that currently in temporary - storage. - - In order to allow for minor errors, clients MAY want to adjust the - timestamp back by two or three minutes before using it in NEWNEWS. - -<span class="h4"><h4><a class="selflink" name="section-7.5.1" href="#section-7.5.1">7.5.1</a>. Examples</h4></span> - - First session: - - [<a name="ref-C" id="ref-C">C</a>] DATE - [S] 111 20010203112233 - [<a href="#ref-C" title='"Demo User"'>C</a>] NEWNEWS local.chat 20001231 235959 GMT - [S] 230 list follows - [S] <article.1@local.service> - [S] <article.2@local.service> - [S] <article.3@local.service> - [S] . - - Second session (the client has subtracted 3 minutes from the - timestamp returned previously): - - [<a name="ref-C" id="ref-C">C</a>] DATE - [S] 111 20010204003344 - [<a href="#ref-C" title='"Demo User"'>C</a>] NEWNEWS local.chat 20010203 111933 GMT - [S] 230 list follows - [S] <article.3@local.service> - [S] <article.4@local.service> - [S] <article.5@local.service> - [S] . - - Note how <article.3@local.service> arrived in the 3 minute gap and so - is listed in both responses. - -<span class="h3"><h3><a class="selflink" name="section-7.6" href="#section-7.6">7.6</a>. The LIST Commands</h3></span> - - The LIST family of commands all return information that is multi-line - and that can, in general, be expected not to change during the - session. Often the information is related to newsgroups, in which - case the response has one line per newsgroup and a wildmat MAY be - provided to restrict the groups for which information is returned. - - The set of available keywords (including those provided by - extensions) is given in the capability list with capability label - LIST. - - - -<span class="grey">Feather Standards Track [Page 66]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-7.6.1" href="#section-7.6.1">7.6.1</a>. LIST</h4></span> - -<span class="h5"><h5><a class="selflink" name="section-7.6.1.1" href="#section-7.6.1.1">7.6.1.1</a>. Usage</h5></span> - - Indicating capability: LIST - - Syntax - LIST [keyword [wildmat|argument]] - - Responses - 215 Information follows (multi-line) - - Parameters - keyword Information requested [<a href="#ref-1">1</a>] - argument Specific to keyword - wildmat Groups of interest - - [<a name="ref-1" id="ref-1">1</a>] If no keyword is provided, it defaults to ACTIVE. - -<span class="h5"><h5><a class="selflink" name="section-7.6.1.2" href="#section-7.6.1.2">7.6.1.2</a>. Description</h5></span> - - The LIST command allows the server to provide blocks of information - to the client. This information may be global or may be related to - newsgroups; in the latter case, the information may be returned - either for all groups or only for those matching a wildmat. Each - block of information is represented by a different keyword. The - command returns the specific information identified by the keyword. - - If the information is available, it is returned as a multi-line data - block following the 215 response code. The format of the information - depends on the keyword. The information MAY be affected by the - additional argument, but the format MUST NOT be. - - If the information is based on newsgroups and the optional wildmat - argument is specified, the response is limited to only the groups (if - any) whose names match the wildmat and for which the information is - available. - - Note that an empty list is a possible valid response; for a - newsgroup-based keyword, it indicates that there are no groups - meeting the above criteria. - - If the keyword is not recognised, or if an argument is specified and - the keyword does not expect one, a 501 response code MUST BE - returned. If the keyword is recognised but the server does not - maintain the information, a 503 response code MUST BE returned. - - - - - -<span class="grey">Feather Standards Track [Page 67]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The LIST command MUST NOT change the visible state of the server in - any way; that is, the behaviour of subsequent commands MUST NOT be - affected by whether the LIST command was issued. For example, it - MUST NOT make groups available that otherwise would not have been. - -<span class="h5"><h5><a class="selflink" name="section-7.6.1.3" href="#section-7.6.1.3">7.6.1.3</a>. Examples</h5></span> - - Example of LIST with the ACTIVE keyword: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE - [S] 215 list of newsgroups follows - [S] misc.test 3002322 3000234 y - [S] comp.risks 442001 441099 m - [S] alt.rfc-writers.recovery 4 1 y - [S] tx.natives.recovery 89 56 y - [S] tx.natives.recovery.d 11 9 n - [S] . - - Example of LIST with no keyword: - - [<a name="ref-C" id="ref-C">C</a>] LIST - [S] 215 list of newsgroups follows - [S] misc.test 3002322 3000234 y - [S] comp.risks 442001 441099 m - [S] alt.rfc-writers.recovery 4 1 y - [S] tx.natives.recovery 89 56 y - [S] tx.natives.recovery.d 11 9 n - [S] . - - The output is identical to that of the previous example. - - Example of LIST on a newsgroup-based keyword with and without - wildmat: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE.TIMES - [S] 215 information follows - [S] misc.test 930445408 <creatme@isc.org> - [S] alt.rfc-writers.recovery 930562309 <m@example.com> - [S] tx.natives.recovery 930678923 <sob@academ.com> - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST ACTIVE.TIMES tx.* - [S] 215 information follows - [S] tx.natives.recovery 930678923 <sob@academ.com> - [S] . - - - - - - - -<span class="grey">Feather Standards Track [Page 68]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of LIST returning an error where the keyword is recognized - but the software does not maintain this information: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST XTRA.DATA - [S] 503 Data item not stored - - Example of LIST where the keyword is not recognised: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST DISTRIB.PATS - [S] 501 Syntax Error - -<span class="h4"><h4><a class="selflink" name="section-7.6.2" href="#section-7.6.2">7.6.2</a>. Standard LIST Keywords</h4></span> - - This specification defines the following LIST keywords: - - +--------------+---------------+------------------------------------+ - | Keyword | Definition | Status | - +--------------+---------------+------------------------------------+ - | ACTIVE | <a href="#section-7.6.3">Section 7.6.3</a> | Mandatory if the READER capability | - | | | is advertised | - | | | | - | ACTIVE.TIMES | <a href="#section-7.6.4">Section 7.6.4</a> | Optional | - | | | | - | DISTRIB.PATS | <a href="#section-7.6.5">Section 7.6.5</a> | Optional | - | | | | - | HEADERS | <a href="#section-8.6">Section 8.6</a> | Mandatory if the HDR capability is | - | | | advertised | - | | | | - | NEWSGROUPS | <a href="#section-7.6.6">Section 7.6.6</a> | Mandatory if the READER capability | - | | | is advertised | - | | | | - | OVERVIEW.FMT | <a href="#section-8.4">Section 8.4</a> | Mandatory if the OVER capability | - | | | is advertised | - +--------------+---------------+------------------------------------+ - - - - - -<span class="grey">Feather Standards Track [Page 69]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Where one of these LIST keywords is supported by a server, it MUST - have the meaning given in the relevant sub-section. - -<span class="h4"><h4><a class="selflink" name="section-7.6.3" href="#section-7.6.3">7.6.3</a>. LIST ACTIVE</h4></span> - - This keyword MUST be supported by servers advertising the READER - capability. - - LIST ACTIVE returns a list of valid newsgroups and associated - information. If no wildmat is specified, the server MUST include - every group that the client is permitted to select with the GROUP - command (<a href="#section-6.1.1">Section 6.1.1</a>). Each line of this list consists of four - fields separated from each other by one or more spaces: - - o The name of the newsgroup. - o The reported high water mark for the group. - o The reported low water mark for the group. - o The current status of the group on this server. - - The reported high and low water marks are as described in the GROUP - command (see <a href="#section-6.1.1">Section 6.1.1</a>), but note that they are in the opposite - order to the 211 response to that command. - - The status field is typically one of the following: - - "y" Posting is permitted. - - "n" Posting is not permitted. - - "m" Postings will be forwarded to the newsgroup moderator. - - The server SHOULD use these values when these meanings are required - and MUST NOT use them with any other meaning. Other values for the - status may exist; the definition of these other values and the - circumstances under which they are returned may be specified in an - extension or may be private to the server. A client SHOULD treat an - unrecognized status as giving no information. - - The status of a newsgroup only indicates how posts to that newsgroup - are normally processed and is not necessarily customised to the - specific client. For example, if the current client is forbidden - from posting, then this will apply equally to groups with status "y". - Conversely, a client with special privileges (not defined by this - specification) might be able to post to a group with status "n". - - - - - - - -<span class="grey">Feather Standards Track [Page 70]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - For example: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE - [S] 215 list of newsgroups follows - [S] misc.test 3002322 3000234 y - [S] comp.risks 442001 441099 m - [S] alt.rfc-writers.recovery 4 1 y - [S] tx.natives.recovery 89 56 y - [S] tx.natives.recovery.d 11 9 n - [S] . - - or, on an implementation that includes leading zeroes: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE - [S] 215 list of newsgroups follows - [S] misc.test 0003002322 0003000234 y - [S] comp.risks 0000442001 0000441099 m - [S] alt.rfc-writers.recovery 0000000004 0000000001 y - [S] tx.natives.recovery 0000000089 0000000056 y - [S] tx.natives.recovery.d 0000000011 0000000009 n - [S] . - - The information is newsgroup based, and a wildmat MAY be specified, - in which case the response is limited to only the groups (if any) - whose names match the wildmat. For example: - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE *.recovery - [S] 215 list of newsgroups follows - [S] alt.rfc-writers.recovery 4 1 y - [S] tx.natives.recovery 89 56 y - [S] . - -<span class="h4"><h4><a class="selflink" name="section-7.6.4" href="#section-7.6.4">7.6.4</a>. LIST ACTIVE.TIMES</h4></span> - - This keyword is optional. - - The active.times list is maintained by some NNTP servers to contain - information about who created a particular newsgroup and when. Each - line of this list consists of three fields separated from each other - by one or more spaces. The first field is the name of the newsgroup. - The second is the time when this group was created on this news - server, measured in seconds since the start of January 1, 1970. The - third is plain text intended to describe the entity that created the - newsgroup; it is often a mailbox as defined in <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>]. - For example: - - - - - - -<span class="grey">Feather Standards Track [Page 71]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE.TIMES - [S] 215 information follows - [S] misc.test 930445408 <creatme@isc.org> - [S] alt.rfc-writers.recovery 930562309 <m@example.com> - [S] tx.natives.recovery 930678923 <sob@academ.com> - [S] . - - The list MAY omit newsgroups for which the information is unavailable - and MAY include groups not available on the server; in particular, it - MAY omit all groups created before the date and time of the oldest - entry. The client MUST NOT assume that the list is complete or that - it matches the list returned by the LIST ACTIVE command - (<a href="#section-7.6.3">Section 7.6.3</a>). The NEWGROUPS command (<a href="#section-7.3">Section 7.3</a>) may provide a - better way to access this information, and the results of the two - commands SHOULD be consistent except that, if the latter is invoked - with a date and time earlier than the oldest entry in active.times - list, its result may include extra groups. - - The information is newsgroup based, and a wildmat MAY be specified, - in which case the response is limited to only the groups (if any) - whose names match the wildmat. - -<span class="h4"><h4><a class="selflink" name="section-7.6.5" href="#section-7.6.5">7.6.5</a>. LIST DISTRIB.PATS</h4></span> - - This keyword is optional. - - The distrib.pats list is maintained by some NNTP servers to assist - clients to choose a value for the content of the Distribution header - of a news article being posted. Each line of this list consists of - three fields separated from each other by a colon (":"). The first - field is a weight, the second field is a wildmat (which may be a - simple newsgroup name), and the third field is a value for the - Distribution header content. For example: - - [<a name="ref-C" id="ref-C">C</a>] LIST DISTRIB.PATS - [S] 215 information follows - [S] 10:local.*:local - [S] 5:*:world - [S] 20:local.here.*:thissite - [S] . - - The client MAY use this information to construct an appropriate - Distribution header given the name of a newsgroup. To do so, it - should determine the lines whose second field matches the newsgroup - name, select from among them the line with the highest weight (with 0 - being the lowest), and use the value of the third field to construct - the Distribution header. - - - - -<span class="grey">Feather Standards Track [Page 72]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - The information is not newsgroup based, and an argument MUST NOT be - specified. - -<span class="h4"><h4><a class="selflink" name="section-7.6.6" href="#section-7.6.6">7.6.6</a>. LIST NEWSGROUPS</h4></span> - - This keyword MUST be supported by servers advertising the READER - capability. - - The newsgroups list is maintained by NNTP servers to contain the name - of each newsgroup that is available on the server and a short - description about the purpose of the group. Each line of this list - consists of two fields separated from each other by one or more space - or TAB characters (the usual practice is a single TAB). The first - field is the name of the newsgroup, and the second is a short - description of the group. For example: - - [<a name="ref-C" id="ref-C">C</a>] LIST NEWSGROUPS - [S] 215 information follows - [S] misc.test General Usenet testing - [S] alt.rfc-writers.recovery RFC Writers Recovery - [S] tx.natives.recovery Texas Natives Recovery - [S] . - - The list MAY omit newsgroups for which the information is unavailable - and MAY include groups not available on the server. The client MUST - NOT assume that the list is complete or that it matches the list - returned by LIST ACTIVE. - - The description SHOULD be in UTF-8. However, servers often obtain - the information from external sources. These sources may have used - different encodings (ones that use octets in the range 128 to 255 in - some other manner) and, in that case, the server MAY pass it on - unchanged. Therefore, clients MUST be prepared to receive such - descriptions. - - The information is newsgroup based, and a wildmat MAY be specified, - in which case the response is limited to only the groups (if any) - whose names match the wildmat. - -<span class="h2"><h2><a class="selflink" name="section-8" href="#section-8">8</a>. Article Field Access Commands</h2></span> - - This section lists commands that may be used to access specific - article fields; that is, headers of articles and metadata about - articles. These commands typically fetch data from an "overview - database", which is a database of headers extracted from incoming - articles plus metadata determined as the article arrives. Only - certain fields are included in the database. - - - - -<span class="grey">Feather Standards Track [Page 73]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - This section is based on the Overview/NOV database [<a href="#ref-ROBE1995" title='"FAQ: Overview database / NOV General Information"'>ROBE1995</a>] - developed by Geoff Collyer. - -<span class="h3"><h3><a class="selflink" name="section-8.1" href="#section-8.1">8.1</a>. Article Metadata</h3></span> - - Article "metadata" is data about articles that does not occur within - the article itself. Each metadata item has a name that MUST begin - with a colon (and that MUST NOT contain a colon elsewhere within it). - As with header names, metadata item names are not case sensitive. - - When generating a metadata item, the server MUST compute it for - itself and MUST NOT trust any related value provided in the article. - (In particular, a Lines or Bytes header in the article MUST NOT be - assumed to specify the correct number of lines or bytes in the - article.) If the server has access to several non-identical copies - of an article, the value returned MUST be correct for any copy of - that article retrieved during the same session. - - This specification defines two metadata items: ":bytes" and ":lines". - Other metadata items may be defined by extensions. The names of - metadata items defined by registered extensions MUST NOT begin with - ":x-". To avoid the risk of a clash with a future registered - extension, the names of metadata items defined by private extensions - SHOULD begin with ":x-". - -<span class="h4"><h4><a class="selflink" name="section-8.1.1" href="#section-8.1.1">8.1.1</a>. The :bytes Metadata Item</h4></span> - - The :bytes metadata item for an article is a decimal integer. It - SHOULD equal the number of octets in the entire article: headers, - body, and separating empty line (counting a CRLF pair as two octets, - and excluding both the "." CRLF terminating the response and any "." - added for "dot-stuffing" purposes). - - Note to client implementers: some existing servers return a value - different from that above. The commonest reasons for this are as - follows: - - o Counting a CRLF pair as one octet. - - o Including the "." character used for dot-stuffing in the number. - - o Including the terminating "." CRLF in the number. - - o Using one copy of an article for counting the octets but then - returning another one that differs in some (permitted) manner. - - Implementations should be prepared for such variation and MUST NOT - rely on the value being accurate. - - - -<span class="grey">Feather Standards Track [Page 74]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-8.1.2" href="#section-8.1.2">8.1.2</a>. The :lines Metadata Item</h4></span> - - The :lines metadata item for an article is a decimal integer. It - MUST equal the number of lines in the article body (excluding the - empty line separating headers and body). Equivalently, it is two - less than the number of CRLF pairs that the BODY command would return - for that article (the extra two are those following the response code - and the termination octet). - -<span class="h3"><h3><a class="selflink" name="section-8.2" href="#section-8.2">8.2</a>. Database Consistency</h3></span> - - The information stored in the overview database may change over time. - If the database records the content or absence of a given field (that - is, a header or metadata item) for all articles, it is said to be - "consistent" for that field. If it records the content of a header - for some articles but not for others that nevertheless included that - header, or if it records a metadata item for some articles but not - for others to which that item applies, it is said to be - "inconsistent" for that field. - - The LIST OVERVIEW.FMT command SHOULD list all the fields for which - the database is consistent at that moment. It MAY omit such fields - (for example, if it is not known whether the database is consistent - or inconsistent). It MUST NOT include fields for which the database - is inconsistent or that are not stored in the database. Therefore, - if a header appears in the LIST OVERVIEW.FMT output but not in the - OVER output for a given article, that header does not appear in the - article (similarly for metadata items). - - These rules assume that the fields being stored in the database - remain constant for long periods of time, and therefore the database - will be consistent. When the set of fields to be stored is changed, - it will be inconsistent until either the database is rebuilt or the - only articles remaining are those received since the change. - Therefore, the output from LIST OVERVIEW.FMT needs to be altered - twice. Firstly, before any fields stop being stored they MUST be - removed from the output; then, when the database is once more known - to be consistent, the new fields SHOULD be added to the output. - - If the HDR command uses the overview database rather than taking - information directly from the articles, the same issues of - consistency and inconsistency apply, and the LIST HEADERS command - SHOULD take the same approach as the LIST OVERVIEW.FMT command in - resolving them. - - - - - - - -<span class="grey">Feather Standards Track [Page 75]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-8.3" href="#section-8.3">8.3</a>. OVER</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-8.3.1" href="#section-8.3.1">8.3.1</a>. Usage</h4></span> - - Indicating capability: OVER - - Syntax - OVER message-id - OVER range - OVER - - Responses - - First form (message-id specified) - 224 Overview information follows (multi-line) - 430 No article with that message-id - - Second form (range specified) - 224 Overview information follows (multi-line) - 412 No newsgroup selected - 423 No articles in that range - - Third form (current article number used) - 224 Overview information follows (multi-line) - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - range Number(s) of articles - message-id Message-id of article - -<span class="h4"><h4><a class="selflink" name="section-8.3.2" href="#section-8.3.2">8.3.2</a>. Description</h4></span> - - The OVER command returns the contents of all the fields in the - database for an article specified by message-id, or from a specified - article or range of articles in the currently selected newsgroup. - - The message-id argument indicates a specific article. The range - argument may be any of the following: - - o An article number. - - o An article number followed by a dash to indicate all following. - - o An article number followed by a dash followed by another article - number. - - If neither is specified, the current article number is used. - - - -<span class="grey">Feather Standards Track [Page 76]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Support for the first (message-id) form is optional. If it is - supported, the OVER capability line MUST include the argument - "MSGID". Otherwise, the capability line MUST NOT include this - argument, and the OVER command MUST return the generic response code - 503 when this form is used. - - If the information is available, it is returned as a multi-line data - block following the 224 response code and contains one line per - article, sorted in numerical order of article number. (Note that - unless the argument is a range including a dash, there will be - exactly one line in the data block.) Each line consists of a number - of fields separated by a TAB. A field may be empty (in which case - there will be two adjacent TABs), and a sequence of trailing TABs may - be omitted. - - The first 8 fields MUST be the following, in order: - - "0" or article number (see below) - Subject header content - From header content - Date header content - Message-ID header content - References header content - :bytes metadata item - :lines metadata item - - If the article is specified by message-id (the first form of the - command), the article number MUST be replaced with zero, except that - if there is a currently selected newsgroup and the article is present - in that group, the server MAY use the article's number in that group. - (See the ARTICLE command (<a href="#section-6.2.1">Section 6.2.1</a>) and STAT examples - (<a href="#section-6.2.4.3">Section 6.2.4.3</a>) for more details.) In the other two forms of the - command, the article number MUST be returned. - - Any subsequent fields are the contents of the other headers and - metadata held in the database. - - For the five mandatory headers, the content of each field MUST be - based on the content of the header (that is, with the header name and - following colon and space removed). If the article does not contain - that header, or if the content is empty, the field MUST be empty. - For the two mandatory metadata items, the content of the field MUST - be just the value, with no other text. - - For all subsequent fields that contain headers, the content MUST be - the entire header line other than the trailing CRLF. For all - subsequent fields that contain metadata, the field consists of the - metadata name, a single space, and then the value. - - - -<span class="grey">Feather Standards Track [Page 77]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - For all fields, the value is processed by first removing all CRLF - pairs (that is, undoing any folding and removing the terminating - CRLF) and then replacing each TAB with a single space. If there is - no such header in the article, no such metadata item, or no header or - item stored in the database for that article, the corresponding field - MUST be empty. - - Note that, after unfolding, the characters NUL, LF, and CR cannot - occur in the header of an article offered by a conformant server. - Nevertheless, servers SHOULD check for these characters and replace - each one by a single space (so that, for example, CR LF LF TAB will - become two spaces, since the CR and first LF will be removed by the - unfolding process). This will encourage robustness in the face of - non-conforming data; it is also possible that future versions of this - specification could permit these characters to appear in articles. - - The server SHOULD NOT produce output for articles that no longer - exist. - - If the argument is a message-id and no such article exists, a 430 - response MUST be returned. If the argument is a range or is omitted - and the currently selected newsgroup is invalid, a 412 response MUST - be returned. If the argument is a range and no articles in that - number range exist in the currently selected newsgroup, including the - case where the second number is less than the first one, a 423 - response MUST be returned. If the argument is omitted and the - current article number is invalid, a 420 response MUST be returned. - -<span class="h4"><h4><a class="selflink" name="section-8.3.3" href="#section-8.3.3">8.3.3</a>. Examples</h4></span> - - In the first four examples, TAB has been replaced by vertical bar and - some lines have been folded for readability. - - Example of a successful retrieval of overview information for an - article (explicitly not using an article number): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER - [S] 224 Overview information follows - [S] 3000234|I am just a test article|"Demo User" - <nobody@example.com>|6 Oct 1998 04:38:40 -0500| - <45223423@example.com>|<45454@example.net>|1234| - 17|Xref: news.example.com misc.test:3000363 - [S] . - - - - - - -<span class="grey">Feather Standards Track [Page 78]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of a successful retrieval of overview information for an - article by message-id: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] OVER MSGID - [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER <45223423@example.com> - [S] 224 Overview information follows - [S] 0|I am just a test article|"Demo User" - <nobody@example.com>|6 Oct 1998 04:38:40 -0500| - <45223423@example.com>|<45454@example.net>|1234| - 17|Xref: news.example.com misc.test:3000363 - [S] . - - Note that the article number has been replaced by "0". - - Example of the same commands on a system that does not implement - retrieval by message-id: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] OVER - [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER <45223423@example.com> - [S] 503 Overview by message-id unsupported - - - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 79]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-80" id="page-80" href="#page-80" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of a successful retrieval of overview information for a range - of articles: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 3000234-3000240 - [S] 224 Overview information follows - [S] 3000234|I am just a test article|"Demo User" - <nobody@example.com>|6 Oct 1998 04:38:40 -0500| - <45223423@example.com>|<45454@example.net>|1234| - 17|Xref: news.example.com misc.test:3000363 - [S] 3000235|Another test article|nobody@nowhere.to - (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425@to.to>|| - 4818|37||Distribution: fi - [S] 3000238|Re: I am just a test article|somebody@elsewhere.to| - 7 Oct 1998 11:38:40 +1200|<kfwer3v@elsewhere.to>| - <45223423@to.to>|9234|51 - [S] . - - Note the missing "References" and Xref headers in the second line, - the missing trailing fields in the first and last lines, and that - there are only results for those articles that still exist. - - Example of an unsuccessful retrieval of overview information on an - article by number: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 300256 - [S] 423 No such article in this group - - Example of an invalid range: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 3000444-3000222 - [S] 423 Empty range - - Example of an unsuccessful retrieval of overview information by - number because no newsgroup was selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER - [S] 412 No newsgroup selected - - - - - - - -<span class="grey">Feather Standards Track [Page 80]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-81" id="page-81" href="#page-81" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an attempt to retrieve information when the currently - selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] OVER - [S] 420 No current article selected - -<span class="h3"><h3><a class="selflink" name="section-8.4" href="#section-8.4">8.4</a>. LIST OVERVIEW.FMT</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-8.4.1" href="#section-8.4.1">8.4.1</a>. Usage</h4></span> - - Indicating capability: OVER - - Syntax - LIST OVERVIEW.FMT - - Responses - 215 Information follows (multi-line) - -<span class="h4"><h4><a class="selflink" name="section-8.4.2" href="#section-8.4.2">8.4.2</a>. Description</h4></span> - - See <a href="#section-7.6.1">Section 7.6.1</a> for general requirements of the LIST command. - - The LIST OVERVIEW.FMT command returns a description of the fields in - the database for which it is consistent (as described above). The - information is returned as a multi-line data block following the 215 - response code. The information contains one line per field in the - order in which they are returned by the OVER command; the first 7 - lines MUST (except for the case of letters) be exactly as follows: - - Subject: - From: - Date: - Message-ID: - References: - :bytes - :lines - - For compatibility with existing implementations, the last two lines - MAY instead be: - - Bytes: - Lines: - - even though they refer to metadata, not headers. - - - - - -<span class="grey">Feather Standards Track [Page 81]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-82" id="page-82" href="#page-82" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - All subsequent lines MUST consist of either a header name followed by - ":full", or the name of a piece of metadata. - - There are no leading or trailing spaces in the output. - - Note that the 7 fixed lines describe the 2nd to 8th fields of the - OVER output. The "full" suffix (which may use either uppercase, - lowercase, or a mix) is a reminder that the corresponding fields - include the header name. - - This command MAY generate different results if it is used more than - once in a session. - - If the OVER command is not implemented, the meaning of the output - from this command is not specified, but it must still meet the above - syntactic requirements. - -<span class="h4"><h4><a class="selflink" name="section-8.4.3" href="#section-8.4.3">8.4.3</a>. Examples</h4></span> - - Example of LIST OVERVIEW.FMT output corresponding to the example OVER - output above, in the preferred format: - - [<a name="ref-C" id="ref-C">C</a>] LIST OVERVIEW.FMT - [S] 215 Order of fields in overview database. - [S] Subject: - [S] From: - [S] Date: - [S] Message-ID: - [S] References: - [S] :bytes - [S] :lines - [S] Xref:full - [S] Distribution:full - [S] . - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 82]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-83" id="page-83" href="#page-83" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of LIST OVERVIEW.FMT output corresponding to the example OVER - output above, in the alternative format: - - [<a name="ref-C" id="ref-C">C</a>] LIST OVERVIEW.FMT - [S] 215 Order of fields in overview database. - [S] Subject: - [S] From: - [S] Date: - [S] Message-ID: - [S] References: - [S] Bytes: - [S] Lines: - [S] Xref:FULL - [S] Distribution:FULL - [S] . - -<span class="h3"><h3><a class="selflink" name="section-8.5" href="#section-8.5">8.5</a>. HDR</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-8.5.1" href="#section-8.5.1">8.5.1</a>. Usage</h4></span> - - Indicating capability: HDR - - Syntax - HDR field message-id - HDR field range - HDR field - - Responses - - First form (message-id specified) - 225 Headers follow (multi-line) - 430 No article with that message-id - - Second form (range specified) - 225 Headers follow (multi-line) - 412 No newsgroup selected - 423 No articles in that range - - Third form (current article number used) - 225 Headers follow (multi-line) - 412 No newsgroup selected - 420 Current article number is invalid - - Parameters - field Name of field - range Number(s) of articles - message-id Message-id of article - - - - -<span class="grey">Feather Standards Track [Page 83]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-84" id="page-84" href="#page-84" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-8.5.2" href="#section-8.5.2">8.5.2</a>. Description</h4></span> - - The HDR command provides access to specific fields from an article - specified by message-id, or from a specified article or range of - articles in the currently selected newsgroup. It MAY take the - information directly from the articles or from the overview database. - In the case of headers, an implementation MAY restrict the use of - this command to a specific list of headers or MAY allow it to be used - with any header; it may behave differently when it is used with a - message-id argument and when it is used with a range or no argument. - - The required field argument is the name of a header with the colon - omitted (e.g., "subject") or the name of a metadata item including - the leading colon (e.g., ":bytes"), and is case insensitive. - - The message-id argument indicates a specific article. The range - argument may be any of the following: - - o An article number. - - o An article number followed by a dash to indicate all following. - - o An article number followed by a dash followed by another article - number. - - If neither is specified, the current article number is used. - - If the information is available, it is returned as a multi-line data - block following the 225 response code and contains one line for each - article in the range that exists. (Note that unless the argument is - a range including a dash, there will be exactly one line in the data - block.) The line consists of the article number, a space, and then - the contents of the field. In the case of a header, the header name, - the colon, and the first space after the colon are all omitted. - - If the article is specified by message-id (the first form of the - command), the article number MUST be replaced with zero, except that - if there is a currently selected newsgroup and the article is present - in that group, the server MAY use the article's number in that group. - (See the ARTICLE command (<a href="#section-6.2.1">Section 6.2.1</a>) and STAT examples - (<a href="#section-6.2.4.3">Section 6.2.4.3</a>) for more details.) In the other two forms of the - command, the article number MUST be returned. - - Header contents are modified as follows: all CRLF pairs are removed, - and then each TAB is replaced with a single space. (Note that this - is the same transformation as is performed by the OVER command - (<a href="#section-8.3.2">Section 8.3.2</a>), and the same comment concerning NUL, CR, and LF - applies.) - - - -<span class="grey">Feather Standards Track [Page 84]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-85" id="page-85" href="#page-85" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Note the distinction between headers and metadata appearing to have - the same meaning. Headers are always taken unchanged from the - article; metadata are always calculated. For example, a request for - "Lines" returns the contents of the "Lines" header of the specified - articles, if any, no matter whether they accurately state the number - of lines, while a request for ":lines" returns the line count - metadata, which is always the actual number of lines irrespective of - what any header may state. - - If the requested header is not present in the article, or if it is - present but empty, a line for that article is included in the output, - but the header content portion of the line is empty (the space after - the article number MAY be retained or omitted). If the header occurs - in a given article more than once, only the content of the first - occurrence is returned by HDR. If any article number in the provided - range does not exist in the group, no line for that article number is - included in the output. - - If the second argument is a message-id and no such article exists, a - 430 response MUST be returned. If the second argument is a range or - is omitted and the currently selected newsgroup is invalid, a 412 - response MUST be returned. If the second argument is a range and no - articles in that number range exist in the currently selected - newsgroup, including the case where the second number is less than - the first one, a 423 response MUST be returned. If the second - argument is omitted and the current article number is invalid, a 420 - response MUST be returned. - - A server MAY only allow HDR commands for a limited set of fields; it - may behave differently in this respect for the first (message-id) - form from how it would for the other forms. If so, it MUST respond - with the generic 503 response to attempts to request other fields, - rather than return erroneous results, such as a successful empty - response. - - If HDR uses the overview database and it is inconsistent for the - requested field, the server MAY return what results it can, or it MAY - respond with the generic 503 response. In the latter case, the field - MUST NOT appear in the output from LIST HEADERS. - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 85]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-86" id="page-86" href="#page-86" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-8.5.3" href="#section-8.5.3">8.5.3</a>. Examples</h4></span> - - Example of a successful retrieval of subject lines from a range of - articles (3000235 has no Subject header, and 3000236 is missing): - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR Subject 3000234-3000238 - [S] 225 Headers follow - [S] 3000234 I am just a test article - [S] 3000235 - [S] 3000237 Re: I am just a test article - [S] 3000238 Ditto - [S] . - - Example of a successful retrieval of line counts from a range of - articles: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR :lines 3000234-3000238 - [S] 225 Headers follow - [S] 3000234 42 - [S] 3000235 5 - [S] 3000237 11 - [S] 3000238 2378 - [S] . - - Example of a successful retrieval of the subject line from an article - by message-id: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject <i.am.a.test.article@example.com> - [S] 225 Header information follows - [S] 0 I am just a test article - [S] . - - Example of a successful retrieval of the subject line from the - current article: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject - [S] 225 Header information follows - [S] 3000234 I am just a test article - [S] . - - - - -<span class="grey">Feather Standards Track [Page 86]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-87" id="page-87" href="#page-87" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an unsuccessful retrieval of a header from an article by - message-id: - - [<a name="ref-C" id="ref-C">C</a>] HDR subject <i.am.not.there@example.com> - [S] 430 No Such Article Found - - Example of an unsuccessful retrieval of headers from articles by - number because no newsgroup was selected first: - - [Assumes currently selected newsgroup is invalid.] - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject 300256- - [S] 412 No newsgroup selected - - Example of an unsuccessful retrieval of headers because the currently - selected newsgroup is empty: - - [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup - [S] 211 0 0 0 example.empty.newsgroup - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject 1- - [S] 423 No articles in that range - - Example of an unsuccessful retrieval of headers because the server - does not allow HDR commands for that header: - - [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test - [S] 211 1234 3000234 3002322 misc.test - [<a href="#ref-C" title='"Demo User"'>C</a>] HDR Content-Type 3000234-3000238 - [S] 503 HDR not permitted on Content-Type - -<span class="h3"><h3><a class="selflink" name="section-8.6" href="#section-8.6">8.6</a>. LIST HEADERS</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-8.6.1" href="#section-8.6.1">8.6.1</a>. Usage</h4></span> - - Indicating capability: HDR - - Syntax - LIST HEADERS [MSGID|RANGE] - - Responses - 215 Field list follows (multi-line) - - Parameters - MSGID Requests list for access by message-id - RANGE Requests list for access by range - - - - - - - -<span class="grey">Feather Standards Track [Page 87]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-88" id="page-88" href="#page-88" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-8.6.2" href="#section-8.6.2">8.6.2</a>. Description</h4></span> - - See <a href="#section-7.6.1">Section 7.6.1</a> for general requirements of the LIST command. - - The LIST HEADERS command returns a list of fields that may be - retrieved using the HDR command. - - The information is returned as a multi-line data block following the - 215 response code and contains one line for each field name - (excluding the trailing colon for headers and including the leading - colon for metadata items). If the implementation allows any header - to be retrieved, it MUST NOT include any header names in the list but - MUST include the special entry ":" (a single colon on its own). It - MUST still explicitly list any metadata items that are available. - The order of items in the list is not significant; the server need - not even consistently return the same order. The list MAY be empty - (though in this circumstance there is little point in providing the - HDR command). - - An implementation that also supports the OVER command SHOULD at least - permit all the headers and metadata items listed in the output from - the LIST OVERVIEW.FMT command. - - If the server treats the first form of the HDR command (message-id - specified) differently from the other two forms (range specified or - current article number used) in respect of which headers or metadata - items are available, then the following apply: - - o If the MSGID argument is specified, the results MUST be those - available for the first form of the HDR command. - - o If the RANGE argument is specified, the results MUST be those - available for the second and third forms of the HDR command. - - o If no argument is specified, the results MUST be those available - in all forms of the HDR command (that is, it MUST only list those - items listed in both the previous cases). - - If the server does not treat the various forms differently, then it - MUST ignore any argument and always produce the same results (though - not necessarily always in the same order). - - If the HDR command is not implemented, the meaning of the output from - this command is not specified, but it must still meet the above - syntactic requirements. - - - - - - -<span class="grey">Feather Standards Track [Page 88]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-89" id="page-89" href="#page-89" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h4"><h4><a class="selflink" name="section-8.6.3" href="#section-8.6.3">8.6.3</a>. Examples</h4></span> - - Example of an implementation providing access to only a few headers: - - [<a name="ref-C" id="ref-C">C</a>] LIST HEADERS - [S] 215 headers supported: - [S] Subject - [S] Message-ID - [S] Xref - [S] . - - Example of an implementation providing access to the same fields as - the first example in <a href="#section-8.4.3">Section 8.4.3</a>: - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] OVER - [S] HDR - [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST HEADERS - [S] 215 headers and metadata items supported: - [S] Date - [S] Distribution - [S] From - [S] Message-ID - [S] References - [S] Subject - [S] Xref - [S] :bytes - [S] :lines - [S] . - - Example of an implementation providing access to all headers: - - [<a name="ref-C" id="ref-C">C</a>] LIST HEADERS - [S] 215 metadata items supported: - [S] : - [S] :lines - [S] :bytes - [S] :x-article-number - [S] . - - - - - - - -<span class="grey">Feather Standards Track [Page 89]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-90" id="page-90" href="#page-90" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Example of an implementation distinguishing the first form of the HDR - command from the other two forms: - - [<a name="ref-C" id="ref-C">C</a>] LIST HEADERS RANGE - [S] 215 metadata items supported: - [S] : - [S] :lines - [S] :bytes - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST HEADERS MSGID - [S] 215 headers and metadata items supported: - [S] Date - [S] Distribution - [S] From - [S] Message-ID - [S] References - [S] Subject - [S] :lines - [S] :bytes - [S] :x-article-number - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] LIST HEADERS - [S] 215 headers and metadata items supported: - [S] Date - [S] Distribution - [S] From - [S] Message-ID - [S] References - [S] Subject - [S] :lines - [S] :bytes - [S] . - - Note that :x-article-number does not appear in the last set of - output. - -<span class="h2"><h2><a class="selflink" name="section-9" href="#section-9">9</a>. Augmented BNF Syntax for NNTP</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-9.1" href="#section-9.1">9.1</a>. Introduction</h3></span> - - Each of the following sections describes the syntax of a major - element of NNTP. This syntax extends and refines the descriptions - elsewhere in this specification and should be given precedence when - resolving apparent conflicts. Note that ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] strings are - case insensitive. Non-terminals used in several places are defined - in a separate section at the end. - - - - - -<span class="grey">Feather Standards Track [Page 90]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-91" id="page-91" href="#page-91" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Between them, the non-terminals <command-line>, <command-datastream>, - <command-continuation>, and <response> specify the text that flows - between client and server. A consistent naming scheme is used in - this document for the non-terminals relating to each command, and - SHOULD be used by the specification of registered extensions. - - For each command, the sequence is as follows: - - o The client sends an instance of <command-line>; the syntax for the - EXAMPLE command is <example-command>. - - o If the client is one that immediately streams data, it sends an - instance of <command-datastream>; the syntax for the EXAMPLE - command is <example-datastream>. - - o The server sends an instance of <response>. - - * The initial response line is independent of the command that - generated it; if the 000 response has arguments, the syntax of - the initial line is <response-000-content>. - - * If the response is multi-line, the initial line is followed by - a <multi-line-data-block>. The syntax for the contents of this - block after "dot-stuffing" has been removed is (for the 000 - response to the EXAMPLE command) <example-000-ml-content> and - is an instance of <multi-line-response-content>. - - o While the latest response is one that indicates more data is - required (in general, a 3xx response): - - * the client sends an instance of <command-continuation>; the - syntax for the EXAMPLE continuation following a 333 response is - <example-333-continuation>; - - * the server sends another instance of <response>, as above. - - (There are no commands in this specification that immediately stream - data, but this non-terminal is defined for the convenience of - extensions.) - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 91]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-92" id="page-92" href="#page-92" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-9.2" href="#section-9.2">9.2</a>. Commands</h3></span> - - This syntax defines the non-terminal <command-line>, which represents - what is sent from the client to the server (see <a href="#section-3.1">section 3.1</a> for - limits on lengths). - - command-line = command EOL - command = X-command - X-command = keyword *(WS token) - - command =/ article-command / - body-command / - capabilities-command / - date-command / - group-command / - hdr-command / - head-command / - help-command / - ihave-command / - last-command / - list-command / - listgroup-command / - mode-reader-command / - newgroups-command / - newnews-command / - next-command / - over-command / - post-command / - quit-command / - stat-command - - article-command = "ARTICLE" [WS article-ref] - body-command = "BODY" [WS article-ref] - capabilities-command = "CAPABILITIES" [WS keyword] - date-command = "DATE" - group-command = "GROUP" [WS newsgroup-name] - hdr-command = "HDR" WS header-meta-name [WS range-ref] - head-command = "HEAD" [WS article-ref] - help-command = "HELP" - ihave-command = "IHAVE" WS message-id - last-command = "LAST" - list-command = "LIST" [WS list-arguments] - listgroup-command = "LISTGROUP" [WS newsgroup-name [WS range]] - mode-reader-command = "MODE" WS "READER" - newgroups-command = "NEWGROUPS" WS date-time - newnews-command = "NEWNEWS" WS wildmat WS date-time - next-command = "NEXT" - over-command = "OVER" [WS range-ref] - - - -<span class="grey">Feather Standards Track [Page 92]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-93" id="page-93" href="#page-93" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - post-command = "POST" - quit-command = "QUIT" - stat-command = "STAT" [WS article-ref] - - article-ref = article-number / message-id - date = date2y / date4y - date4y = 4DIGIT 2DIGIT 2DIGIT - date2y = 2DIGIT 2DIGIT 2DIGIT - date-time = date WS time [WS "GMT"] - header-meta-name = header-name / metadata-name - list-arguments = keyword [WS token] - metadata-name = ":" 1*A-NOTCOLON - range = article-number ["-" [article-number]] - range-ref = range / message-id - time = 2DIGIT 2DIGIT 2DIGIT - -<span class="h3"><h3><a class="selflink" name="section-9.3" href="#section-9.3">9.3</a>. Command Continuation</h3></span> - - This syntax defines the further material sent by the client in the - case of multi-stage commands and those that stream data. - - command-datastream = UNDEFINED - ; not used, provided as a hook for extensions - command-continuation = ihave-335-continuation / - post-340-continuation - - ihave-335-continuation = encoded-article - post-340-continuation = encoded-article - - encoded-article = multi-line-data-block - ; after undoing the "dot-stuffing", this MUST match <article> - -<span class="h3"><h3><a class="selflink" name="section-9.4" href="#section-9.4">9.4</a>. Responses</h3></span> - -<span class="h4"><h4><a class="selflink" name="section-9.4.1" href="#section-9.4.1">9.4.1</a>. Generic Responses</h4></span> - - This syntax defines the non-terminal <response>, which represents the - generic form of responses; that is, what is sent from the server to - the client in response to a <command> or a <command-continuation>. - - response = simple-response / multi-line-response - simple-response = initial-response-line - multi-line-response = initial-response-line multi-line-data-block - - initial-response-line = - initial-response-content [SP trailing-comment] CRLF - initial-response-content = X-initial-response-content - X-initial-response-content = 3DIGIT *(SP response-argument) - - - -<span class="grey">Feather Standards Track [Page 93]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-94" id="page-94" href="#page-94" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - response-argument = 1*A-CHAR - trailing-comment = *U-CHAR - -<span class="h4"><h4><a class="selflink" name="section-9.4.2" href="#section-9.4.2">9.4.2</a>. Initial Response Line Contents</h4></span> - - This syntax defines the specific initial response lines for the - various commands in this specification (see <a href="#section-3.1">section 3.1</a> for limits on - lengths). Only those response codes with arguments are listed. - - initial-response-content =/ response-111-content / - response-211-content / - response-220-content / - response-221-content / - response-222-content / - response-223-content / - response-401-content - - response-111-content = "111" SP date4y time - response-211-content = "211" 3(SP article-number) SP newsgroup-name - response-220-content = "220" SP article-number SP message-id - response-221-content = "221" SP article-number SP message-id - response-222-content = "222" SP article-number SP message-id - response-223-content = "223" SP article-number SP message-id - response-401-content = "401" SP capability-label - -<span class="h4"><h4><a class="selflink" name="section-9.4.3" href="#section-9.4.3">9.4.3</a>. Multi-line Response Contents</h4></span> - - This syntax defines the content of the various multi-line responses; - more precisely, it defines the part of the response in the multi-line - data block after any "dot-stuffing" has been undone. The numeric - portion of each non-terminal name indicates the response code that is - followed by this data. - - multi-line-response-content = article-220-ml-content / - body-222-ml-content / - capabilities-101-ml-content / - hdr-225-ml-content / - head-221-ml-content / - help-100-ml-content / - list-215-ml-content / - listgroup-211-ml-content / - newgroups-231-ml-content / - newnews-230-ml-content / - over-224-ml-content - - article-220-ml-content = article - body-222-ml-content = body - capabilities-101-ml-content = version-line CRLF - - - -<span class="grey">Feather Standards Track [Page 94]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-95" id="page-95" href="#page-95" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - *(capability-line CRLF) - hdr-225-ml-content = *(article-number SP hdr-content CRLF) - head-221-ml-content = 1*header - help-100-ml-content = *(*U-CHAR CRLF) - list-215-ml-content = list-content - listgroup-211-ml-content = *(article-number CRLF) - newgroups-231-ml-content = active-groups-list - newnews-230-ml-content = *(message-id CRLF) - over-224-ml-content = *(article-number over-content CRLF) - - active-groups-list = *(newsgroup-name SPA article-number - SPA article-number SPA newsgroup-status CRLF) - hdr-content = *S-NONTAB - hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content] - list-content = body - newsgroup-status = %x79 / %x6E / %x6D / private-status - over-content = 1*6(TAB hdr-content) / - 7(TAB hdr-content) *(TAB hdr-n-content) - private-status = token ; except the values in newsgroup-status - -<span class="h3"><h3><a class="selflink" name="section-9.5" href="#section-9.5">9.5</a>. Capability Lines</h3></span> - - This syntax defines the generic form of a capability line in the - capabilities list (see <a href="#section-3.3.1">Section 3.3.1</a>). - - capability-line = capability-entry - capability-entry = X-capability-entry - X-capability-entry = capability-label *(WS capability-argument) - capability-label = keyword - capability-argument = token - - This syntax defines the specific capability entries for the - capabilities in this specification. - - capability-entry =/ - hdr-capability / - ihave-capability / - implementation-capability / - list-capability / - mode-reader-capability / - newnews-capability / - over-capability / - post-capability / - reader-capability - - hdr-capability = "HDR" - ihave-capability = "IHAVE" - implementation-capability = "IMPLEMENTATION" *(WS token) - - - -<span class="grey">Feather Standards Track [Page 95]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-96" id="page-96" href="#page-96" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - list-capability = "LIST" 1*(WS keyword) - mode-reader-capability = "MODE-READER" - newnews-capability = "NEWNEWS" - over-capability = "OVER" [WS "MSGID"] - post-capability = "POST" - reader-capability = "READER" - - version-line = "VERSION" 1*(WS version-number) - version-number = nzDIGIT *5DIGIT - -<span class="h3"><h3><a class="selflink" name="section-9.6" href="#section-9.6">9.6</a>. LIST Variants</h3></span> - - This section defines more specifically the keywords for the LIST - command and the syntax of the corresponding response contents. - - ; active - list-arguments =/ "ACTIVE" [WS wildmat] - list-content =/ list-active-content - list-active-content = active-groups-list - - - ; active.times - list-arguments =/ "ACTIVE.TIMES" [WS wildmat] - list-content =/ list-active-times-content - list-active-times-content = - *(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF) - newsgroup-creator = U-TEXT - - - ; distrib.pats - list-arguments =/ "DISTRIB.PATS" - list-content =/ list-distrib-pats-content - list-distrib-pats-content = - *(1*DIGIT ":" wildmat ":" distribution CRLF) - distribution = token - - - ; headers - list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")] - list-content =/ list-headers-content - list-headers-content = *(header-meta-name CRLF) / - *((metadata-name / ":") CRLF) - - - ; newsgroups - list-arguments =/ "NEWSGROUPS" [WS wildmat] - list-content =/ list-newsgroups-content - list-newsgroups-content = - - - -<span class="grey">Feather Standards Track [Page 96]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-97" id="page-97" href="#page-97" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - *(newsgroup-name WS newsgroup-description CRLF) - newsgroup-description = S-TEXT - - - ; overview.fmt - list-arguments =/ "OVERVIEW.FMT" - list-content =/ list-overview-fmt-content - list-overview-fmt-content = "Subject:" CRLF - "From:" CRLF - "Date:" CRLF - "Message-ID:" CRLF - "References:" CRLF - ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF - *((header-name ":full" / metadata-name) CRLF) - -<span class="h3"><h3><a class="selflink" name="section-9.7" href="#section-9.7">9.7</a>. Articles</h3></span> - - This syntax defines the non-terminal <article>, which represents the - format of an article as described in <a href="#section-3.6">Section 3.6</a>. - - article = 1*header CRLF body - header = header-name ":" [CRLF] SP header-content CRLF - header-content = *(S-CHAR / [CRLF] WS) - body = *(*B-CHAR CRLF) - -<span class="h3"><h3><a class="selflink" name="section-9.8" href="#section-9.8">9.8</a>. General Non-terminals</h3></span> - - These non-terminals are used at various places in the syntax and are - collected here for convenience. A few of these non-terminals are not - used in this specification but are provided for the consistency and - convenience of extension authors. - - multi-line-data-block = content-lines termination - content-lines = *([content-text] CRLF) - content-text = (".." / B-NONDOT) *B-CHAR - termination = "." CRLF - - article-number = 1*16DIGIT - header-name = 1*A-NOTCOLON - keyword = ALPHA 2*(ALPHA / DIGIT / "." / "-") - message-id = "<" 1*248A-NOTGT ">" - newsgroup-name = 1*wildmat-exact - token = 1*P-CHAR - - wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) - wildmat-pattern = 1*wildmat-item - wildmat-item = wildmat-exact / wildmat-wild - wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / - - - -<span class="grey">Feather Standards Track [Page 97]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-98" id="page-98" href="#page-98" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - UTF8-non-ascii ; exclude ! * , ? [ \ ] - wildmat-wild = "*" / "?" - - base64 = *(4base64-char) [base64-terminal] - base64-char = UPPER / LOWER / DIGIT / "+" / "/" - base64-terminal = 2base64-char "==" / 3base64-char "=" - - ; Assorted special character sets - ; A- means based on US-ASCII, excluding controls and SP - ; P- means based on UTF-8, excluding controls and SP - ; U- means based on UTF-8, excluding NUL CR and LF - ; B- means based on bytes, excluding NUL CR and LF - A-CHAR = %x21-7E - A-NOTCOLON = %x21-39 / %x3B-7E ; exclude ":" - A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" - P-CHAR = A-CHAR / UTF8-non-ascii - U-CHAR = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii - U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii - U-TEXT = P-CHAR *U-CHAR - B-CHAR = CTRL / TAB / SP / %x21-FF - B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "." - - ALPHA = UPPER / LOWER ; use only when case-insensitive - CR = %x0D - CRLF = CR LF - CTRL = %x01-08 / %x0B-0C / %x0E-1F - DIGIT = %x30-39 - nzDIGIT = %x31-39 - EOL = *(SP / TAB) CRLF - LF = %x0A - LOWER = %x61-7A - SP = %x20 - SPA = 1*SP - TAB = %x09 - UPPER = %x41-5A - UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 - UTF8-2 = %xC2-DF UTF8-tail - UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail / - %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail - UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail / - %xF4 %x80-8F 2UTF8-tail - UTF8-tail = %x80-BF - WS = 1*(SP / TAB) - - The following non-terminals require special consideration. They - represent situations where material SHOULD be restricted to UTF-8, - but implementations MUST be able to cope with other character - encodings. Therefore, there are two sets of definitions for them. - - - -<span class="grey">Feather Standards Track [Page 98]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-99" id="page-99" href="#page-99" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Implementations MUST accept any content that meets this syntax: - - S-CHAR = %x21-FF - S-NONTAB = CTRL / SP / S-CHAR - S-TEXT = (CTRL / S-CHAR) *B-CHAR - - and MAY pass such content on unaltered. - - When generating new content or re-encoding existing content, - implementations SHOULD conform to this syntax: - - S-CHAR = P-CHAR - S-NONTAB = U-NONTAB - S-TEXT = U-TEXT - -<span class="h3"><h3><a class="selflink" name="section-9.9" href="#section-9.9">9.9</a>. Extensions and Validation</h3></span> - - The specification of a registered extension MUST include formal - syntax that defines additional forms for the following non-terminals: - - command - for each new command other than a variant of the LIST command - - the syntax of each command MUST be compatible with the definition - of <X-command>; - - command-datastream - for each new command that immediately streams data; - - command-continuation - for each new command that sends further material after the initial - command line - the syntax of each continuation MUST be exactly - what is sent to the server, including any escape mechanisms such - as "dot-stuffing"; - - initial-response-content - for each new response code that has arguments - the syntax of each - response MUST be compatible with the definition of <X-initial- - response-content>; - - multi-line-response-content - for each new response code that has a multi-line response - the - syntax MUST show the response after the lines containing the - response code and the terminating octet have been removed and any - "dot-stuffing" undone; - - capability-entry - for each new capability label - the syntax of each entry MUST be - compatible with the definition of <X-capability-entry>; - - - -<span class="grey">Feather Standards Track [Page 99]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-100" id="page-100" href="#page-100" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - list-arguments - for each new variant of the LIST command - the syntax of each - entry MUST be compatible with the definition of <X-command>; - - list-content - for each new variant of the LIST command - the syntax MUST show - the response after the lines containing the 215 response code and - the terminating octet have been removed and any "dot-stuffing" - undone. - - The =/ notation of ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] and the naming conventions - described in <a href="#section-9.1">Section 9.1</a> SHOULD be used for this. - - When the syntax in this specification, or syntax based on it, is - validated, it should be noted that: - - o the non-terminals <command-line>, <command-datastream>, - <command-continuation>, <response>, and - <multi-line-response-content> describe basic concepts of the - protocol and are not referred to by any other rule; - - o the non-terminal <base64> is provided for the convenience of - extension authors and is not referred to by any rule in this - specification; - - o for the reasons given above, the non-terminals <S-CHAR>, - <S-NONTAB>, and <S-TEXT> each have two definitions; and - - o the non-terminal <UNDEFINED> is deliberately not defined. - -<span class="h2"><h2><a class="selflink" name="section-10" href="#section-10">10</a>. Internationalisation Considerations</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-10.1" href="#section-10.1">10.1</a>. Introduction and Historical Situation</h3></span> - - <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>] was written at a time when internationalisation was - not seen as a significant issue. As such, it was written on the - assumption that all communication would be in ASCII and use only a - 7-bit transport layer, although in practice just about all known - implementations are 8-bit clean. - - Since then, Usenet and NNTP have spread throughout the world. In the - absence of standards for handling the issues of language and - character sets, countries, newsgroup hierarchies, and individuals - have found a variety of solutions that work for them but that are not - necessarily appropriate elsewhere. For example, some have adopted a - default 8-bit character set appropriate to their needs (such as - ISO/IEC 8859-1 in Western Europe or KOI-8 in Russia), others have - used ASCII (either US-ASCII or national variants) in headers but - - - -<span class="grey">Feather Standards Track [Page 100]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-101" id="page-101" href="#page-101" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - local 16-bit character sets in article bodies, and still others have - gone for a combination of MIME [<a href="https://tools.ietf.org/html/rfc2045" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>RFC2045</a>] and UTF-8. With the - increased use of MIME in email, it is becoming more common to find - NNTP articles containing MIME headers that identify the character set - of the body, but this is far from universal. - - The resulting confusion does not help interoperability. - - One point that has been generally accepted is that articles can - contain octets with the top bit set, and NNTP is only expected to - operate on 8-bit clean transport paths. - -<span class="h3"><h3><a class="selflink" name="section-10.2" href="#section-10.2">10.2</a>. This Specification</h3></span> - - Part of the role of this present specification is to eliminate this - confusion and promote interoperability as far as possible. At the - same time, it is necessary to accept the existence of the present - situation and not break existing implementations and arrangements - gratuitously, even if they are less than optimal. Therefore, the - current practice described above has been taken into consideration in - producing this specification. - - This specification extends NNTP from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to UTF-8 - [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]. Except in the two areas discussed below, UTF-8 (which is - a superset of US-ASCII) is mandatory, and implementations MUST NOT - use any other encoding. - - Firstly, the use of MIME for article headers and bodies is strongly - recommended. However, given widely divergent existing practices, an - attempt to require a particular encoding and tagging standard would - be premature at this time. Accordingly, this specification allows - the use of arbitrary 8-bit data in articles subject to the following - requirements and recommendations. - - o The names of headers (e.g., "From" or "Subject") MUST be in - US-ASCII. - - o Header values SHOULD use US-ASCII or an encoding based on it, such - as <a href="https://tools.ietf.org/html/rfc2047">RFC 2047</a> [<a href="https://tools.ietf.org/html/rfc2047" title='"MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"'>RFC2047</a>], until such time as another approach has - been standardised. At present, 8-bit encodings (including UTF-8) - SHOULD NOT be used because they are likely to cause - interoperability problems. - - o The character set of article bodies SHOULD be indicated in the - article headers, and this SHOULD be done in accordance with MIME. - - o Where an article is obtained from an external source, an - implementation MAY pass it on and derive data from it (such as the - - - -<span class="grey">Feather Standards Track [Page 101]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-102" id="page-102" href="#page-102" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - response to the HDR command), even though the article or the data - does not meet the above requirements. Implementations MUST - transfer such articles and data correctly and unchanged; they MUST - NOT attempt to convert or re-encode the article or derived data. - (Nevertheless, a client or server MAY elect not to post or forward - the article if, after further examination of the article, it deems - it inappropriate to do so.) - - This requirement affects the ARTICLE (<a href="#section-6.2.1">Section 6.2.1</a>), BODY - (<a href="#section-6.2.3">Section 6.2.3</a>), HDR (<a href="#section-8.5">Section 8.5</a>), HEAD (<a href="#section-6.2.2">Section 6.2.2</a>), IHAVE - (<a href="#section-6.3.2">Section 6.3.2</a>), OVER (<a href="#section-8.3">Section 8.3</a>), and POST (<a href="#section-6.3.1">Section 6.3.1</a>) - commands. - - Secondly, the following requirements are placed on the newsgroups - list returned by the LIST NEWSGROUPS command (<a href="#section-7.6.6">Section 7.6.6</a>): - - o Although this specification allows UTF-8 for newsgroup names, they - SHOULD be restricted to US-ASCII until a successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> - [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] standardises another approach. 8-bit encodings SHOULD - NOT be used because they are likely to cause interoperability - problems. - - o The newsgroup description SHOULD be in US-ASCII or UTF-8 unless - and until a successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> standardises other encoding - arrangements. 8-bit encodings other than UTF-8 SHOULD NOT be used - because they are likely to cause interoperability problems. - - o Implementations that obtain this data from an external source MUST - handle it correctly even if it does not meet the above - requirements. Implementations (in particular, clients) MUST - handle such data correctly. - -<span class="h3"><h3><a class="selflink" name="section-10.3" href="#section-10.3">10.3</a>. Outstanding Issues</h3></span> - - While the primary use of NNTP is for transmitting articles that - conform to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> (Netnews articles), it is also used for other - formats (see <a href="#appendix-A">Appendix A</a>). It is therefore most appropriate that - internationalisation issues related to article formats be addressed - in the relevant specifications. For Netnews articles, this is any - successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>. For email messages, it is <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>]. - - Of course, any article transmitted via NNTP needs to conform to this - specification as well. - - Restricting newsgroup names to UTF-8 is not a complete solution. In - particular, when new newsgroup names are created or a user is asked - to enter a newsgroup name, some scheme of canonicalisation will need - to take place. This specification does not attempt to define that - - - -<span class="grey">Feather Standards Track [Page 102]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-103" id="page-103" href="#page-103" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - canonicalization; further work is needed in this area, in conjunction - with the article format specifications. Until such specifications - are published, implementations SHOULD match newsgroup names octet by - octet. It is anticipated that any approved scheme will be applied - "at the edges", and therefore octet-by-octet comparison will continue - to apply to most, if not all, uses of newsgroup names in NNTP. - - In the meantime, any implementation experimenting with UTF-8 - newsgroup names is strongly cautioned that a future specification may - require that those names be canonicalized when used with NNTP in a - way that is not compatible with their experiments. - - Since the primary use of NNTP is with Netnews, and since newsgroup - descriptions are normally distributed through specially formatted - articles, it is recommended that the internationalisation issues - related to them be addressed in any successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>. - -<span class="h2"><h2><a class="selflink" name="section-11" href="#section-11">11</a>. IANA Considerations</h2></span> - - This specification requires IANA to keep a registry of capability - labels. The initial contents of this registry are specified in - <a href="#section-3.3.4">Section 3.3.4</a>. As described in <a href="#section-3.3.3">Section 3.3.3</a>, labels beginning with - X are reserved for private use, while all other names are expected to - be associated with a specification in an RFC on the standards track - or defining an IESG-approved experimental protocol. - - Different entries in the registry MUST use different capability - labels. - - Different entries in the registry MUST NOT use the same command name. - For this purpose, variants distinguished by a second or subsequent - keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as - different commands. If there is a need for two extensions to use the - same command, a single harmonised specification MUST be registered. - -<span class="h2"><h2><a class="selflink" name="section-12" href="#section-12">12</a>. Security Considerations</h2></span> - - This section is meant to inform application developers, information - providers, and users of the security limitations in NNTP as described - by this document. The discussion does not include definitive - solutions to the problems revealed, though it does make some - suggestions for reducing security risks. - - - - - - - - - -<span class="grey">Feather Standards Track [Page 103]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-104" id="page-104" href="#page-104" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h3"><h3><a class="selflink" name="section-12.1" href="#section-12.1">12.1</a>. Personal and Proprietary Information</h3></span> - - NNTP, because it was created to distribute network news articles, - will forward whatever information is stored in those articles. - Specification of that information is outside this scope of this - document, but it is likely that some personal and/or proprietary - information is available in some of those articles. It is very - important that designers and implementers provide informative - warnings to users so that personal and/or proprietary information in - material that is added automatically to articles (e.g., in headers) - is not disclosed inadvertently. Additionally, effective and easily - understood mechanisms to manage the distribution of news articles - SHOULD be provided to NNTP Server administrators, so that they are - able to report with confidence the likely spread of any particular - set of news articles. - -<span class="h3"><h3><a class="selflink" name="section-12.2" href="#section-12.2">12.2</a>. Abuse of Server Log Information</h3></span> - - A server is in the position to save session data about a user's - requests that might identify their reading patterns or subjects of - interest. This information is clearly confidential in nature, and - its handling can be constrained by law in certain countries. People - using this protocol to provide data are responsible for ensuring that - such material is not distributed without the permission of any - individuals that are identifiable by the published results. - -<span class="h3"><h3><a class="selflink" name="section-12.3" href="#section-12.3">12.3</a>. Weak Authentication and Access Control</h3></span> - - There is no user-based or token-based authentication in the basic - NNTP specification. Access is normally controlled by server - configuration files. Those files specify access by using domain - names or IP addresses. However, this specification does permit the - creation of extensions to NNTP for such purposes; one such extension - is [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>]. While including such mechanisms is optional, doing - so is strongly encouraged. - - Other mechanisms are also available. For example, a proxy server - could be put in place that requires authentication before connecting - via the proxy to the NNTP server. - -<span class="h3"><h3><a class="selflink" name="section-12.4" href="#section-12.4">12.4</a>. DNS Spoofing</h3></span> - - Many existing NNTP implementations authorize incoming connections by - checking the IP address of that connection against the IP addresses - obtained via DNS lookups of lists of domain names given in local - configuration files. Servers that use this type of authentication - and clients that find a server by doing a DNS lookup of the server - name rely very heavily on the Domain Name Service, and are thus - - - -<span class="grey">Feather Standards Track [Page 104]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-105" id="page-105" href="#page-105" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - generally prone to security attacks based on the deliberate - misassociation of IP addresses and DNS names. Clients and servers - need to be cautious in assuming the continuing validity of an IP - number/DNS name association. - - In particular, NNTP clients and servers SHOULD rely on their name - resolver for confirmation of an IP number/DNS name association, - rather than cache the result of previous host name lookups. Many - platforms already can cache host name lookups locally when - appropriate, and they SHOULD be configured to do so. It is proper - for these lookups to be cached, however, only when the TTL (Time To - Live) information reported by the name server makes it likely that - the cached information will remain useful. - - If NNTP clients or servers cache the results of host name lookups in - order to achieve a performance improvement, they MUST observe the TTL - information reported by DNS. If NNTP clients or servers do not - observe this rule, they could be spoofed when a previously accessed - server's IP address changes. As network renumbering is expected to - become increasingly common, the possibility of this form of attack - will increase. Observing this requirement thus reduces this - potential security vulnerability. - - This requirement also improves the load-balancing behaviour of - clients for replicated servers using the same DNS name and reduces - the likelihood of a user's experiencing failure in accessing sites - that use that strategy. - -<span class="h3"><h3><a class="selflink" name="section-12.5" href="#section-12.5">12.5</a>. UTF-8 Issues</h3></span> - - UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] permits only certain sequences of octets and - designates others as either malformed or "illegal". The Unicode - standard identifies a number of security issues related to illegal - sequences and forbids their generation by conforming implementations. - - Implementations of this specification MUST NOT generate malformed or - illegal sequences and SHOULD detect them and take some appropriate - action. This could include the following: - - o Generating a 501 response code. - - o Replacing such sequences by the sequence %xEF.BF.BD, which encodes - the "replacement character" U+FFFD. - - o Closing the connection. - - o Replacing such sequences by a "guessed" valid sequence (based on - properties of the UTF-8 encoding). - - - -<span class="grey">Feather Standards Track [Page 105]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-106" id="page-106" href="#page-106" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - In the last case, the implementation MUST ensure that any replacement - cannot be used to bypass validity or security checks. For example, - the illegal sequence %xC0.A0 is an over-long encoding for space - (%x20). If it is replaced by the correct encoding in a command line, - this needs to happen before the command line is parsed into - individual arguments. If the replacement came after parsing, it - would be possible to generate an argument with an embedded space, - which is forbidden. Use of the "replacement character" does not have - this problem, since it is permitted wherever non-US-ASCII characters - are. Implementations SHOULD use one of the first two solutions where - the general structure of the NNTP stream remains intact and SHOULD - close the connection if it is no longer possible to parse it - sensibly. - -<span class="h3"><h3><a class="selflink" name="section-12.6" href="#section-12.6">12.6</a>. Caching of Capability Lists</h3></span> - - The CAPABILITIES command provides a capability list, which is - information about the current capabilities of the server. Whenever - there is a relevant change to the server state, the results of this - command are required to change accordingly. - - In most situations, the capabilities list in a given server state - will not change from session to session; for example, a given - extension will be installed permanently on a server. Some clients - may therefore wish to remember which extensions a server supports to - avoid the delay of an additional command and response, particularly - if they open multiple connections in the same session. - - However, information about extensions related to security and privacy - MUST NOT be cached, since this could allow a variety of attacks. - - For example, consider a server that permits the use of cleartext - passwords on links that are encrypted but not otherwise: - - [Initial connection set-up completed.] - [S] 200 NNTP Service Ready, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] NEWNEWS - [S] POST - [S] XENCRYPT - [S] LIST ACTIVE NEWSGROUPS - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] XENCRYPT - [Client and server negotiate encryption on the link] - [S] 283 Encrypted link established - - - -<span class="grey">Feather Standards Track [Page 106]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-107" id="page-107" href="#page-107" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES - [S] 101 Capability list: - [S] VERSION 2 - [S] READER - [S] NEWNEWS - [S] POST - [S] XSECRET - [S] LIST ACTIVE NEWSGROUPS - [S] . - [<a href="#ref-C" title='"Demo User"'>C</a>] XSECRET fred flintstone - [S] 290 Password for fred accepted - - If the client caches the last capabilities list, then on the next - session it will attempt to use XSECRET on an unencrypted link: - - [Initial connection set-up completed.] - [S] 200 NNTP Service Ready, posting permitted - [<a href="#ref-C" title='"Demo User"'>C</a>] XSECRET fred flintstone - [S] 483 Only permitted on secure links - - This exposes the password to any eavesdropper. While the primary - cause of this is passing a secret without first checking the security - of the link, caching of capability lists can increase the risk. - - Any security extension should include requirements to check the - security state of the link in a manner appropriate to that extension. - - Caching should normally only be considered for anonymous clients that - do not use any security or privacy extensions and for which the time - required for an additional command and response is a noticeable - issue. - -<span class="h2"><h2><a class="selflink" name="section-13" href="#section-13">13</a>. Acknowledgements</h2></span> - - This document is the result of much effort by the present and past - members of the NNTP Working Group, chaired by Russ Allbery and Ned - Freed. It could not have been produced without them. - - The author acknowledges the original authors of NNTP as documented in - <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>]: Brian Kantor and Phil Lapsey. - - The author gratefully acknowledges the following: - - o The work of the NNTP committee chaired by Eliot Lear. The - organization of this document was influenced by the last available - version from this working group. A special thanks to Eliot for - generously providing the original machine-readable sources for - that document. - - - -<span class="grey">Feather Standards Track [Page 107]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-108" id="page-108" href="#page-108" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - o The work of the DRUMS working group, specifically <a href="https://tools.ietf.org/html/rfc1869">RFC 1869</a> - [<a href="https://tools.ietf.org/html/rfc1869" title='"SMTP Service Extensions"'>RFC1869</a>], that drove the original thinking that led to the - CAPABILITIES command and the extensions mechanism detailed in this - document. - - o The authors of <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a> [<a href="https://tools.ietf.org/html/rfc2616" title='"Hypertext Transfer Protocol -- HTTP/1.1"'>RFC2616</a>] for providing specific and - relevant examples of security issues that should be considered for - HTTP. Since many of the same considerations exist for NNTP, those - examples that are relevant have been included here with some minor - rewrites. - - o The comments and additional information provided by the following - individuals in preparing one or more of the progenitors of this - document: - - Russ Allbery <rra@stanford.edu> - Wayne Davison <davison@armory.com> - Chris Lewis <clewis@bnr.ca> - Tom Limoncelli <tal@mars.superlink.net> - Eric Schnoebelen <eric@egsner.cirr.com> - Rich Salz <rsalz@osf.org> - - This work was motivated by the work of various news reader authors - and news server authors, including those listed below: - - Rick Adams - Original author of the NNTP extensions to the RN news reader and - last maintainer of Bnews. - - Stan Barber - Original author of the NNTP extensions to the news readers that - are part of Bnews. - - Geoff Collyer - Original author of the OVERVIEW database proposal and one of the - original authors of CNEWS. - - Dan Curry - Original author of the xvnews news reader. - - Wayne Davison - Author of the first threading extensions to the RN news reader - (commonly called TRN). - - Geoff Huston - Original author of ANU NEWS. - - - - - -<span class="grey">Feather Standards Track [Page 108]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-109" id="page-109" href="#page-109" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Phil Lapsey - Original author of the UNIX reference implementation for NNTP. - - Iain Lea - Original maintainer of the TIN news reader. - - Chris Lewis - First known implementer of the AUTHINFO GENERIC extension. - - Rich Salz - Original author of INN. - - Henry Spencer - One of the original authors of CNEWS. - - Kim Storm - Original author of the NN news reader. - - Other people who contributed to this document include: - - Matthias Andree - Greg Andruk - Daniel Barclay - Maurizio Codogno - Mark Crispin - Andrew Gierth - Juergen Helbing - Scott Hollenbeck - Urs Janssen - Charles Lindsey - Ade Lovett - David Magda - Ken Murchison - Francois Petillon - Peter Robinson - Rob Siemborski - Howard Swinehart - Ruud van Tol - Jeffrey Vinocur - Erik Warmelink - - The author thanks them all and apologises to anyone omitted. - - Finally, the present author gratefully acknowledges the vast amount - of work put into previous versions by the previous author: - - Stan Barber <sob@academ.com> - - - - -<span class="grey">Feather Standards Track [Page 109]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-110" id="page-110" href="#page-110" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="section-14" href="#section-14">14</a>. References</h2></span> - -<span class="h3"><h3><a class="selflink" name="section-14.1" href="#section-14.1">14.1</a>. Normative References</h3></span> - - [<a name="ref-ANSI1986" id="ref-ANSI1986">ANSI1986</a>] American National Standards Institute, "Coded Character - Set - 7-bit American Standard Code for Information - Interchange", ANSI X3.4, 1986. - - [<a name="ref-RFC977" id="ref-RFC977">RFC977</a>] Kantor, B. and P. Lapsley, "Network News Transfer - Protocol", <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, February 1986. - - [<a name="ref-RFC2045" id="ref-RFC2045">RFC2045</a>] Freed, N. and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) Part One: Format of Internet - Message Bodies", <a href="https://tools.ietf.org/html/rfc2045">RFC 2045</a>, November 1996. - - [<a name="ref-RFC2047" id="ref-RFC2047">RFC2047</a>] Moore, K., "MIME (Multipurpose Internet Mail - Extensions) Part Three: Message Header Extensions for - Non-ASCII Text", <a href="https://tools.ietf.org/html/rfc2047">RFC 2047</a>, November 1996. - - [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", <a href="https://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997. - - [<a name="ref-RFC3629" id="ref-RFC3629">RFC3629</a>] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, <a href="https://tools.ietf.org/html/rfc3629">RFC 3629</a>, November 2003. - - [<a name="ref-RFC4234" id="ref-RFC4234">RFC4234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", <a href="https://tools.ietf.org/html/rfc4234">RFC 4234</a>, October 2005. - - [<a name="ref-RFC4648" id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", <a href="https://tools.ietf.org/html/rfc4648">RFC 4648</a>, October 2006. - - [<a name="ref-TF.686-1" id="ref-TF.686-1">TF.686-1</a>] International Telecommunications Union - Radio, - "Glossary, ITU-R Recommendation TF.686-1", - ITU-R Recommendation TF.686-1, October 1997. - -<span class="h3"><h3><a class="selflink" name="section-14.2" href="#section-14.2">14.2</a>. Informative References</h3></span> - - [<a name="ref-NNTP-AUTH" id="ref-NNTP-AUTH">NNTP-AUTH</a>] Vinocur, J., Murchison, K., and C. Newman, "Network - News Transfer Protocol (NNTP) Extension for - Authentication", - <a href="https://tools.ietf.org/html/rfc4643">RFC 4643</a>, October 2006. - - [<a name="ref-NNTP-STREAM" id="ref-NNTP-STREAM">NNTP-STREAM</a>] Vinocur, J. and K. Murchison, "Network News Transfer - Protocol (NNTP) Extension for Streaming Feeds", - <a href="https://tools.ietf.org/html/rfc4644">RFC 4644</a>, October 2006. - - - - - - -<span class="grey">Feather Standards Track [Page 110]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-111" id="page-111" href="#page-111" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - [<a name="ref-NNTP-TLS" id="ref-NNTP-TLS">NNTP-TLS</a>] Murchison, K., Vinocur, J., and C. Newman, "Using - Transport Layer Security (TLS) with Network News - Transfer Protocol (NNTP)", <a href="https://tools.ietf.org/html/rfc4642">RFC 4642</a>, October 2006. - - [<a name="ref-RFC1036" id="ref-RFC1036">RFC1036</a>] Horton, M. and R. Adams, "Standard for interchange of - USENET messages", <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>, December 1987. - - [<a name="ref-RFC1305" id="ref-RFC1305">RFC1305</a>] Mills, D., "Network Time Protocol (Version 3) - Specification, Implementation and Analysis", <a href="https://tools.ietf.org/html/rfc1305">RFC 1305</a>, - March 1992. - - [<a name="ref-RFC1869" id="ref-RFC1869">RFC1869</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. - Crocker, "SMTP Service Extensions", STD 10, <a href="https://tools.ietf.org/html/rfc1869">RFC 1869</a>, - November 1995. - - [<a name="ref-RFC2616" id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>, June 1999. - - [<a name="ref-RFC2629" id="ref-RFC2629">RFC2629</a>] Rose, M., "Writing I-Ds and RFCs using XML", <a href="https://tools.ietf.org/html/rfc2629">RFC 2629</a>, - June 1999. - - [<a name="ref-RFC2822" id="ref-RFC2822">RFC2822</a>] Resnick, P., "Internet Message Format", <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a>, April - 2001. - - [<a name="ref-RFC2980" id="ref-RFC2980">RFC2980</a>] Barber, S., "Common NNTP Extensions", <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a>, October - 2000. - - [<a name="ref-ROBE1995" id="ref-ROBE1995">ROBE1995</a>] Robertson, R., "FAQ: Overview database / NOV General - Information", January 1995. - - There is no definitive copy of this document known to - the author. It was previously posted as the Usenet - article <news:nov-faq-1-930909720@agate.Berkeley.EDU> - - [<a name="ref-SALZ1992" id="ref-SALZ1992">SALZ1992</a>] Salz, R., "Manual Page for wildmat(3) from the INN 1.4 - distribution, Revision 1.10", April 1992. - - There is no definitive copy of this document known to - the author. - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 111]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-112" id="page-112" href="#page-112" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>. Interaction with Other Specifications</h2></span> - - NNTP is most often used for transferring articles that conform to - <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] (such articles are called "Netnews articles" - here). It is also sometimes used for transferring email messages - that conform to <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>] (such articles are called "email - articles" here). In this situation, articles must conform both to - this specification and to that other one; this appendix describes - some relevant issues. - -<span class="h1"><h1><a class="selflink" name="appendix-A.1" href="#appendix-A.1">A.1</a>. Header Folding</h1></span> - - NNTP allows a header line to be folded (by inserting a CRLF pair) - before any space or TAB character. - - Both email and Netnews articles are required to have at least one - octet other than space or TAB on each header line. Thus, folding can - only happen at one point in each sequence of consecutive spaces or - TABs. Netnews articles are further required to have the header name, - colon, and following space all on the first line; folding may only - happen beyond that space. Finally, some non-conforming software will - remove trailing spaces and TABs from a line. Therefore, it might be - inadvisable to fold a header after a space or TAB. - - For maximum safety, header lines SHOULD conform to the following - syntax rather than to that in <a href="#section-9.7">Section 9.7</a>. - - - header = header-name ":" SP [header-content] CRLF - header-content = [WS] token *( [CRLF] WS token ) - -<span class="h1"><h1><a class="selflink" name="appendix-A.2" href="#appendix-A.2">A.2</a>. Message-IDs</h1></span> - - Every article handled by an NNTP server MUST have a unique - message-id. For the purposes of this specification, a message-id is - an arbitrary opaque string that merely needs to meet certain - syntactic requirements and is just a way to refer to the article. - - Because there is a significant risk that old articles will be - reinjected into the global Usenet system, <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] requires - that message-ids are globally unique for all time. - - This specification states that message-ids are the same if and only - if they consist of the same sequence of octets. Other specifications - may define two different sequences as being equal because they are - putting an interpretation on particular characters. <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> - [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>] has a concept of "quoted" and "escaped" characters. It - therefore considers the three message-ids: - - - -<span class="grey">Feather Standards Track [Page 112]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-113" id="page-113" href="#page-113" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - <ab.cd@example.com> - <"ab.cd"@example.com> - <"ab.\cd"@example.com> - - as being identical. Therefore, an NNTP implementation handing email - articles must ensure that only one of these three appears in the - protocol and that the other two are converted to it as and when - necessary, such as when a client checks the results of a NEWNEWS - command against an internal database of message-ids. Note that - <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] never treats two different strings as being - identical. Its successor (as of the time of writing) restricts the - syntax of message-ids so that, whenever <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> would treat two - strings as equivalent, only one of them is valid (in the above - example, only the first string is valid). - - This specification does not describe how the message-id of an article - is determined; it may be deduced from the contents of the article or - derived from some external source. If the server is also conforming - to another specification that contains a definition of message-id - compatible with this one, the server SHOULD use those message-ids. A - common approach, and one that SHOULD be used for email and Netnews - articles, is to extract the message-id from the contents of a header - with name "Message-ID". This may not be as simple as copying the - entire header contents; it may be necessary to strip off comments and - undo quoting, or to reduce "equivalent" message-ids to a canonical - form. - - If an article is obtained through the IHAVE command, there will be a - message-id provided with the command. The server MAY either use it - or determine one from the article contents. However, whichever it - does, it SHOULD ensure that, if the IHAVE command is repeated with - the same argument and article, it will be recognized as a duplicate. - - If an article does not contain a message-id that the server can - identify, it MUST synthesize one. This could, for example, be a - simple sequence number or be based on the date and time when the - article arrived. When email or Netnews articles are handled, a - Message-ID header SHOULD be added to ensure global consistency and - uniqueness. - - Note that, because the message-id might not have been derived from - the Message-ID header in the article, the following example is - legitimate (though unusual): - - - - - - - - -<span class="grey">Feather Standards Track [Page 113]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-114" id="page-114" href="#page-114" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - [<a name="ref-C" id="ref-C">C</a>] HEAD <45223423@example.com> - [S] 221 0 <45223423@example.com> - [S] Path: pathost!demo!whitehouse!not-for-mail - [S] Message-ID: <1234@example.net> - [S] From: "Demo User" <nobody@example.net> - [S] Newsgroups: misc.test - [S] Subject: I am just a test article - [S] Date: 6 Oct 1998 04:38:40 -0500 - [S] Organization: An Example Net, Uncertain, Texas - [S] . - -<span class="h1"><h1><a class="selflink" name="appendix-A.3" href="#appendix-A.3">A.3</a>. Article Posting</h1></span> - - As far as NNTP is concerned, the POST and IHAVE commands provide the - same basic facilities in a slightly different way. However, they - have rather different intentions. - - The IHAVE command is intended for transmitting conforming articles - between a system of NNTP servers, with all articles perhaps also - conforming to another specification (e.g., all articles are Netnews - articles). It is expected that the client will already have done any - necessary validation (or that it has in turn obtained the article - from a third party that has done so); therefore, the contents SHOULD - be left unchanged. - - In contrast, the POST command is intended for use when an end-user is - injecting a newly created article into a such a system. The article - being transferred might not be a conforming email or Netnews article, - and the server is expected to validate it and, if necessary, to - convert it to the right form for onward distribution. This is often - done by a separate piece of software on the server installation; if - so, the NNTP server SHOULD pass the incoming article to that software - unaltered, making no attempt to filter characters, to fold or limit - lines, or to process the incoming text otherwise. - - The POST command can fail in various ways, and clients should be - prepared to re-send an article. When doing so, however, it is often - important to ensure (as far as possible) that the same message-id is - allocated to both attempts so that the server, or other servers, can - recognize the two articles as duplicates. In the case of email or - Netnews articles, therefore, the posted article SHOULD contain a - header with the name "Message-ID", and the contents of this header - SHOULD be identical on each attempt. The server SHOULD ensure that - two POSTed articles with the same contents for this header are - recognized as identical and that the same message-id is allocated, - whether or not those contents are suitable for use as the message-id. - - - - - -<span class="grey">Feather Standards Track [Page 114]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-115" id="page-115" href="#page-115" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="appendix-B" href="#appendix-B">Appendix B</a>. Summary of Commands</h2></span> - - This section contains a list of every command defined in this - document, ordered by command name and by indicating capability. - - Ordered by command name: - - +-------------------+-----------------------+---------------+ - | Command | Indicating capability | Definition | - +-------------------+-----------------------+---------------+ - | ARTICLE | READER | <a href="#section-6.2.1">Section 6.2.1</a> | - | BODY | READER | <a href="#section-6.2.3">Section 6.2.3</a> | - | CAPABILITIES | mandatory | <a href="#section-5.2">Section 5.2</a> | - | DATE | READER | <a href="#section-7.1">Section 7.1</a> | - | GROUP | READER | <a href="#section-6.1.1">Section 6.1.1</a> | - | HDR | HDR | <a href="#section-8.5">Section 8.5</a> | - | HEAD | mandatory | <a href="#section-6.2.2">Section 6.2.2</a> | - | HELP | mandatory | <a href="#section-7.2">Section 7.2</a> | - | IHAVE | IHAVE | <a href="#section-6.3.2">Section 6.3.2</a> | - | LAST | READER | <a href="#section-6.1.3">Section 6.1.3</a> | - | LIST | LIST | <a href="#section-7.6.1">Section 7.6.1</a> | - | LIST ACTIVE.TIMES | LIST | <a href="#section-7.6.4">Section 7.6.4</a> | - | LIST ACTIVE | LIST | <a href="#section-7.6.3">Section 7.6.3</a> | - | LIST DISTRIB.PATS | LIST | <a href="#section-7.6.5">Section 7.6.5</a> | - | LIST HEADERS | HDR | <a href="#section-8.6">Section 8.6</a> | - | LIST NEWSGROUPS | LIST | <a href="#section-7.6.6">Section 7.6.6</a> | - | LIST OVERVIEW.FMT | OVER | <a href="#section-8.4">Section 8.4</a> | - | LISTGROUP | READER | <a href="#section-6.1.2">Section 6.1.2</a> | - | MODE READER | MODE-READER | <a href="#section-5.3">Section 5.3</a> | - | NEWGROUPS | READER | <a href="#section-7.3">Section 7.3</a> | - | NEWNEWS | NEWNEWS | <a href="#section-7.4">Section 7.4</a> | - | NEXT | READER | <a href="#section-6.1.4">Section 6.1.4</a> | - | OVER | OVER | <a href="#section-8.3">Section 8.3</a> | - | POST | POST | <a href="#section-6.3.1">Section 6.3.1</a> | - | QUIT | mandatory | <a href="#section-5.4">Section 5.4</a> | - | STAT | mandatory | <a href="#section-6.2.4">Section 6.2.4</a> | - +-------------------+-----------------------+---------------+ - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 115]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-116" id="page-116" href="#page-116" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Ordered by indicating capability: - - +-------------------+-----------------------+---------------+ - | Command | Indicating capability | Definition | - +-------------------+-----------------------+---------------+ - | CAPABILITIES | mandatory | <a href="#section-5.2">Section 5.2</a> | - | HEAD | mandatory | <a href="#section-6.2.2">Section 6.2.2</a> | - | HELP | mandatory | <a href="#section-7.2">Section 7.2</a> | - | QUIT | mandatory | <a href="#section-5.4">Section 5.4</a> | - | STAT | mandatory | <a href="#section-6.2.4">Section 6.2.4</a> | - | HDR | HDR | <a href="#section-8.5">Section 8.5</a> | - | LIST HEADERS | HDR | <a href="#section-8.6">Section 8.6</a> | - | IHAVE | IHAVE | <a href="#section-6.3.2">Section 6.3.2</a> | - | LIST | LIST | <a href="#section-7.6.1">Section 7.6.1</a> | - | LIST ACTIVE | LIST | <a href="#section-7.6.3">Section 7.6.3</a> | - | LIST ACTIVE.TIMES | LIST | <a href="#section-7.6.4">Section 7.6.4</a> | - | LIST DISTRIB.PATS | LIST | <a href="#section-7.6.5">Section 7.6.5</a> | - | LIST NEWSGROUPS | LIST | <a href="#section-7.6.6">Section 7.6.6</a> | - | MODE READER | MODE-READER | <a href="#section-5.3">Section 5.3</a> | - | NEWNEWS | NEWNEWS | <a href="#section-7.4">Section 7.4</a> | - | OVER | OVER | <a href="#section-8.3">Section 8.3</a> | - | LIST OVERVIEW.FMT | OVER | <a href="#section-8.4">Section 8.4</a> | - | POST | POST | <a href="#section-6.3.1">Section 6.3.1</a> | - | ARTICLE | READER | <a href="#section-6.2.1">Section 6.2.1</a> | - | BODY | READER | <a href="#section-6.2.3">Section 6.2.3</a> | - | DATE | READER | <a href="#section-7.1">Section 7.1</a> | - | GROUP | READER | <a href="#section-6.1.1">Section 6.1.1</a> | - | LAST | READER | <a href="#section-6.1.3">Section 6.1.3</a> | - | LISTGROUP | READER | <a href="#section-6.1.2">Section 6.1.2</a> | - | NEWGROUPS | READER | <a href="#section-7.3">Section 7.3</a> | - | NEXT | READER | <a href="#section-6.1.4">Section 6.1.4</a> | - +-------------------+-----------------------+---------------+ - - - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 116]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-117" id="page-117" href="#page-117" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -<span class="h2"><h2><a class="selflink" name="appendix-C" href="#appendix-C">Appendix C</a>. Summary of Response Codes</h2></span> - - This section contains a list of every response code defined in this - document and indicates whether it is multi-line, which commands can - generate it, what arguments it has, and what its meaning is. - - Response code 100 (multi-line) - Generated by: HELP - Meaning: help text follows. - - Response code 101 (multi-line) - Generated by: CAPABILITIES - Meaning: capabilities list follows. - - Response code 111 - Generated by: DATE - 1 argument: yyyymmddhhmmss - Meaning: server date and time. - - Response code 200 - Generated by: initial connection, MODE READER - Meaning: service available, posting allowed. - - Response code 201 - Generated by: initial connection, MODE READER - Meaning: service available, posting prohibited. - - Response code 205 - Generated by: QUIT - Meaning: connection closing (the server immediately closes the - connection). - - Response code 211 - The 211 response code has two completely different forms, - depending on which command generated it: - - (not multi-line) - Generated by: GROUP - 4 arguments: number low high group - Meaning: group selected. - - (multi-line) - Generated by: LISTGROUP - 4 arguments: number low high group - Meaning: article numbers follow. - - - - - - -<span class="grey">Feather Standards Track [Page 117]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-118" id="page-118" href="#page-118" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Response code 215 (multi-line) - Generated by: LIST - Meaning: information follows. - - Response code 220 (multi-line) - Generated by: ARTICLE - 2 arguments: n message-id - Meaning: article follows. - - Response code 221 (multi-line) - Generated by: HEAD - 2 arguments: n message-id - Meaning: article headers follow. - - Response code 222 (multi-line) - Generated by: BODY - 2 arguments: n message-id - Meaning: article body follows. - - Response code 223 - Generated by: LAST, NEXT, STAT - 2 arguments: n message-id - Meaning: article exists and selected. - - Response code 224 (multi-line) - Generated by: OVER - Meaning: overview information follows. - - Response code 225 (multi-line) - Generated by: HDR - Meaning: headers follow. - - Response code 230 (multi-line) - Generated by: NEWNEWS - Meaning: list of new articles follows. - - Response code 231 (multi-line) - Generated by: NEWGROUPS - Meaning: list of new newsgroups follows. - - Response code 235 - Generated by: IHAVE (second stage) - Meaning: article transferred OK. - - Response code 240 - Generated by: POST (second stage) - Meaning: article received OK. - - - - -<span class="grey">Feather Standards Track [Page 118]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-119" id="page-119" href="#page-119" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Response code 335 - Generated by: IHAVE (first stage) - Meaning: send article to be transferred. - - Response code 340 - Generated by: POST (first stage) - Meaning: send article to be posted. - - Response code 400 - Generic response and generated by initial connection - Meaning: service not available or no longer available (the server - immediately closes the connection). - - Response code 401 - Generic response - 1 argument: capability-label - Meaning: the server is in the wrong mode; the indicated capability - should be used to change the mode. - - Response code 403 - Generic response - Meaning: internal fault or problem preventing action being taken. - - Response code 411 - Generated by: GROUP, LISTGROUP - Meaning: no such newsgroup. - - Response code 412 - Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP, - NEXT, OVER, STAT - Meaning: no newsgroup selected. - - Response code 420 - Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT - Meaning: current article number is invalid. - - Response code 421 - Generated by: NEXT - Meaning: no next article in this group. - - Response code 422 - Generated by: LAST - Meaning: no previous article in this group. - - Response code 423 - Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT - Meaning: no article with that number or in that range. - - - - -<span class="grey">Feather Standards Track [Page 119]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-120" id="page-120" href="#page-120" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Response code 430 - Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT - Meaning: no article with that message-id. - - Response code 435 - Generated by: IHAVE (first stage) - Meaning: article not wanted. - - Response code 436 - Generated by: IHAVE (either stage) - Meaning: transfer not possible (first stage) or failed (second - stage); try again later. - - Response code 437 - Generated by: IHAVE (second stage) - Meaning: transfer rejected; do not retry. - - Response code 440 - Generated by: POST (first stage) - Meaning: posting not permitted. - - Response code 441 - Generated by: POST (second stage) - Meaning: posting failed. - - Response code 480 - Generic response - Meaning: command unavailable until the client has authenticated - itself. - - Response code 483 - Generic response - Meaning: command unavailable until suitable privacy has been - arranged. - - Response code 500 - Generic response - Meaning: unknown command. - - Response code 501 - Generic response - Meaning: syntax error in command. - - - - - - - - - -<span class="grey">Feather Standards Track [Page 120]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-121" id="page-121" href="#page-121" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - Response code 502 - Generic response and generated by initial connection - - Meaning for the initial connection and the MODE READER command: - service permanently unavailable (the server immediately closes the - connection). - - Meaning for all other commands: command not permitted (and there - is no way for the client to change this). - - Response code 503 - Generic response - Meaning: feature not supported. - - Response code 504 - Generic response - Meaning: error in base64-encoding [<a href="https://tools.ietf.org/html/rfc4648" title='"The Base16, Base32, and Base64 Data Encodings"'>RFC4648</a>] of an argument. - -<span class="h2"><h2><a class="selflink" name="appendix-D" href="#appendix-D">Appendix D</a>. Changes from <a href="https://tools.ietf.org/html/rfc977">RFC 977</a></h2></span> - - In general every attempt has been made to ensure that the protocol - specification in this document is compatible with the version - specified in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>] and the various facilities adopted from - <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> [<a href="https://tools.ietf.org/html/rfc2980" title='"Common NNTP Extensions"'>RFC2980</a>]. However, there have been a number of changes, - some compatible and some not. - - This appendix lists these changes. It is not guaranteed to be - exhaustive or correct and MUST NOT be relied on. - - o A formal syntax specification (<a href="#section-9">Section 9</a>) has been added. - - o The default character set is changed from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to - UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] (note that US-ASCII is a subset of UTF-8). This - matter is discussed further in <a href="#section-10">Section 10</a>. - - o All articles are required to have a message-id, eliminating the - "<0>" placeholder used in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> in some responses. - - o The newsgroup name matching capabilities already documented in - <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> ("wildmats", <a href="#section-4">Section 4</a>) are clarified and extended. The - new facilities (e.g., the use of commas and exclamation marks) are - allowed wherever wildmats appear in the protocol. - - o Support for pipelining of commands (<a href="#section-3.5">Section 3.5</a>) is made - mandatory. - - - - - - -<span class="grey">Feather Standards Track [Page 121]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-122" id="page-122" href="#page-122" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - o The principles behind response codes (<a href="#section-3.2">Section 3.2</a>) have been - tidied up. In particular: - - * the x8x response code family, formerly used for private - extensions, is now reserved for authentication and privacy - extensions; - - * the x9x response code family, formerly intended for debugging - facilities, are now reserved for private extensions; - - * the 502 and 503 generic response codes (<a href="#section-3.2.1">Section 3.2.1</a>) have - been redefined; - - * new 401, 403, 480, 483, and 504 generic response codes have - been added. - - o The rules for article numbering (<a href="#section-6">Section 6</a>) have been clarified - (also see <a href="#section-6.1.1.2">Section 6.1.1.2</a>). - - o The SLAVE command (which was ill-defined) is removed from the - protocol. - - o Four-digit years are permitted in the NEWNEWS (<a href="#section-7.4">Section 7.4</a>) and - NEWGROUPS (<a href="#section-7.3">Section 7.3</a>) commands (two-digit years are still - permitted). The optional distribution parameter to these commands - has been removed. - - o The LIST command (<a href="#section-7.6.1">Section 7.6.1</a>) is greatly extended; the original - is available as LIST ACTIVE, while new variants include - ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS. A new "m" status flag - is added to the LIST ACTIVE response. - - o A new CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>) allows clients to - determine what facilities are supported by a server. - - o The DATE command (<a href="#section-7.1">Section 7.1</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> - effectively unchanged. - - o The LISTGROUP command (<a href="#section-6.1.2">Section 6.1.2</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a>. - An optional range argument has been added, and the 211 initial - response line now has the same format as the 211 response from the - GROUP command. - - o The MODE READER command (<a href="#section-5.3">Section 5.3</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> and - its meaning and effects clarified. - - o The XHDR command in <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> has been formalised as the new HDR - (<a href="#section-8.5">Section 8.5</a>) and LIST HEADERS (<a href="#section-8.6">Section 8.6</a>) commands. - - - -<span class="grey">Feather Standards Track [Page 122]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-123" id="page-123" href="#page-123" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - - o The XOVER command in <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> has been formalised as the new OVER - (<a href="#section-8.3">Section 8.3</a>) and LIST OVERVIEW.FMT (<a href="#section-8.4">Section 8.4</a>) commands. The - former can be applied to a message-id as well as to a range. - - o The concept of article metadata (<a href="#section-8.1">Section 8.1</a>) has been formalised, - allowing the Bytes and Lines pseudo-headers to be deprecated. - - Client authors should note in particular that lack of support for the - CAPABILITIES command is a good indication that the server does not - support this specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 123]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-124" id="page-124" href="#page-124" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -Author's Address - - Clive D.W. Feather - THUS plc - 322 Regents Park Road - London - N3 2QQ - United Kingdom - - Phone: +44 20 8495 6138 - Fax: +44 870 051 9937 - EMail: clive@demon.net - URI: <a href="http://www.davros.org/">http://www.davros.org/</a> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<span class="grey">Feather Standards Track [Page 124]</span> -</pre><!--NewPage--><pre class="newpage"><a name="page-125" id="page-125" href="#page-125" class="invisible"> </a> -<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> - - -Full Copyright Statement - -Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in <a href="https://tools.ietf.org/html/bcp78">BCP 78</a>, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - 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 <a href="https://tools.ietf.org/html/bcp78">BCP 78</a> and <a href="https://tools.ietf.org/html/bcp79">BCP 79</a>. - - 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 - <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. - - 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 ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Feather Standards Track [Page 125] - -</pre><br> -<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.109, available from -<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> -</small></small></span> - -</body></html>
\ No newline at end of file |