You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ch...@apache.org on 2001/05/17 18:50:33 UTC
cvs commit: jakarta-james/www/rfclist README draft-ietf-nntpext-base-13.txt rfc1036.txt rfc2980.txt rfc822.txt rfc977.txt
charlesb 01/05/17 09:50:31
Modified: . build.xml
src/xdocs todo.xml
Added: src/conf inetOrgPerson.at.conf inetOrgPerson.oc.conf
src/sql james-message-mysql.sql james-message-sqlserver.sql
testDirectory.ldif
src/xdocs configuration.xml
www code-standards.html commandsIMAP.html
configuration.html developer.html index.html
install.html license.html mailets.html
matchers.html proposalIMAP.html
statusIMAPserver.html todo.html
usingDatabaseRepository.html usingLDAP.html
usingTLS.html
www/images james-logo.jpg
www/rfclist README draft-ietf-nntpext-base-13.txt
rfc1036.txt rfc2980.txt rfc822.txt rfc977.txt
Removed: docs inetOrgPerson.at.conf inetOrgPerson.oc.conf
james-message-mysql.sql james-message-sqlserver.sql
testDirectory.ldif
Log:
Start moving docs to www dir
Revision Changes Path
1.65 +83 -4 jakarta-james/build.xml
Index: build.xml
===================================================================
RCS file: /home/cvs/jakarta-james/build.xml,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- build.xml 2001/05/16 13:25:53 1.64
+++ build.xml 2001/05/17 16:49:47 1.65
@@ -97,6 +97,10 @@
<property name="lib.dir" value="lib"/>
<property name="tools.dir" value="tools"/>
<property name="xdocs.dir" value="${src.dir}/xdocs"/>
+ <property name="docs.src" value="${xdocs.dir}"/>
+ <property name="docs.dir" value="docs"/>
+ <property name="www.dir" value="www"/>
+ <property name="javadocs.dir" value="${docs.dir}/api"/>
<property name="dist.name" value="${name}-${version}"/>
@@ -107,8 +111,7 @@
<property name="site.dir" value="../xml-site/sources/james"/>
<property name="site.docs" value="../xml-site/targets/james"/>
- <property name="docs.src" value="${xdocs.dir}"/>
- <property name="docs.dest" value="./docs"/>
+
<!--
===================================================================
@@ -421,6 +424,18 @@
</target>
<!-- =================================================================== -->
+ <!-- Documentation -->
+ <!-- =================================================================== -->
+ <!-- Docs are generated from xml sources in src/xdocs, javadocs from -->
+ <!-- source files in src/java. -->
+ <!-- Docs for most recent release are on the website and in www dir. -->
+ <!-- Docs for cvs state are generated on demand and can, optionally, -->
+ <!-- be placed in docs dir. -->
+ <!-- =================================================================== -->
+
+
+
+ <!-- =================================================================== -->
<!-- Generates the javadoc -->
<!-- =================================================================== -->
<target name="javadocs">
@@ -474,7 +489,7 @@
<!-- =================================================================== -->
<target name="xdocs" depends="prepare-error" if="AnakiaTask.present">
<taskdef name="anakia" classname="org.apache.velocity.anakia.AnakiaTask"/>
- <anakia basedir="${docs.src}" destdir="${docs.dest}/"
+ <anakia basedir="${docs.src}" destdir="${build.docs}/"
extension=".html" style="./site.vsl"
projectFile="stylesheets/project.xml"
excludes="**/stylesheets/** empty.xml"
@@ -483,7 +498,7 @@
templatePath="../jakarta-site2/xdocs/stylesheets">
</anakia>
- <copy todir="${docs.dest}/images" filtering="no">
+ <copy todir="${build.docs}/images" filtering="no">
<fileset dir="${docs.src}/images">
<include name="**/*.gif"/>
<include name="**/*.jpeg"/>
@@ -491,4 +506,68 @@
</fileset>
</copy>
</target>
+
+ <!--
+ ===================================================================
+ Create the Local site documentation
+ ===================================================================
+ -->
+ <target name="local-xdocs" depends="xdocs">
+
+ <delete>
+ <fileset dir="${docs.dir}">
+ <exclude name="framework/api/**"/>
+ </fileset>
+ </delete>
+ <mkdir dir="${docs.dir}"/>
+
+ <copy todir="${docs.dir}">
+ <fileset dir="${build.docs}" />
+ </copy>
+
+ </target>
+
+ <!--
+ ===================================================================
+ Create the Local API documentation
+ ===================================================================
+ -->
+ <target name="local-javadocs" depends="javadocs">
+
+ <delete dir="${javadocs.dir}"/>
+ <mkdir dir="${javadocs.dir}"/>
+
+ <copy todir="${javadocs.dir}">
+ <fileset dir="${build.javadocs}" />
+ </copy>
+
+ </target>
+
+ <target name="local-docs" depends="local-javadocs,local-xdocs"/>
+
+ <!--
+ ===================================================================
+ Update the www directory
+ ===================================================================
+ -->
+ <target name="site-docs" depends="local-xdocs">
+
+ <!-- delete all old documents but keep CVS directories -->
+ <!-- note that by doing an include the defaultexcludes (CVS dirs) will be kept -->
+ <delete>
+ <fileset dir="${www.dir}">
+ <include name="**"/>
+ </fileset>
+ </delete>
+
+ <mkdir dir="${www.dir}"/>
+ <copy todir="${www.dir}">
+ <fileset dir="${docs.dir}">
+ <exclude name="api/**"/>
+ </fileset>
+ </copy>
+
+ </target>
+
+
</project>
1.1 jakarta-james/src/conf/inetOrgPerson.at.conf
Index: inetOrgPerson.at.conf
===================================================================
attribute userSMIMECertificate bin
attribute userPKCS12 bin
1.1 jakarta-james/src/conf/inetOrgPerson.oc.conf
Index: inetOrgPerson.oc.conf
===================================================================
objectclass inetOrgPerson
requires
objectClass,
cn,
sn
allows
audio,
businessCategory,
carLicense,
departmentNumber,
description,
destinationIndicator,
displayName,
employeeNumber,
employeeType,
facsimileTelephoneNumber,
givenName,
homePhone,
homePostalAddress,
initials,
internationaliSDNNumber,
jpegPhoto,
l,
labelledURI,
mail,
manager,
mobile,
o,
ou,
pager,
photo,
physicalDeliveryOfficeName,
postalAddress,
postalCode,
postOfficeBox,
preferredDeliveryMethod,
registeredAddress,
seeAlso,
roomNumber,
secretary,
st,
street,
telephoneNumber,
teletexTerminalIdentifier,
telexNumber,
title,
uid,
userCertificate,
userPassword,
x121Address,
x500uniqueIdentifier,
preferredLanguage,
userSMIMECertificate,
userPKCS12,
memberOfGroup
1.1 jakarta-james/src/sql/james-message-mysql.sql
Index: james-message-mysql.sql
===================================================================
DROP DATABASE James;
CREATE DATABASE James;
use James;
CREATE TABLE Message (
message_name varchar (200) NOT NULL PRIMARY KEY,
repository_name varchar (200) NOT NULL ,
message_state varchar (30) NOT NULL ,
error_message varchar (200) NULL ,
sender varchar (100) NOT NULL ,
recipients text NOT NULL ,
remote_host varchar (100) NOT NULL ,
remote_addr varchar (20) NOT NULL ,
message_body longblob NOT NULL ,
last_updated datetime NOT NULL
);
1.1 jakarta-james/src/sql/james-message-sqlserver.sql
Index: james-message-sqlserver.sql
===================================================================
/****** Object: Table [dbo].[Message] Script Date: 10/3/2000 7:13:05 AM ******/
CREATE TABLE [dbo].[Message] (
[message_name] [varchar] (200) NOT NULL ,
[repository_name] [varchar] (200) NOT NULL ,
[message_state] [varchar] (30) NOT NULL ,
[error_message] [varchar] (200) NULL ,
[sender] [varchar] (100) NOT NULL ,
[recipients] [text] NOT NULL ,
[remote_host] [varchar] (100) NOT NULL ,
[remote_addr] [varchar] (20) NOT NULL ,
[message_body] [image] NOT NULL ,
[last_updated] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[Message] WITH NOCHECK ADD
CONSTRAINT [PK_Message] PRIMARY KEY NONCLUSTERED
(
[message_name]
) ON [PRIMARY]
GO
1.1 jakarta-james/src/sql/testDirectory.ldif
Index: testDirectory.ldif
===================================================================
dc=org
objectClass=dcobject
dc=org
dc=apache, dc=org
objectClass=dcobject
dc=apache
cn=mailserver.apache.org, dc=apache, dc=org
objectClass=applicationProcess
cn=mailserver.apache.org
description=TestServerUsingJAMES
dn: cn=King Arthur, dc=apache, dc=org
objectClass: inetOrgPerson
cn: King Arthur
sn: Pendragon
mail: Arthur@apache.org
mail: TheKing@apache.org
uid: Arthur@apache.org
userPassword: king
dn: cn=Morgan LeFay, dc=apache, dc=org
objectClass: inetOrgPerson
cn: Morgan LeFay
sn: LeFay
mail: Morgan.LeFay@apache.org
uid: Morgan.LeFay@apache.org
userPassword: sister
cn=Sir Lancelot, dc=apache, dc=org
objectClass=inetOrgPerson
cn=Sir Lancelot
sn=LoverOfGuinevere
mail=Sir.Lancelot@apache.org
uid=Lancelot.Loverboy@apache.org
userPassword=knight
1.2 +9 -5 jakarta-james/src/xdocs/todo.xml
Index: todo.xml
===================================================================
RCS file: /home/cvs/jakarta-james/src/xdocs/todo.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- todo.xml 2001/05/15 16:47:23 1.1
+++ todo.xml 2001/05/17 16:50:15 1.2
@@ -12,18 +12,20 @@
<section name="TODO">
<p>This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback.
-Last Updated 26 April 2001.</p>
+Last Updated 17 May 2001.</p>
</section>
<section name="High Priority">
<p>Port existing documentation to xdocs format</p>
<p>Bundle docs in dist</p>
-<p>Allow RemoteManager to change passwords of users (change attribute) </p>
+<p>Allow RemoteManager to change passwords of users (change attribute)<b> In proposals dir </b> </p>
<p>Revive RDBMS support for messages and users. Possibly move from town to straight jdbc, or jakarta-turbine.</p>
-<p>Enable multiple domains</p>
+
</section>
<section name="Medium Priority">
-<p>Let RemoteDelivery send all messages to a single remote server (acting like a gateway or a relay host) </p>
+<p>Enable multiple domains/ virtual hosting</p>
+<p>Rewrite SMTP and POP3 handlers to use streams not MimeMessage objects</p>
+<p>Let RemoteDelivery send all messages to a single remote server (acting like a gateway, relay or 'smart' host) </p>
<p>Improve exception management in RemoteDelivery mailet and general notices of why delivery failures occur.</p>
<p>Add support for regex inside most matchers and thereby consolidate a few of them.</p>
<p>Write more documentation. </p>
@@ -38,12 +40,14 @@
<p>Add support for deployable message processing apps using Camelot pattern</p>
<p>Give admins option to enforce one access at a time to a POP3 mailbox.</p>
<p>Simplify email aliasing</p>
+<p>Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.</p>
</section>
<section name="Low Priority">
-<p>Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.</p>
+
<p>Add support for DRAC login/relay allowing</p>
<p>Review threadpooling - is it dynamic?</p>
+<p>Enable read receipts to be handled properly</p>
</section>
</body>
1.1 jakarta-james/src/xdocs/configuration.xml
Index: configuration.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Configuration for James 1.2.1</title>
<author email="sergek@lokitech.com">Serge Knystautas</author>
</properties>
<body>
<section name="Configuration">
<p>
<blockquote>
<p>This document explains the JAMES.conf.xml file for James 1.2.1
<br>JAMES 1.2.1 is currently based on an older version of Avalon,
specifically the <code>avalon-james-1-1b1</code> branch in CVS.
</br>
</p>
</blockquote>
</p>
</section>
<section name="James Server Configuration">
<subsection name="James Configuration">
<p>
These tag elements control the JAMES spooling and identification
settings.
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> postmaster </td>
<td> Postmaster@localhost </td>
<td> Is the source of error replies and the email users will mail to for any problem. You
should change this to an address that can receive incoming messages.</td>
</tr>
<tr>
<td> helloName</td>
<td> attribute autodetect=TRUE and value of 'myMailServer' </td>
<td> The name by which James will identify itself in SMTP and POP3
greetings. If autodetect is TRUE James will attempt to detect
automatically the name, failing which it will use 'localhost'. If
autodetect is not TRUE, James will use the specified name or
'localhost' if none is specified. Look in jamesinfo.log for
lines like "[...] Local host is: [servername] and [...] Hello Name is: [machine name]"</td>
</tr>
<tr>
<td> servernames/servername</td>
<td> attribute autodetect=TRUE and last value of 'localhost'</td>
<td> A list of host names James will consider as local. Any user [user]@[servername]
will be considered to be local. If autodetect is TRUE James will attempt to detect
automatically the name and use any names specified. Look in jamesinfo.log for a line like "[...] Handling mail for:: [domain/host]"</td>
</tr>
<tr>
<td> spoolRepository </td>
<td> file://../var/mail/spool/ </td>
<td> This is the path where incoming messages are stored before beeing processed. </td>
</tr>
<tr>
<td> inboxRepository </td>
<td> file://../var/mail/localinbox/ </td>
<td> This is the root for local users inbox. Each user will have a personal folder
[inboxRepository]/[user] </td>
</tr>
<tr>
<td> spoolmanagerthreads </td>
<td> 1 </td>
<td> This is the number of thread that work polling mails from the spool and take care
of processing them. </td>
</tr>
</table>
</subsection>
<subsection name="SMTP Server Configuration">
<p>
These tag elements affect the SMTP listener (for incoming messages).
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 25 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> smtphandler </td>
<td> N.A. </td>
<td> Parent for all SMTPHandler configuations. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills
the connection is closed. </td>
</tr>
</table>
</subsection>
<subsection name="POP3 Server Configuration">
<p>
These tag elements affect the POP3 server (for message retrieval)
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 110 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> useTLS </td>
<td> false </td>
<td> Whether you wish to require/use TLS (SSL) on this port. </td>
</tr>
<tr>
<td> pop3handler </td>
<td> N.A. </td>
<td> Parent for all POP3Handler configuations. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills
the connection is closed. </td>
</tr>
</table>
</subsection>
<subsection name="Users Manager Configuration">
<p>
These tag elements affect the configuration of the list of local users.
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> repository </td>
<td> file://../var/users/ </td>
<td> The path where local mail account informations are stored. </td>
</tr>
</table>
</subsection>
<subsection name="Remote Manager Configuration">
<p>
These tag elements affect the remote manager, a telnet based utility
to manage the User Manager.
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 4555 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> useTLS </td>
<td> false </td>
<td> Whether you wish to require/use TLS (SSL) on this port. </td>
</tr>
<tr>
<td> administrator_accounts </td>
<td> N.A. </td>
<td> The parent of <account> </td>
</tr>
<tr>
<td> account </td>
<td> login="root" password="root" </td>
<td> A list of root account to administer JAMES. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills</td>
</tr>
</table>
</subsection>
<subsection name="Transport Configuration">
<p>
These tag elements affect SMTP remote delivery, specifically, DNS
lookup functionality.
</p>
<table border="1">
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> dnsServer/servers/server </td>
<td> N.A. </td>
<td> This is a list of DNS to resolve external address. </td>
</tr>
<tr>
<td> authoritative </td>
<td> false </td>
<td> Whether to require authoritative (non-cached) DNS records. Should always be false
unless you understand the implications. </td>
</tr>
<tr>
<td> repository </td>
<td> file://../var/mail/delayed/ </td>
<td> This is a temp repository path shared with the name of "TMP_REPOSITORY".
It is used by the RemoteDelivery Mailet to store mail for futher delivery.
(Note: this is not very elegant and will probally change soon) </td>
</tr>
<tr>
<td> mailets </td>
<td> rootpath="org.apache.james.transport.mailets." </td>
<td> This is the parent node for all mailet configurations. The rootpath specify
where mailet repository is. (Note: need to plug more than one repository) </td>
</tr>
</table>
</subsection>
</section>
<section name="The Mailet processor pipeline">
<p>
This is James sitemap. It defines how each incoming mail will be
processed. Incoming mails begins their process at the first mailet in the
pipe. Each step is described by a <servet> tag with some attributes:
<mailet match="[matchClass]=[matchParameters]"
class="[mailetClass]">.
The Match class split the mail into two: one with all recipients matching
conditions and the other with all recipient not matching. All information
in the mail except recipients cloned so bot matching and not matching are
identical (again except recipients). The matching mail will be passed to
the specified mailet for processing. After processing both mails, the
untoched not matching and the processed matching, goes to next step in
pipe. Some mailet will not return anything after process. The Null mailet
for example will simply destroy any incoming mail or the RemoteDelivery
since after delivery the mail needs no more processing.
</p>
<subsection name="Matches">
<p>
The Match interface defines how match class should work. Their work is
to split a Vector of recipients into two: the ones matching a specified
condition and all others. Condition may or may not be present. You can
make one simple boolean operation merging two matches into one or you
can write your own class implementing the Match interface.
Currently implemented match:
</p>
<table border="1">
<tr>
<th>class name</th>
<th>parameter</th>
<th>action</th>
<th>example</th>
</tr>
<tr>
<td> All </td>
<td> none </td>
<td> match all recipients. </td>
<td> match="All" </td>
</tr>
<tr>
<td> HostIs </td>
<td> comma separated list of hosts names </td>
<td> match all recipient belonging to one of the specified hosts </td>
<td> match="HostIs=myHost.mydom.org,yourHost" </td>
</tr>
<tr>
<td> RecipientIs </td>
<td> comma separated list of recipients </td>
<td> match all recipients defined in condition. </td>
<td> match="RecipientIs=root@localhost,admin@localhost" </td>
</tr>
<tr>
<td> UserIs </td>
<td> comma separated list of accounts </td>
<td> match all recipients defined in condition regardless of host. </td>
<td> match="UserIs=root,admin" </td>
</tr>
<tr>
<td> HostIsLocal </td>
<td> none </td>
<td> check recipients's hosts against the list of host names set in configuration for localhost
(see <servername>). </td>
<td> match="HostIsLocal" </td>
</tr>
<tr>
<td> RecipientIsLocal </td>
<td> none </td>
<td> match recipient which host is local (see HostIsLocal) and that are recognized by the
Users Manager to be local accounts. </td>
<td> match="RecipientIsLocal" </td>
</tr>
<tr>
<td> SenderIs </td>
<td> comma separated list of address. </td>
<td> match all recipients if sender is in the condition string, else match none. </td>
<td> match="SenderIs=badBay@badhost" </td>
</tr>
<tr>
<td> RelayLimit </td>
<td> Maximum number of hops. </td>
<td> match all recipients if the message has more than the specified number of SMTP hops.
Important to prevent race conditions in SMTP delivery.
</td>
<td> match="RelayLimit=30" </td>
</tr>
<tr>
<td> SubjectIs </td>
<td> comma separated list of address. </td>
<td> match all recipients if the subject is equal to the condition string, else match none. </td>
<td> match="SubjectIs=REMOVE" </td>
</tr>
<tr>
<td> SubjectStartsWith </td>
<td> comma separated list of address. </td>
<td> match all recipients if the subject starts with the condition string, else match none. </td>
<td> match="SubjectStartsWith: [ADV]" </td>
</tr>
</table>
<p>
Some examples:
<br>
- <mailet match="RecipientIsLocal"
class="LocalDelivery">
</br>
<br>
- <mailet match="UserIs=root & HostIsLocal"
class="Forward">
</br>
<br>
- <mailet match="SenderIs=badBoy@myhost,badGirl@yourhost"
class="Null">
</br>
</p>
</subsection>
<subsection name="Mailet">
<p>
Mailet are the ones performing a process on a message. They are
provided with a Mail object on which thy can perform any kind of task
and they reply with another Mail object containing the response. Wise
use of mailet allow to write any mail based application as http
application using mailet. Simple mailet provides basic mail
functionality like mail forwarding, mailing list, "I'm on vacation"
message, mail logging etc. As simply as these mailet, you can write
and deploy your own mailet to perform any kind of task.
<br>
Here you are some mailet samples with their configuration:
</br>
</p>
<b>Null</b>
<blockquote>
Destroy any incoming mail. No configuration needed.
<br>
<mailet match="SenderIs=badBoy@badhost" class="Null">
</mailet>
</br>
</blockquote>
<b>Identity</b>
<blockquote>
Leave any incoming mail untoched.Sort of debug mailet
(not really useful).
No configuration needed.
<br>
<mailet match="All" class="Identity">
</mailet></br>
</blockquote>
<b>Forward</b>
<blockquote>
Replace the recipient list with recipient specified in
configurations.<br>
<mailet match="RecipientIs=root@localhost"
class="Forward"></br>
<blockquote>
<br>
<forwardto> green@blue.org </forwardto>
</br>
<br>
<forwardto> red@yellow.com </forwardto>
</br>
</blockquote>
</mailet>
</blockquote>
<b>ToProcessor</b>
<blockquote>
Sends the incoming mail object to a new processor pipeline.
<code>root</code> and <code>error</code> are special processors that
should always be defined.
<br>
<mailet match="RecipientIsLocal" class="ToProcessor">
</br>
<blockquote>
<processor> localdelivery </processor>
</blockquote>
</mailet>
</blockquote>
<b>ServerTime</b>
<blockquote>
Replies to the sender with a short message with the current time.
No configuration needed.
<br>
<mailet match="RecipientIs=time@localhost" class="ServerTime">
</br>
</mailet>
</blockquote>
<b>ToRepository</b>
<blockquote>
Stores mails in the specified MailRepository. Useful for mail logging
etc. If the passThrough is false the mail will be destroyed, if true
it will be returned untouched to the pipe.
<br>
<mailet match="RecipientIs=root@localhost"
class="ToRepository">
</br>
<blockquote>
<br>
<repositoryPath> file://../var/mail/logAdmin
</repositoryPath>
</br>
<br>
<passThrough> true </passThrough> (default false)
</br>
</blockquote>
</mailet>
</blockquote>
<b>LocalDelivery</b>
<blockquote>
Store mail in the local inbox, one folder for each user.
<br>
<mailet match="RecipientIsLocal" class="LocalDelivery">
</br>
</mailet>
</blockquote>
<b>RemoteDelivery</b>
<blockquote>
Realy mails to remote hosts. "delayTime" is the time in mills the
mailet will wait
before retrying sending a mail which fail at first time.
"maxRetries" is the number of
retries before sending back to sender the mail.
<br>
<mailet match="!RecipientIsLocal" class="RemoteDelivery">
</br>
<blockquote>
<br>
<delayTime> 21600000 </delayTime>
</br>
<br>
<maxRetries> 5 </maxRetries>
</br>
</blockquote>
</mailet>
</blockquote>
</subsection>
</section>
</body>
</document>
1.1 jakarta-james/www/code-standards.html
Index: code-standards.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Serge Knystautas">
<meta name="email" value="sergek@lokitech.com">
<title>The Jakarta Site - Coding Standards</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Coding Standards"><strong>Coding Standards</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
Submissions to the James project must follow the coding conventions
outlined in this document. James developers
are asked to follow coding conventions already present in the code.
(For example, if the existing code has the bracket on
the same line as the if statement, then all subsequent code
should also follow that convention.) Anything not
explicitly mentioned in this document should adhere to the
official
<a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Sun
Java Coding Conventions</a>.
</p>
<p>
<strong>Developers who commit code that does not follow
the coding conventions outlined in this document will be
responsible for fixing their own code.</strong>
</p>
<p>
1. Spaces between parentheses are optional. The preference is to exclude
extra spaces. Both of these conventions are acceptable:
</p>
<p>
<source><![CDATA[
if (foo)
or
if ( foo )
]]></source>
</p>
<p>
2. Four spaces. <strong>NO</strong> tabs. Period. The James
mailing list receives cvs commit messages that are almost impossible
to read if tabs are used.
</p>
<p>
In Emacs-speak, this translates to the following command:
(setq-default tab-width 4 indent-tabs-mode nil)
</p>
<p>
3. Use Unix linefeeds for all .java source code files. Only platform-specific
files (e.g. .bat files for Windows) should contain non-Unix linefeeds.
</p>
<p>
4. Javadoc <strong>MUST</strong> exist on all methods. Contributing
a missing javadoc for any method, class, variable, etc., will be greatly
appreciated as this will help to improve the James project.
</p>
<p>
5. The Jakarta Apache/James License <strong>MUST</strong> be placed
at the top of every file.
</p>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/commandsIMAP.html
Index: commandsIMAP.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Charles Benett">
<meta name="email" value="charles@benett1.demon.co.uk">
<title>The Jakarta Site - Java Apache Mail Enterprise Server</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Summary"><strong>Summary</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<h3>An overview of IMAP command implementation proposed for JAMES</h3>
<blockquote>
Objective: A set of interfaces and basic implementations that provide:
<ul>
<li>The core functionality of RFC 2060, IMAP4Rev1.</li>
<li>Mailbox referrals - RFC 2193</li>
<li>Login referrals - RFC 2221</li>
<li>Access Control Lists - RFC 2086</li>
<li>Quotas - RFC 2087</li>
</ul>
</blockquote>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Background - IMAP commands"><strong>Background - IMAP commands</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>The IMAP protocol is based on single socket connections. Each connection may be in one of four official states: Non-Authenticated, Authenticated, Selected and Logout. In addition, there is an on-connection 'state'. Connections may be pre-authenticated, in which case they transition directly to the Authenticated state. Connections may also be rejected arbitrarily, in which case a response is sent and the connection tranistions directly to Logout. Once a connection enters the Logout state it must terminate and will terminate without further client input.
</p>
<p>A connection can only 'select' one mailbox at a time, although the STATE command allows a limited view of another mailbox. A client may open more than one connection to a single server at once. The client is responsible for any coordination needed. Multiple connections may 'select' a mailbox at the same time. The server must coordinate access.
</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Commands by State, Effect and Sensitivity"><strong>Commands by State, Effect and Sensitivity</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>Clients are, in general, permitted to issue multiple commands in a single connection. That is they can issue a second command without waiting for a response to the first command. Servers may process multiple commands in parallel or in series. However, some combinations of commands cannot be processed in parallel, because they are ambiguous. According to RFC2060,
<blockquote> "Clients MUST NOT send multiple commands without waiting if an ambiguity would result. If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client."
</blockquote>
The following table aims to highlight which commands can or cannot be processed in parallel with other commands. In particular, commands that are sensitive to mailbox context or message sequence number cannot be processed in parallel with commands that change those respective facts.
</p>
<p>
IMAP servers can support multiple namespaces with mailboxes that, for clients, would otherwise have identical names. For example, a user could have a private mailbox called James and also have access to a workgroup mailbox called James. These are disambiguated by namespace tokens, which a client can discover by the Namespace command.
</p>
<p>
Mailboxes can, in general, be accessed on behalf of more than one user. Access Control Lists are used to on a per mailbox basis. Any command which explicitly or implicitly refers to a mailbox, which is every command apart from Capability, Noop, Logout, can be impacted by a change of ACL. I intend to tie administer rights for an ACL to full read-write rights for the mailbox and not to allow someone with administer rights to remove their own administer rights. Implementations not following this practice may need to disambiguate ACL sensitive commands.
</p>
<p>The state of a mailbox (name, existence, ACL, number of messages, identity of messages and message attributes) may be changed outside a given connection which has the mailbox selected. Some of these changes should be notified to a client whether or noe a command is in progress and some should be notified only if a command is in progress.
</p>
<p>
The effects of a command noted here are ones which may affect processing multiple commands from one connection or impact multiply accessed mailboxes.
<ul>
<li>Connection state change: will or may change the state of the connection</li>
<li>Mailbox change: will or may change the state of an existing mailbox. Includes: changing name, altering size of mailbox (by adding or removing message) changing the access control list.</li>
<li>Mailbox context change: changes the selection of a mailbox, which is the context for Selected state commands.</li>
<li>Message Sequence Number Change: will or may change the message sequence number of a message known to this client, for example by provoking an untagged Expunge response. Note that any command in the selected state may send an untagged Expunge, except for Fetch, Store and Search. The entry 'likely' in this column indicates a proposed implementation.</li>
</ul>
The sensitivities noted are ones which may affect processing multiple commands from one connection or impact multiply accessed mailboxes.
<ul>
<li>Current Mailbox: this command implicity refers to the currently selected mailbox so is sensitive to either a mailbox change or a mailbox context change</li>
<li>Message sequence number change: this command may take an MSN as an argument</li>
</ul>
All commands which explicitly or implicitly refers to a mailbox, which is every command apart from Capability, Noop, Logout, can be impacted by a Mailbox change.
</p>
<table>
<tr>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#039acc" colspan="3" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
State in which valid
</font>
</td>
<td bgcolor="#039acc" colspan="4" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Effects
</font>
</td>
<td bgcolor="#039acc" colspan="2" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Sensitivity
</font>
</td>
</tr>
<tr>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Command
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Non-Authenticated
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Authenticated
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Selected
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Connection State change
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Mailbox change
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Mailbox context change
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Message Sequence Number Change
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Mailbox context
</font>
</td>
<td bgcolor="#039acc" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Message Sequence Number
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="10" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
<i>Core IMAP4 rev1 commands (RFC2060)</i>
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Capability
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Noop
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
likely
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Logout
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Authenticate
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Login
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Select
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Examine
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Create
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Delete
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Rename
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Subscribe
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Unsubscribe
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
List
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
LSUB
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Status
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Append
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Check
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
likely
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Close
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Must not
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Expunge
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Must
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Search
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Must not
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Fetch
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Must not
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Store
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Must not
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Copy
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
likely
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
UID
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
likely
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="10" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
<i>Access Control List commands (RFC2086)</i>
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
SetACL
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
DeleteACL
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
GetACL
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
ListRights
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
MyRights
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="10" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
<i>Namespace commands (RFC2342)</i>
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Namespace
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="10" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
<i>Mailbox Referral commands (RFC2193)</i>
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
RList
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
RLSUB
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="10" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
<i>Quota commands (RFC2087)</i>
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
SetQuota
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
GetQuota
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
GetQuotaRoot
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Yes
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
<td bgcolor="#a0ddf0" colspan="1" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
</font>
</td>
</tr>
</table>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/configuration.html
Index: configuration.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h3 align = left><a href="index.html">Up to Index</a></h3>
<h1 align="center">Configuration</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Configuration</h3>
<blockquote>
<p>This document explains the JAMES.conf.xml file.
<br>JAMES is currently based on an older version of Avalon,
specifically the <code>avalon-james-1-1b1</code> branch in CVS.</p>
</blockquote>
<h3>James Server Configuration</h3>
<blockquote>
<h4>James Configuration</h4>
<blockquote>
<p>These tag elements control the JAMES spooling and identification settings.</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> postmaster </td>
<td> Postmaster@localhost </td>
<td> Is the source of error replies and the email users will mail to for any problem. You
should change this to an address that can receive incoming messages.</td>
</tr>
<tr>
<td> helloName</td>
<td> attribute autodetect=TRUE and value of 'myMailServer' </td>
<td> The name by which James will identify itself in SMTP and POP3
greetings. If autodetect is TRUE James will attempt to detect
automatically the name, failing which it will use 'localhost'. If
autodetect is not TRUE, James will use the specified name or
'localhost' if none is specified. Look in jamesinfo.log for
lines like "[...] Local host is: [servername] and [...] Hello Name is: [machine name]"</td>
</tr>
<tr>
<td> servernames/servername</td>
<td> attribute autodetect=TRUE and last value of 'localhost'</td>
<td> A list of host names James will consider as local. Any user [user]@[servername]
will be considered to be local. If autodetect is TRUE James will attempt to detect
automatically the name and use any names specified. Look in jamesinfo.log for a line like "[...] Handling mail for:: [domain/host]"</td>
</tr>
<tr>
<td> spoolRepository </td>
<td> file://../var/mail/spool/ </td>
<td> This is the path where incoming messages are stored before beeing processed. </td>
</tr>
<tr>
<td> inboxRepository </td>
<td> file://../var/mail/localinbox/ </td>
<td> This is the root for local users inbox. Each user will have a personal folder
[inboxRepository]/[user] </td>
</tr>
<tr>
<td> spoolmanagerthreads </td>
<td> 1 </td>
<td> This is the number of thread that work polling mails from the spool and take care
of processing them. </td>
</tr>
</table>
<h4>SMTP Server</h4>
<blockquote>
<p>These tag elements affect the SMTP listener (for incoming messages).</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 25 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> smtphandler </td>
<td> N.A. </td>
<td> Parent for all SMTPHandler configuations. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills
the connection is closed. </td>
</tr>
</table>
<h4>POP3 Server</h4>
<blockquote>
<p>These tag elements affect the POP3 server (for message retrieval)</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 110 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> useTLS </td>
<td> false </td>
<td> Whether you wish to require/use TLS (SSL) on this port. </td>
</tr>
<tr>
<td> pop3handler </td>
<td> N.A. </td>
<td> Parent for all POP3Handler configuations. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills
the connection is closed. </td>
</tr>
</table>
<h4>Users Manager</h4>
<blockquote>
<p>These tag elements affect the configuration of the list of local users.</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> repository </td>
<td> file://../var/users/ </td>
<td> The path where local mail account informations are stored. </td>
</tr>
</table>
<h4>Remote Manager</h4>
<blockquote>
<p>These tag elements affect the remote manager, a telnet based utility to manage the User Manager.</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> port </td>
<td> 4555 </td>
<td> The port we are listening to. </td>
</tr>
<tr>
<td> bind </td>
<td> N.A. </td>
<td> Specific IP addresses that you wish to bind this service to. </td>
</tr>
<tr>
<td> useTLS </td>
<td> false </td>
<td> Whether you wish to require/use TLS (SSL) on this port. </td>
</tr>
<tr>
<td> administrator_accounts </td>
<td> N.A. </td>
<td> The parent of <account> </td>
</tr>
<tr>
<td> account </td>
<td> login="root" password="root" </td>
<td> A list of root account to administer JAMES. </td>
</tr>
<tr>
<td> connectiontimeout </td>
<td> 120000 </td>
<td> If nothing is received from an open connection for more than {timeout] mills
</tr>
</table>
<h4>Transport</h4>
<blockquote>
<p>These tag elements affect SMTP remote delivery, specifically, DNS lookup functionality.</p>
</blockquote>
<table border=1>
<tr>
<th><name></th>
<th>default value</th>
<th>meaning</th>
</tr>
<tr>
<td> dnsServer/servers/server </td>
<td> N.A. </td>
<td> This is a list of DNS to resolve external address. </td>
</tr>
<tr>
<td> authoritative </td>
<td> false </td>
<td> Whether to require authoritative (non-cached) DNS records. Should always be false
unless you understand the implications. </td>
</tr>
<tr>
<td> repository </td>
<td> file://../var/mail/delayed/ </td>
<td> This is a temp repository path shared with the name of "TMP_REPOSITORY".
It is used by the RemoteDelivery Mailet to store mail for futher delivery.
(Note: this is not very elegant and will probally change soon) </td>
</tr>
<tr>
<td> mailets </td>
<td> rootpath="org.apache.james.transport.mailets." </td>
<td> This is the parent node for all mailet configurations. The rootpath specify
where mailet repository is. (Note: need to plug more than one repository) </td>
</tr>
</table>
<blockquote>
</blockquote>
</blockquote>
<br><br>
<h3>The Mailet processor pipeline</h3>
<blockquote>
<p>This is James sitemap. It defines how each incoming mail will be processed.
Incoming mails begins their process at the first mailet in the pipe.
Each step is described by a <servet> tag with some attributes:
<mailet match="[matchClass]=[matchParameters]" class="[mailetClass]">.
The Match class split the mail into two: one with all recipients matching conditions and
the other with all recipient not matching. All information in the mail except recipients
cloned so bot matching and not matching are identical (again except recipients).
The matching mail will be passed to the specified mailet for processing. After processing
both mails, the untoched not matching and the processed matching, goes to next step in pipe.
Some mailet will not return anything after process. The Null mailet for example will simply
destroy any incoming mail or the RemoteDelivery since after delivery the mail needs no
more processing.</p><br>
<h4>Matches</h4>
<blockquote>
<p>The Match interface defines how match class should work. Their work is to split a Vector
of recipients into two: the ones matching a specified condition and all others. Condition
may or may not be present. You can make one simple boolean operation merging two matches into one
or you can write your own class implementing the Match interface.
Currently implemented match: </p>
</blockquote>
<table border=1>
<tr>
<th>class name</th>
<th>parameter</th>
<th>action</th>
<th>example</th>
</tr>
<tr>
<td> All </td>
<td> none </td>
<td> match all recipients. </td>
<td> match="All" </td>
</tr>
<tr>
<td> HostIs </td>
<td> comma separated list of hosts names </td>
<td> match all recipient belonging to one of the specified hosts </td>
<td> match="HostIs=myHost.mydom.org,yourHost" </td>
</tr>
<tr>
<td> RecipientIs </td>
<td> comma separated list of recipients </td>
<td> match all recipients defined in condition. </td>
<td> match="RecipientIs=root@localhost,admin@localhost" </td>
</tr>
<tr>
<td> UserIs </td>
<td> comma separated list of accounts </td>
<td> match all recipients defined in condition regardless of host. </td>
<td> match="UserIs=root,admin" </td>
</tr>
<tr>
<td> HostIsLocal </td>
<td> none </td>
<td> check recipients's hosts against the list of host names set in configuration for localhost
(see <servername>). </td>
<td> match="HostIsLocal" </td>
</tr>
<tr>
<td> RecipientIsLocal </td>
<td> none </td>
<td> match recipient which host is local (see HostIsLocal) and that are recognized by the
Users Manager to be local accounts. </td>
<td> match="RecipientIsLocal" </td>
</tr>
<tr>
<td> SenderIs </td>
<td> comma separated list of address. </td>
<td> match all recipients if sender is in the condition string, else match none. </td>
<td> match="SenderIs=badBay@badhost" </td>
</tr>
<tr>
<td> RelayLimit </td>
<td> Maximum number of hops. </td>
<td> match all recipients if the message has more than the specified number of SMTP hops.
Important to prevent race conditions in SMTP delivery.
</td>
<td> match="RelayLimit=30" </td>
</tr>
<tr>
<td> SubjectIs </td>
<td> comma separated list of address. </td>
<td> match all recipients if the subject is equal to the condition string, else match none. </td>
<td> match="SubjectIs=REMOVE" </td>
</tr>
<tr>
<td> SubjectStartsWith </td>
<td> comma separated list of address. </td>
<td> match all recipients if the subject starts with the condition string, else match none. </td>
<td> match="SubjectStartsWith: [ADV]" </td>
</tr>
</table>
<blockquote>
Some examples:<br>
- <mailet match="RecipientIsLocal" class="LocalDelivery"><br><br>
- <mailet match="UserIs=root & HostIsLocal" class="Forward"><br><br>
- <mailet match="SenderIs=badBoy@myhost,badGirl@yourhost" class="Null"><br><br>
</blockquote>
<h4>Mailet</h4>
<blockquote>
<p>
Mailet are the ones performing a process on a message. They are provided with a Mail object
on which thy can perform any kind of task and they reply with another Mail object
containing the response. Wise use of mailet allow to write any mail based application
as http application using mailet. Simple mailet provides basic mail functionality like
mail forwarding, mailing list, "I'm on vacation" message, mail logging etc. As simply as
these mailet, you can write and deploy your own mailet to perform any kind of task. <br>
Here you are some mailet samples with their configuration:
</p>
<b>Null</b>
<blockquote>
Destroy any incoming mail. No configuration needed.<br><br>
<mailet match="SenderIs=badBoy@badhost" class="Null"><br>
</mailet><br><br>
</blockquote>
<b>Identity</b>
<blockquote>
Leave any incoming mail untoched.Sort of debug mailet (not really useful).
No configuration needed.<br><br>
<mailet match="All" class="Identity"><br>
</mailet><br><br>
</blockquote>
<b>Forward</b>
<blockquote>
Replace the recipient list with recipient specified in configurations.<br><br>
<mailet match="RecipientIs=root@localhost" class="Forward"><br>
<blockquote>
<forwardto> green@blue.org </forwardto><br>
<forwardto> red@yellow.com </forwardto><br>
</blockquote>
</mailet><br><br>
</blockquote>
<b>ToProcessor</b>
<blockquote>
Sends the incoming mail object to a new processor pipeline. <code>root</code> and
<code>error</code> are special processors that should always be defined.<br><br>
<mailet match="RecipientIsLocal" class="ToProcessor"><br>
<blockquote>
<processor> localdelivery </processor><br>
</blockquote>
</mailet><br><br>
</blockquote>
<b>ServerTime</b>
<blockquote>
Replies to the sender with a short message with the current time.
No configuration needed.<br><br>
<mailet match="RecipientIs=time@localhost" class="ServerTime"><br>
</mailet><br><br>
</blockquote>
<b>ToRepository</b>
<blockquote>
Stores mails in the specified MailRepository. Useful for mail logging etc.
If the passThrough is false the mail will be destroyed, if true it will be
returned untouched to the pipe.<br><br>
<mailet match="RecipientIs=root@localhost" class="ToRepository"><br>
<blockquote>
<repositoryPath> file://../var/mail/logAdmin </repositoryPath><br>
<passThrough> true </passThrough> (default false)<br>
</blockquote>
</mailet><br><br>
</blockquote>
<b>LocalDelivery</b>
<blockquote>
Store mail in the local inbox, one folder for each user.<br><br>
<mailet match="RecipientIsLocal" class="LocalDelivery"><br>
</mailet><br><br>
</blockquote>
<b>RemoteDelivery</b>
<blockquote>
Realy mails to remote hosts. "delayTime" is the time in mills the mailet will wait
before retrying sending a mail which fail at first time. "maxRetries" is the number of
retries before sending back to sender the mail.<br><br>
<mailet match="!RecipientIsLocal" class="RemoteDelivery"><br>
<blockquote>
<delayTime> 21600000 </delayTime> <br>
<maxRetries> 5 </maxRetries> <br>
</blockquote>
</mailet><br><br>
<br>
.<br>
</blockquote>
</blockquote>
</blockquote>
<h3 align = left><a href="index.html">Up to Index</a></h3>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/developer.html
Index: developer.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h3 align = left><a href="index.html">Up to Index</a></h3>
<h1 align="center">Technical Notes for Developers</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Architecture</h3>
<blockquote>
<p>JAMES is a multi-protocol message processing and storage engine. JAMES currently consists of:
<ul>
<li> two mail prototcol servers (SMTP and POP3),</li>
<li> a remote administration server,</li>
<li> a mail processing engine that supports the Mailet API</li>
<li> file-system message storage and a message storage interface to RDBMS's</li>
<li> file-system user record storage and an experimental interface to LDAP directories</li>
<li> beta support for TLS (SSL) for POP3 and remote administration</li>
</ul>
</p>
<p> JAMES is built on top of Avalon, the Java Apache Server Framework. Versions 1.1 and 1.2 of James use a slightly older version of Avalon, specifically the <code>avalon-james-1-1b1</code> branch. We intend to migrate to the new Avalon in the near future.</p>
</blockquote>
<h3>Process flow</h3>
<blockquote>
<p>Fill Me!!.</p>
</blockquote>
<p> Good luck :)
<br> The Apache JAMES team</p>
<h3 align = left><a href="index.html">Up to Index</a></h3>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/index.html
Index: index.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Serge Knystautas">
<meta name="email" value="sergek@lokitech.com">
<title>The Jakarta Site - Java Apache Mail Enterprise Server</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="What is it?"><strong>What is it?</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a 100% pure
Java server, designed to be a complete and portable enterprise mail engine solution
based on currently available open protocols (SMTP, POP3, IMAP, HTTP). It requires
Java 2 (minimum requirement is the JRE 1.2).
</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Design Objectives"><strong>Design Objectives</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>These are some of the currently implemented features:</p>
<p><i><b>Complete portability</b></i> Apache James is be a 100% pure Java application
based on the Java 2 platform and the JavaMail 1.2 API.
</p>
<p><i><b>Protocol abstraction</b></i> Unlike other mail engines, protocols are seen only
like "communication languages" ruling comunications between clients and
the server. Apache James is not be tied to any particular protocol but
follow an abstracted server design (like JavaMail did on the
client side)</p>
<p><i><b>Complete solution</b></i> the mail system is able to handle both mail
transport and storage in a single server application. Apache James
works alone without the need for any other server or solution.</p>
<p><i><b>Mailet support</b></i> Apache James supports the Apache Mailet API. A Mailet
is a discrete piece of mail-processing logic which is incorporated into
a Mailet-compliant mail-server's processing. This easy-to-write,
easy-to-use pattern allows developers to build powerful customized mail
systems. Examples of the services a Mailet might provide include: a
mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailling
list manager, etc. Several Mailets are included in the JAMES
distribution (see <a href="configuration.html">Configuration</a>).</p>
<p><i><b>Resource abstraction</b></i> Like protocols, resources are abstracted and,
accessed through defined interfaces (JavaMail for transport, JDBC for
spool storage or user accounts in RDBMS's, Apache Mailet API). The server is
highly modular and reuse solutions from other projects.</p>
<p><i><b>Secure and multi-threaded design</b></i> Based on the technology developed
for the Apache JServ servlet engine, Apache James has a careful,
security-oriented, full multi-threaded design, to allow performance,
scalability and mission-critical use.</p>
<p>Anything else you may want if you help us write it :-)</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Feature Status"><strong>Feature Status</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<table>
<tr>
<td bgcolor="#039acc" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Item
</font>
</td>
<td bgcolor="#039acc" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Status (v1.2.1)
</font>
</td>
<td bgcolor="#039acc" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Since
</font>
</td>
<td bgcolor="#039acc" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
First released
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
SMTP server
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.0
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
0.95
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Mailet Engine
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
0.95
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
FileSystem mailboxes/spool
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.0
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
RDBMS mailboxes/spool
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
POP3 server
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.1
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.0
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
RDBMS - Users
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2.1
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2.1
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
LDAP Support - Users
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Experimental
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
TLS Support - POP3
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Experimental
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Remote Manager
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.0
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.0
</font>
</td>
</tr>
<tr>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
TLS Support - Remote Manager
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
Stable
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
<td bgcolor="#a0ddf0" colspan="" rowspan="" valign="top" align="left">
<font color="#000000" size="-1" face="arial,helvetica,sanserif">
1.2
</font>
</td>
</tr>
</table>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/install.html
Index: install.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Serge Knystautas">
<meta name="email" value="sergek@lokitech.com">
<title>The Jakarta Site - Installation</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Step 0: Building. (only necessary for daily snapshots)"><strong>Step 0: Building. (only necessary for daily snapshots)</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
If you have downloaded a regular distribution, you do not need to
build James. Proceed directory to Step 1.
</p>
<p>
To compile James from sources you will need <a href="http://jakarta.apache.org/ant/">Ant</a>.
This is a Java-tailored, XML-configured, extensible build or make system.
We are currently using Ant 1.1, although documentation generation requires Ant 1.2.
</p>
<p>
If you have downloaded a daily snapshot, you need to build a
distribution. James uses Ant (<a href="http://jakarta.apache.org/ant/">http://jakarta.apache.org/ant/</a>) to
compile and package its distribution. Once you have installed Ant,
extracted the snapshot to your favorite folder, cd to that folder
and run the "dist" task by calling "ant dist". This will create the
distribution in the "./dist" folder as well as create .tgz and .zip
copies of this folder. This "./dist" folder is the distribution
folder used in Step 1 and beyond. You may either cd to ./dist, or
you may copy and rename the dist folder to your new favorite folder.
</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Step 1: Installation."><strong>Step 1: Installation.</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
Download distibution. Extract all files in your favorite folder.
</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Step 2: Configuration."><strong>Step 2: Configuration.</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
Read the short and snappy documentation at docs/index.html for a proper
overview of configuring the system.
</p>
<p>
<b>Summary</b> (for impatient people)
</p>
<p>
M$ users should just run /bin/run.bat. Unix users will find run.sh
under the same folder. A JVM must be in the path.
Running [run* -help] will provide a simple command line help.
</p>
<p>
Most UNIX systems require superuser privileges to open sockets below 1024,
which includes the IANA-standard SMTP (on port 25) and POP3 (on port 110).
These default ports can be changed in the conf.xml file. (Obviously, you
would then need to reconfigure your clients. This may not be an option if
you want to receive mail from external mailservers.)
</p>
<p>
The Avalon framework will unpack the neccessay configuration files and wait
for you to configure them. For basic use, you only need to set two items
in the JAMES.conf.xml file: a root password for the remote administration
facility and the IP address of a DNS server. Once you have edited the
configuration files, press 'Enter' on the terminal where Avalon is waiting.
</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Step 4: Kickstart."><strong>Step 4: Kickstart.</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
Once started you'll see a message saying Avalon is running. This means that
Avalon has loaded JAMES and every other needed Block (see /logs/avalon.log)
and is now waiting for a socket request.
Since at the beginning James is empty, it will not have any local users
registered.
To register a local user open a telnet session with localhost on port 4555,
log in as root ("root[enter] <password-you-set-in-conf.xml>[enter]") and
type "help" for a list of available commands in the "JAMES remote
administrator tool". It is really a basic set but should allow you to test
installation.
</p>
<p>
Once you have some local users registered, try sending mail to one of them
@localhost with SMTP (port 25) (assuming you have not changed the default
server names in the conf.xml file). You'll see the mail appear under
../var/mail/localinbox/[user].
Try now to retrieve that mail using POP3 (port 110).
Trace out JAMES actions in /logs/*info.log.
Action that will be taken by JAMES on incoming mail are configurated in
the mailet pipe line (/conf/james.conf.xml). Look at it if you want to
understand what's happening.
</p>
<p>
Good luck :)
</p>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/license.html
Index: license.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Serge Knystautas">
<meta name="email" value="sergek@lokitech.com">
<title>The Jakarta Site - Apache Software License</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Apache Software License"><strong>Apache Software License</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
James is released under the Apache Software License
listed below:
</p>
<div align="left">
<table cellspacing="4" cellpadding="0" border="0">
<tr>
<td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
<td bgcolor="#023264" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
<td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
</tr>
<tr>
<td bgcolor="#023264" width="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
<td bgcolor="#ffffff"><pre>
The Apache Software License, Version 1.1
Copyright (c) 2001 The Apache Software Foundation. All rights
reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The end-user documentation included with the redistribution, if
any, must include the following acknowlegement:
"This product includes software developed by the
Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowlegement may appear in the software itself,
if and wherever such third-party acknowlegements normally appear.
4. The names "The Jakarta Project", "James", and "Apache Software
Foundation" must not be used to endorse or promote products derived
from this software without prior written permission. For written
permission, please contact apache@apache.org.
5. Products derived from this software may not be called "Apache"
nor may "Apache" appear in their names without prior written
permission of the Apache Group.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
====================================================================
This software consists of voluntary contributions made by many
individuals on behalf of the Apache Software Foundation. For more
information on the Apache Software Foundation, please see
<http://www.apache.org/>.
</pre></td>
<td bgcolor="#023264" width="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
</tr>
<tr>
<td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
<td bgcolor="#023264" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
<td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
</tr>
</table>
</div>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/mailets.html
Index: mailets.html
===================================================================
<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="./mailets_files/filelist.xml">
<title>Matchers</title>
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Author>Serge Knystautas</o:Author>
<o:LastAuthor>Serge Knystautas</o:LastAuthor>
<o:Revision>4</o:Revision>
<o:TotalTime>63</o:TotalTime>
<o:Created>2000-10-14T14:03:00Z</o:Created>
<o:LastSaved>2000-10-14T15:56:00Z</o:LastSaved>
<o:Pages>1</o:Pages>
<o:Words>127</o:Words>
<o:Characters>728</o:Characters>
<o:Company>Loki Technologies</o:Company>
<o:Lines>6</o:Lines>
<o:Paragraphs>1</o:Paragraphs>
<o:CharactersWithSpaces>894</o:CharactersWithSpaces>
<o:Version>9.2720</o:Version>
</o:DocumentProperties>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery>
<w:DisplayVerticalDrawingGridEvery>0</w:DisplayVerticalDrawingGridEvery>
<w:UseMarginsForDrawingGridOrigin/>
<w:Compatibility>
<w:FootnoteLayoutLikeWW8/>
<w:ShapeLayoutLikeWW8/>
<w:AlignTablesRowByRow/>
<w:ForgetLastTabAlignment/>
<w:LayoutRawTableWidth/>
<w:LayoutTableRowsApart/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;
mso-font-charset:2;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:0 268435456 0 0 -2147483648 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
h1
{mso-style-next:Normal;
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:1;
font-size:16.0pt;
mso-bidi-font-size:10.0pt;
font-family:"Times New Roman";
mso-font-kerning:0pt;}
h2
{mso-style-next:Normal;
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:2;
font-size:12.0pt;
mso-bidi-font-size:10.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:954022716;
mso-list-type:hybrid;
mso-list-template-ids:708707336 2039251646 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>
<div class=Section1>
<h1>Mailets</h1>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>AvalonListserv</h2>
<p class=MsoNormal>An Avalon-based listserv.<span style="mso-spacerun: yes">�
</span>This uses settings specified in the JAMES.conf.xml file, and uses an
Avalon UserRepository manager as the listserv members.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Required parameters:</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><members><br>
The URL to the Avalon UserRepository.</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><membersonly><br>
<span style="mso-spacerun: yes">�</span>Either true or false.<span
style="mso-spacerun: yes">� </span>Indicates whether only members of this
listserv can send messages to it.</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><attachmentsallowed><br>
<span style="mso-spacerun: yes">�</span>Either true or false.<span
style="mso-spacerun: yes">� </span>Indicates whether you can send attachments
to this listserv.</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><replytolist><br>
<span style="mso-spacerun: yes">�</span>Either true or false.<span
style="mso-spacerun: yes">� </span>Indicates whether the Reply-To header is
set, which will direct replies to the list itself.</p>
<p class=MsoNormal>Optional parameters:</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><subjectprefix><br>
<span style="mso-spacerun: yes">�</span>This text will be put in brackets at
the beginning of the subject of the message if specified.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>AvalonListservManager</h2>
<p class=MsoNormal>An Avalon-based listserv manager.<span style="mso-spacerun:
yes">� </span>Handles adding a removing members to the specified
UserRepository.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Required parameters:</p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><members></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]>-<span style='font:7.0pt "Times New Roman"'>
</span><![endif]><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
</div>
</body>
</html>
1.1 jakarta-james/www/matchers.html
Index: matchers.html
===================================================================
<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="./matchers_files/filelist.xml">
<title>Matchers</title>
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Author>Serge Knystautas</o:Author>
<o:LastAuthor>Serge Knystautas</o:LastAuthor>
<o:Revision>3</o:Revision>
<o:TotalTime>27</o:TotalTime>
<o:Created>2000-10-14T14:03:00Z</o:Created>
<o:LastSaved>2000-10-14T14:31:00Z</o:LastSaved>
<o:Pages>2</o:Pages>
<o:Words>443</o:Words>
<o:Characters>2529</o:Characters>
<o:Company>Loki Technologies</o:Company>
<o:Lines>21</o:Lines>
<o:Paragraphs>5</o:Paragraphs>
<o:CharactersWithSpaces>3105</o:CharactersWithSpaces>
<o:Version>9.2720</o:Version>
</o:DocumentProperties>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery>
<w:DisplayVerticalDrawingGridEvery>0</w:DisplayVerticalDrawingGridEvery>
<w:UseMarginsForDrawingGridOrigin/>
<w:Compatibility>
<w:FootnoteLayoutLikeWW8/>
<w:ShapeLayoutLikeWW8/>
<w:AlignTablesRowByRow/>
<w:ForgetLastTabAlignment/>
<w:LayoutRawTableWidth/>
<w:LayoutTableRowsApart/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
h1
{mso-style-next:Normal;
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:1;
font-size:16.0pt;
mso-bidi-font-size:10.0pt;
font-family:"Times New Roman";
mso-font-kerning:0pt;}
h2
{mso-style-next:Normal;
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:2;
font-size:12.0pt;
mso-bidi-font-size:10.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>
<div class=Section1>
<h1>Matchers</h1>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>All</h2>
<p class=MsoNormal>Every mail with all recipients is always matched.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>No condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>CommandForListserv</h2>
<p class=MsoNormal>Matches the �on and �off version of the address
specified.<span style="mso-spacerun: yes">� </span>For instance, if the match
was specified as CommandForListserv=james@list.working-dogs.com, then this
match would match james-on@list.working-dogs.com and james-off@list.working-dogs.com.
<span style="mso-spacerun: yes">�</span>Useful to channel listserv commands to
a different mailet.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: listserv address to use as base.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>HostIs</h2>
<p class=MsoNormal>Matches recipients where the domain of the recipient�s email
address matches the host specified in the condition.<span style="mso-spacerun:
yes">� </span>This is a string comparison and does not check DNS information.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: the hostname to compare to the recipient�s domain
name.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>HostIsLocal</h2>
<p class=MsoNormal>Matches recipients where the domain of the recipient�s email
address matches one of the hosts handled by this server.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>No condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>RecipientIs</h2>
<p class=MsoNormal>Matches recipients against a comma or space delimited list
of recipient email addresses (exactly).</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a comma or space delimited list of email addresses.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>RecipientIsLocal</h2>
<p class=MsoNormal>Matches the recipient�s domain against the hosts handled by
this server and the recipient�s user against the user accounts of this server.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>No condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>RelayLimit</h2>
<p class=MsoNormal>Matches mail is it has been relayed more than the number
specified in the condition.<span style="mso-spacerun: yes">� </span>Determines number
of hops by counting the number of �Received� headers in the message.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: the number of hops at which this message should
start matching.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>RemoteInNetwork</h2>
<p class=MsoNormal>Matches mail if the remote IP address of the sending machine
is in one of the networks specified in the condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a comma or space delimited list of IP addresses
and networks.<span style="mso-spacerun: yes">� </span>Networks are specified by
leaving off the appropriate subnet mask as is done in /etc/hosts.allow and /etc/hosts.deny
in unix, e.g., �38.177.223.�</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>RemoteNotInNetwork</h2>
<p class=MsoNormal>Matches mail if the remote IP address of the sending machine
is not in one of the networks specified in the condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a comma or space delimited list IP addresses and
networks.<span style="mso-spacerun: yes">� </span>Networks are specified by
leaving off the appropriate subnet mask as is done in /etc/hosts.allow and /etc/hosts.deny
in unix, e.g., �38.177.223.�</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>SenderInFakeDomain</h2>
<p class=MsoNormal>Does a DNS lookup for MX, A or CNAME record on the sending email
address�s domain part.<span style="mso-spacerun: yes">� </span>If no DNS
records are found, the mail is matched.<span style="mso-spacerun: yes">�
</span>(useful for blocking mail with forged email addresses.)</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>No condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>SenderIs</h2>
<p class=MsoNormal>Matches mail if sender is one of the email addresses
specified in the condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a comma or space delimited list of email addresses.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>SubjectIs</h2>
<p class=MsoNormal>Matches mail if the subject is the same as the one specified
in the condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a subject to match.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>SubjectStartsWith</h2>
<p class=MsoNormal>Matches mail if the subjects starts with the one specified
in the condition.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a subject fragment to compare.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<h2>UserIs</h2>
<p class=MsoNormal>Matches mail if the user part of a recipient�s email address
matches one of the users specified in the condition.<span style="mso-spacerun:
yes">� </span>The user portion of an email address is the part before the @
symbol.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal>Condition: a comma or space delimited list of users.</p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
<p class=MsoNormal><![if !supportEmptyParas]> <![endif]><o:p></o:p></p>
</div>
</body>
</html>
1.1 jakarta-james/www/proposalIMAP.html
Index: proposalIMAP.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h1 align="center">IMAP Proposal - First Draft</h1>
<h4 align="center">JAMES 1.1</h4>
<h3>Overview of proposed IMAP server on JAMES</h3>
<blockquote>
Objective: A set of interfaces and basic implementations that provide:
<ul>
<li>The core functionality of RFC 2060, IMAP4Rev1.</li>
<li>Mailbox referrals - RFC 2193</li>
<li>Login referrals - RFC 2221</li>
<li>Access Control Lists - RFC 2086</li>
<li>Quotas - RFC 2087</li>
<li>Namespaces - RFC 2342</li>
</ul>
</blockquote>
<h3>System, hosts and Mailboxes</h3>
<table >
<tr>
<td colspan=6></td>
<td align="center">**************<br>* IMAPSystem *<br>**************</td>
<td colspan=6></td>
</tr>
<tr>
<td colspan=6 align="center">********<br>* Host *<br>********</td>
<td></td>
<td colspan=6 align="center">********<br>* Host *<br>********</td>
</tr>
<tr>
<td colspan=2 align="center">********************<br>* Folder Repository *<br>********************</td>
<td colspan=2 align="center">***********<br>* Mailbox *<br>***********</td>
<td colspan=2 align="center">***********<br>* Mailbox *<br>***********</td>
<td></td>
<td colspan=2 align="center">********************<br>* Folder Repository *<br>********************</td>
<td colspan=2 align="center">***********<br>* Mailbox *<br>***********</td>
<td colspan=2 align="center">***********<br>* Mailbox *<br>***********</td>
</tr>
<tr>
<td align="center">**********<br>* Folder *<br>* Record *<br>**********</td>
<td align="center">**********<br>* Folder *<br>* Record *<br>**********</td>
<td align="center">***********<br>* Message *<br>***********</td>
<td align="center">***********<br>* Message *<br>* Attribute *<br>***********</td>
<td align="center">***********<br>* Message *<br>***********</td>
<td align="center">***********<br>* Message *<br>* Attribute *<br>***********</td>
<td></td>
<td align="center">**********<br>* Folder *<br>* Record *<br>**********</td>
<td align="center">**********<br>* Folder *<br>* Record *<br>**********</td>
<td align="center">***********<br>* Message *<br>***********</td>
<td align="center">***********<br>* Message *<br>* Attribute *<br>***********</td>
<td align="center">***********<br>* Message *<br>***********</td>
<td align="center">***********<br>* Message *<br>* Attribute *<br>***********</td>
</tr>
</table>
<p>
<b>interface IMAPSystem</b><br>
An IMAP system may include more than one host (ie server in the physical machine sense). For example, different hosts may handle private mailboxes, shared mailboxes and news. This interface allows a James instance to identify other servers in the IMAP system, for Login referrals and Mailbox referrals.
</p>
<p>
<b>interface Host</b><br>
An IMAP host establishes if a user has their private mail here or access to any other mail. It handles access to a mailbox.
<blockquote>
plan: <i>implemented by James.java</i>
</blockquote>
</p>
<p>
<b>interface FolderRecord</b><br>
An IMAP server needs to keep track of deleted mailboxes, so that mailboxes created with the name of a previously deleted mailbox have different UID or UIDValidity values. In some circumstances, a mailbox may be deleted but not available for its name to be reused. This interface captures this data.
<blockquote>
plan: <i>class SimpleFolderRecord</i> File system implementation of FolderRecord.
</blockquote>
</p>
<p>
<b>interface RecordRepository</b><br>
Place to keep FolderRecords
<blockquote>
plan: <i>class AvalonFolderRepository</i> FileSystem implementation.
</blockquote>
</p>
<p>
<b>interface MailBox</b><br>
As well as storing messages, an IMAP mailbox needs to keep track of folder options, such as whether inferiors/ child folders are allowed and accepatable flags and message attributes (such as flags, and envelope details).
<blockquote>
plan: <i> AvalonMailbox</i> FileSystem implementation of IMAPMailBox.
</blockquote>
</p>
<p>
<b>interface MessageAttributes</b><br>
Holds message flags and parsed data.
<blockquote>
plan: <i>class FileMessageAttributes</i> FileSystem implemetation of IMAPMessageAttributes.
</blockquote>
</p>
<h3>Servers, Connections, Commands, Events</h3>
<p>
<b>class Server</b><br>
Monitors socket and launches connection handler.
</p>
<p>
<b>interface ConnectionHandler</b>
<br>
Each instance handles a single connection. This includes authenticating the user, collecting commands from the client (which can require server input) and then arranging for the commands to be processed. The connection handler may arrange for multiple non-ambiguous commands to be processed concurrently, but must process ambiguous multiple commands in the order in which they are received from the client. See the <a href="commandsIMAP.html">Overview of IMAP commands</a>.
</p>Because IMAP s designed for long-lived connections (the minimum timeout is 30 minutes) it is likely that new mail will be delivered to an Inbox or mail may be added to or removed from a shared mailbox while no client commands are in process. The protocol therefore allows server data to be sent unilaterally to the client, that is not in response to a request for that data. Unilateral data may be sent while a command is being processed, indeed mailbox size changes must be sent if observed during the course of processing a command. The server may also send data while no commands are being processed (except for Expunge responses).
<p>
<b>class MailboxEvent</b>
<br>
MailboxEvents are sent by MailboxEventSources to any registered listener when there has been a relevant change in the Mailbox.
<p>
<b>interface MailboxEventListener</b>
<br>
The MailBoxEventListener interface is implemented by any object needing to monitor a mailbox. The Listener must register with the appropriate EventSource. Typically a ConnectionHandler will register with a Mailbox when it enters selected state and deregister when that mailbox is deselected.
<p>
<b>interface MailboxEventSource</b>
<br>
The MailboxEventSource interface is implemented by any object needing to send events to listeners. Typically a mailbox.
<p>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/statusIMAPserver.html
Index: statusIMAPserver.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h3 align = left><a href="index.html">Up to Index</a></h3>
<h1 align="center">Status of the IMAP Server</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Summary</h3>
<blockquote>
<p>This document explains the status of the IMAP server portion of James, ie what functionality has been implemented or tested and what needs to be done.</p>
</blockquote>
<h3>Objectives for JAMES IMAP server</h3>
<b>Primary objectives:</b>
<ul>
<li>Basic IMAPv4rev1 compliance - RFC2060</li>
<li>AccessControlLists - RFC2086</li>
<li>multiple Namespaces - RFC2342</li>
<li>Single server</li>
<li>Filesystem based mail storage.</li>
<li>Filesystem based user storage.</li>
</ul>
<b>Secondary objectives:</b>
<ul>
<li>Mail quotas - RFC</li>
<li>LDAP based user storage</li>
<li>Multiple servers - RFCs</li>
<li>RDBMS based mail storage.</li>
<li>more funky IMAP stuff</li>
</ul>
<h3>Status</h3>
<b>RFC2060 (Core IMAP) commands</b>
<table cols=7>
<tr>
<th>Command</th>
<th>Implemented</th>
<th>Tested - telnet</th>
<th>Tested - Pine</th>
<th>Tested - Netscape Messenger</th>
<th>Tested - Microsoft Outlook</th>
<th>Comments</th>
</tr>
<tr>
<th colspan ="7">RFC2060 (Core IMAP) commands</th>
</tr>
<tr align=center>
<td>CAPABILITY</td>
<td>Yes</td>
<td>OK</td>
<td>OK</td>
<td>OK</td>
<td></td>
<td>update as functionality added</td>
</tr>
<tr align=center>
<td>NOOP</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td>OK</td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>LOGOUT</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>AUTHENTICATE</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td>No authentication methods other than plaintext password login supported</td>
</tr>
<tr align=center>
<td>LOGIN</td>
<td>Yes</td>
<td>OK</td>
<td>OK</td>
<td>OK</td>
<td></td>
</tr>
<tr align=center>
<td>SELECT</td>
<td>Yes</td>
<td>OK</td>
<td>OK</td>
<td>OK</td>
<td></td>
</tr>
<tr align=center>
<td>EXAMINE</td>
<td>Yes</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>CREATE</td>
<td>Yes</td>
<td></td>
<td></td>
<td>OK</td>
<td></td>
</tr>
<tr align=center>
<td>DELETE</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>JamesHost needs to implement this</td>
</tr>
<tr align=center>
<td>RENAME</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>JamesHost needs to implement this</td>
</tr>
<tr align=center>
<td>SUBSCRIBE</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>Need to design user object to hold subscriptions</td>
</tr>
<tr align=center>
<td>UNSUBSCRIBE</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>see SUBSCRIBE</td>
</tr>
<tr align=center>
<td>LIST</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>unsure</td>
</tr>
<tr align=center>
<td>LSUB</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>see SUBSCRIBE and LIST</td>
</tr>
<tr align=center>
<td>STATUS</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td>unsure</td>
</tr>
<tr align=center>
<td>APPEND</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>not started</td>
</tr>
<tr align=center>
<td>CHECK</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>CLOSE</td>
<td>Yes</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>EXPUNGE</td>
<td>Yes</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>SEARCH</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>not started</td>
</tr>
<tr align=center>
<td>FETCH</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>see table below</td>
</tr>
<tr align=center>
<td>STORE</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>COPY</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>not started</td>
</tr>
<tr align=center>
<td>UID</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td>UID FETCH (partial) and UID STORE only</td>
</tr>
<tr>
<th colspan =7>Fetch command arguments</th>
</tr>
<tr>
<th>Arguments</th>
<th>Implemented</th>
<th>Tested - telnet</th>
<th>Tested - Pine</th>
<th>Tested - Netscape Messenger</th>
<th>Tested - Microsoft Outlook</th>
<th>Comments</th>
</tr>
<tr align=center >
<td>ALL</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>BODY</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>1-part, multipart and embedded rfc822 messages where constituents are of type Text/Plain. Line count is not right.</td>
</tr>
<tr align=center>
<td>BODY[] & BODY.PEEK[]</td>
<td>yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>BODY[section] & BODY.PEEK[section]</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>TEXT, HEADER, HEADER.FIELDS & HEADER.FIELDS.NOT done - but HEADER.FIELDS buggy on Netscape. MIME, numbered sections, subsections and octet-partial-fetches not started</td>
</tr>
<tr align=center>
<td>BODYSTRUCTURE</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>See body</td>
</tr>
<tr align=center>
<td>ENVELOPE</td>
<td>Yes</td>
<td>OK</td>
<td>No</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>FAST</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>FLAGS</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>FULL</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>INTERNALDATE</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>Format is not right</td>
</tr>
<tr align=center>
<td>RFC822</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>RFC822.HEADER</td>
<td>no</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>RFC822.SIZE</td>
<td>Partial</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>giving content size not message size</td>
</tr>
<tr align=center>
<td>RFC822.TEXT</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>UID</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<th colspan =7>RFC2086 (Access Control Lists) commands</th>
</tr>
<tr>
<th>Command</th>
<th>Implemented</th>
<th>Tested - telnet</th>
<th>Tested - Pine</th>
<th>Tested - Netscape Messenger</th>
<th>Tested - Microsoft Outlook</th>
<th>Comments</th>
</tr>
<tr align=center>
<td>SETACL</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>DELETEACL</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>GETACL</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>LISTRIGHTS</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr align=center>
<td>MYRIGHTS</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr
<tr>
<th colspan =7>RFC2342 (Namespaces) commands</th>
</tr>
<tr>
<th>Command</th>
<th>Implemented</th>
<th>Tested - telnet</th>
<th>Tested - Pine</th>
<th>Tested - Netscape Messenger</th>
<th>Tested - Microsoft Outlook</th>
<th>Comments</th>
</tr>
<tr align=center>
<td>NAMESPACE</td>
<td>Yes</td>
<td>OK</td>
<td></td>
<td>OK</td>
<td></td>
<td>Currently only providing a private mailbox namesapce and an other users mailbox namespace. Shared mailboxes and newsgroup access tbd</td>
</tr>
</table>
<h3 align = left><a href="index.html">Up to Index</a></h3>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/todo.html
Index: todo.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Serge Knystautas">
<meta name="email" value="sergek@lokitech.com">
<meta name="author" value="Charles Benett">
<meta name="email" value="charles@benett1.co.uk">
<title>The Jakarta Site - TODO</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/james/"><img src="./images/james-logo.jpg" alt="JAMES - Java Apache Mail Enterprise Server" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>About</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./install.html">Install</a>
</li>
<li> <a href="./mailets.html">Mailets Concept</a>
</li>
<li> <a href="./code-standards.html">Coding Standards</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="./todo.html">TODO</a>
</li>
</ul>
<p><strong>Guides</strong></p>
<ul>
<li> <a href="./javadoc/mailet/index.html">Mailet API</a>
</li>
<li> <a href="./usingLDAP.html">Using LDAP</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="TODO"><strong>TODO</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback.
Last Updated 26 April 2001.</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="High Priority"><strong>High Priority</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>Port existing documentation to xdocs format</p>
<p>Bundle docs in dist</p>
<p>Allow RemoteManager to change passwords of users (change attribute) </p>
<p>Revive RDBMS support for messages and users. Possibly move from town to straight jdbc, or jakarta-turbine.</p>
<p>Enable multiple domains</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Medium Priority"><strong>Medium Priority</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>Let RemoteDelivery send all messages to a single remote server (acting like a gateway or a relay host) </p>
<p>Improve exception management in RemoteDelivery mailet and general notices of why delivery failures occur.</p>
<p>Add support for regex inside most matchers and thereby consolidate a few of them.</p>
<p>Write more documentation. </p>
<p>Make James stoppable (elegantly)</p>
<p>Get IMAP server to alpha standard, ie basic interoperation with e-mail clients.</p>
<p>Add #news namespace to IMAP system</p>
<p>Revisit UserRepository - after doing IMAP List & Subscribe</p>
<p>Make James reconfigurable/contextualizable/composable.</p>
<p>Reinject error/spam mails incorrecty handled.</p>
<p>Add needed functions to RemoteManager, Including Stop and ReConfigure, Reinject mail, Store RemoteManger password securely.</p>
<p>Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipline pattern</p>
<p>Add support for deployable message processing apps using Camelot pattern</p>
<p>Give admins option to enforce one access at a time to a POP3 mailbox.</p>
<p>Simplify email aliasing</p>
</blockquote>
</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Low Priority"><strong>Low Priority</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.</p>
<p>Add support for DRAC login/relay allowing</p>
<p>Review threadpooling - is it dynamic?</p>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-james/www/usingDatabaseRepository.html
Index: usingDatabaseRepository.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h1 align="center">Using a Database Mail Repository</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Summary</h3>
<blockquote>
<p>This document explains how to enable JAMES to use a database to store mail messages for spools, user accounts, and other usages.</p>
</blockquote>
<h3>Obtain a JDBC driver</h3>
<blockquote>
<p>Obtain a suitable JDBC driver for a suitable vendor. A non-production grade JDBC-ODBC is included in the JDK, and many commercial and free drivers are available. See <a href="http://java.sun.com/products/jdbc/drivers/">http://java.sun.com/products/jdbc/drivers/</a> for a list of suitable drivers. JAMES uses the Town library (<a href="http://www.working-dogs.com/town/">http://www.working-dogs.com/town/</a>) to access a database, and you can use any JDBC 1.X or greater compliant database driver. Town also handles connection pooling.</p>
<p>Note that as JAMES will repeatedly send large amounts of text and binary across this driver, we recommend production grade drivers whenever possible.</p>
</blockquote>
<h3>Define a database connection</h3>
<blockquote>
<p>In the <i>var</i> directory of the JAMES distribution, you will find several sample database connection definition files. These are sample Properties files that define the necessary information to connect to a database. You may either rename one of these to <i>maildatabase</i>, or you may create your own database connection definition file. Important properties to set are the driver classname, the JDBC URL, and the username and password.</p>
</blockquote>
</h3>
<h3>Create a table in your database</h3>
<blockquote>
<p>JAMES expects to use a table named "Message" in whatever database you've specified. Sample SQL scripts to create this table in SQL Server and MySQL are available in this docs directory. If you are using another database, you can hopefully see the necessary structure and can create it for your database. Please submit these to us! (we'll include them in future distributions)</p>
</blockquote>
</h3>
<h3>Enable a Database Mail Repository</h3>
<blockquote>
<p>After the bootstrap startup, when you edit the JAMES.conf.xml file, you will see several places that specify a mail or spool repository. Commented out next to several of these entries are alternate settings to use the database connection definition defined above.</p>
<p>The format of the URL to use the database mail or spool repository is town://<repositoryname>@<conndef-filename> The alternate settings for the database repository expect the filename to be <i>maildatabase</i>, which is why above we recommended you rename it.
</p>
</blockquote>
<h3>Verify JAMES establishes a database connection</h3>
<blockquote>
<p>In the bin directory where run.bat and run.sh (or whatever directory you were in when you started JAMES), you should see a file named something like DCB_970616938320.log. If this file does not exist, JAMES was unable to find the connection definition file or it was unable to find the database driver.</p>
<p>Open this file, and you will see the server's attempt to connect to the server. If successful, you will see the log shows one or two open connections were established. If you are seeing repeated attempts to reconnect to the database, either the JDBC URL is incorrect, or the username and password are incorrect.
</p>
</blockquote>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/usingLDAP.html
Index: usingLDAP.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h3 align = left><a href="index.html">Up to Index</a></h3>
<h1 align="center">Using LDAP as a Users Repository</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Summary</h3>
<blockquote>
<p>This document explains how to enable JAMES to use an LDAP directory as a Users Repository</p>
</blockquote>
<h3>Summary</h3>
<blockquote>
<p>We have tried to make the LDAP implementation of UsersRepository as flexible a possible, recognising that each installation will have a unique directory schema.</p>
<p>We assume that all users that a James Mailserver will handle fall within one single-rooted tree. The root of this tree, ie the lowest node in the directory which is an ancestor for all users served by this mailserver and the mailserver, is called the LDAPRoot. (See diagram)</p>
<p>It is entirely possible that an organization may have more than one mail server. Consequently, the fact that a user is in the Directory does not imply that this mailserver should handle mail for them.
<p>This implementation of UsersRepository creates one node (object) for each set of mail users. The set called 'LocalUsers' is the set of users whose mail is handled by this server. Other sets include any mail-lists handled by the server. Each member of a set is recorded as an attribute of these objects. These nodes are child nodes of the mailserver.
<p>The mailserver will accept mail for local delivery if the user part of the email address matches a member of LocalUsers and if the domain/host part of the email address matches the first servername . (Set servernames autodetect to false and enter the domain served as the first servername, e.g. apache.org).
<p>For POP3 authentication, the mailserver first finds the user entry in the directory, underLDAPRoot, whose attribute, specified as MailAttribute in conf, matches user@domain. The mailserver authenticates the POP3 user if it can bind to the directory as that user entry with the offered password.
<p>This implementation does not set passwords in the directory. Use a dummy password when invoking adduser in RemoteManger.
<p>If ManageGroupAttribute is set to TRUE (as it is by default), then the RemoteManger will add/remove the full DN of the email group to/from the user entry. This facilty allows users to ask the directory what is my mailserver and what email lists am I subscribed to?
</blockquote>
<h3>Diagram</h3>
<table cellspacing=0>
<tr>
<td> </td>
<td align="center">Root of Directory<br>Example: dc=org<br>May not be referenced in conf.xml<br>|<br>|</td>
<td> </td>
</tr>
<tr>
<td colspan=3 align="center">-------------------------------------------------------------------------------------------------</td>
</tr>
<tr>
<td align="center" valign="top">|<br>Subtree not served by James<br> e.g.: dc=w3c, dc=org </td>
<td align="center" valign="top">|<br>Subtree served by James<br> e.g.: dc=apache, dc=org <br>"LDAPRoot"<br>|</td>
<td align="center" valign="top">|<br>Subtree not served by James<br> e.g.: dc=xml, dc=org </td>
</tr>
<tr>
<td> </td>
<td>
<table cellspace=0>
<tr>
<td colspan=4 align="center">----------------------------------------------------</td>
</tr>
<td align="center" valign="top">|<br>This mailserver <br>cn=mailserver.apache.org<br>|<BR>---------------</td>
<td align="center" valign="top">|<br>A user <br>cn=King Arthur<br> memberOfGroup=<br>cn=LocalUsers etc </td>
<td align="center" valign="top">|<br>A user <br>cn=Morgan LeFay </td>
<td align="center" valign="top">|<br>Another mailserver <br>cn=oldmail.apache.org</td>
<tr>
<td>
<table cellspace=0>
<tr>
<td align="center" valign="top"> |<br>LocalUsers<br>member=Arthur</td>
<td align="center" valign="top"> |<br>list-james<br>member=Arthur</td
</tr>
</table>
</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</table>
</td>
<td> </td>
</table>
<p align="center">
<p align="center">
<p align="center">
<p align="center">
<p align="center">
<h3>Installation</h3>
<blockquote>
<p>Six entries in JAMES.conf.xml must be set for this to work:</p>
<ul>
<li>change usersManager - type to ldap.
<li>Set the ldapServer element to point to the correct host and port
<li>Set LDAPRoot and ThsServerRDN.
<li>Set the direcory FDN and password that should be used to write to the directory.
<li>Unless all your users have email addresses of the form, name@the-machine-running-James, set servernames-autodetect to false and apecify the your email domain as the first servername.
</ul>
<h3 align = left><a href="index.html">Up to Index</a></h3>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/usingTLS.html
Index: usingTLS.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<title>Java Apache Mail Enterprise Server</title>
</head>
<body BGCOLOR="#FFFFFF">
<!--
<h2 align="center"><img SRC="images/java-apache-project.gif" BORDER="0" HEIGHT="100"
WIDTH="609"></h2>
-->
<h3 align = left><a href="index.html">Up to Index</a></h3>
<h1 align="center">Using TLS (SSL)</h1>
<h4 align="center">JAMES 1.2</h4>
<h3>Summary</h3>
<blockquote>
<p>This document explains how to enable JAMES to use Transport Layer Security (TLS) (ie SSL).</p>
</blockquote>
<h3>Obtain JSSE</h3>
<blockquote>
<p>Obtain JSSE source from java.sun.com. Follow their installation directions. We assume that you install JSSE as a standard extension, with a static provider definition. (See notes with JSSE distribution)</p>
<p>Note that the US export restrictions still apply to JSSE (at version 1.0.2), so while both the international and domestic versions offer the same level of crypto, the international version does not take alternative providers.</p>
</blockquote>
<h3>Enable TLS</h3>
<blockquote>
<p>Using JAMES with TLS. You need to do three things over and above the normal operation of James: </p>
<ul>
<li>In Avalon.conf.xml, uncomment the TLS listener defintion.
<li>In JAMES.conf.xml, uncomment the \<useTLS\>TRUE\</useTLS\> element for the service you want to use TLS. It is currently available for remote manager and POP3. (If using POP3 over TLS, it is probably best to change port to 995, which is the IANA designated POP3S port).
<li> Ensure that avalonTestKeys is in the conf directory. You may need to manually extract this from the Avalon.jar (with: jar xvf Avalon.jar conf/avalonTestKeys). Note that this is a self-signed certificate for test purposes only. You can specify a different server certificate in the Avalon.conf.xml file.
</ul>
<p>Start James</p>
</blockquote>
<h3>Verify TLS-enabled JAMES</h3>
<blockquote>
<p>(Positive Test) Use an SSL client to open a socket to the appropriate port. I used openssl from www.openssl.org to test this. E.g. openssl s_client -connect localhost:4555. You should see the normal remote manager or POP3 server greeting and have normal operation.
<br>- If, using openssl s_client, you get a connection refused/ error no 111, just try again. This probably means you got to the port before it was ready.</p>
<p>(Negative Test) telnet to port 4555 (ie without SSL). This should hang the telnet client. It should also lock port 4555 until the connection timesout, I think.</p>
</blockquote>
<h3 align = left><a href="index.html">Up to Index</a></h3>
<p align="center"><font SIZE="-1">Copyright (c) 1997-2000 <a HREF="http://java.apache.org">The
Java Apache Project</a>.<br>
All rights reserved.</font></p>
</body>
</html>
1.1 jakarta-james/www/images/james-logo.jpg
<<Binary file>>
1.1 jakarta-james/www/rfclist/README
Index: README
===================================================================
This Document contains references to relevant RFCs and Drafts.
Basic RFC
---------
RFC 822: Mail Message Format
SMTP
----
POP3
----
IMAP
----
NNTP
----
RFC 977 : NNTP Protocol.
draft-ietf-nntpext-base-13.txt: Latest draft of NNTP protocol
RFC 2980: Common NNTP Extensions
RFC 1036: Format of News Messages
NNTP Working group: http://www.academ.com/academ/nntp/
LDAP
----
1.1 jakarta-james/www/rfclist/draft-ietf-nntpext-base-13.txt
Index: draft-ietf-nntpext-base-13.txt
===================================================================
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Network News Transport Protocol
draft-ietf-nntpext-base-13.txt
1. Status of this Document
This document is an Internet-Draft and is in full conformance
with Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accesses at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft shadow directories can be accessed
at http://www.ietf.org/shadow.html.
This section will be updated with the appropriate verbiage
from RFC 2223 should this document has been found ready for
publication as an RFC.
This document is a product of the NNTP Working Group, chaired
by Ned Freed and Stan Barber.
2. Abstract
The Network News Transport Protocol 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 RFC 977 and officially updates the protocol
specification. It clarifies some vagueness in RFC 977,
includes some new base functionality and provides a specific
mechanism to add standardized extensions to NNTP.
3. Introduction
This document specifies the Network News Transport Protocol
(NNTP), which is used for the distribution, inquiry,
retrieval, and posting of net news articles using a reliable
stream-based mechanism. For news reading clients, NNTP enables
retrieval of news articles that are stored in a central
Barber [Page 1]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
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. For server-to-server
interaction, NNTP is designed for efficient transmission of
net news articles over a reliable full duplex communication
method.
Every attempt is made to insure that the protocol
specification in this document is compatible with the version
specified in RFC 977[1]. However, this version does not
support the ill-defined SLAVE command and permits four digit
years to be specified in the NEWNEWS and NEWGROUPS commands.
It changes the default character set to UTF-8[2] instead of
US-ASCII[3]. It also extends the newsgroup name matching
capabilities already documented in RFC 977.
Generally, new functionality is available using new keywords.
Part of that new functionality involves a mechanism to
discover what new functionality is available to clients from a
server.
This mechanism can also be used to add more functionality as
needs merit such additions.
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 RFC 2119[4].
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 memo, the term "client host" refers
to a host making use of the NNTP service, while the term
"server host" refers to a host that offers the NNTP service.
In addition, where examples of interactions between a client
host and a server host are provided a "[C]" will be used to
represent the client host and a "[S]" will be used to
represent the server host.
4. Basic Operation.
Every NNTP session MUST involve the following in this order:
Barber [Page 2]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
CONNECTION
GREETING
DISCONNECTION
Other steps may occur between the GREETING and DISCONNECTION
step. They are:
CAPABILITIES DISCOVERY
NEWS EXCHANGE
CONCLUSION
NNTP operates over any reliable data stream 8-bit-wide
channel. When running over TCP/IP, the official port for the
NNTP service is 119. Initially, 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. This is the
CONNECTION step. When the connection is established, the NNTP
server host MUST send a greeting. This is the GREETING step.
The client host and server host SHOULD then exchange commands
and responses (respectively) until the connection is closed or
aborted. This final step is called the DISCONNECTION step.
If there is a CONCLUSION step, it MUST immediately precede the
DISCONNECTION step. There MUST be only one CONNECTION,
CONCLUSION and DISCONNECTION step for each NNTP session. All
other steps MAY be repeated as needed. For example, the
GREETING step may be repeated if the client makes use of the
MODE READER command (See Section 7.2 for more on the MODE
READER command).
The character set for all NNTP commands is UTF-8. Commands in
the NNTP MUST consist of an US-ASCII case-insensitive keyword,
which MAY be followed by one or more arguments. An US-ASCII
CRLF pair MUST terminate all commands. Multiple commands MUST
NOT be on the same line. Keywords MUST consist of printable
US-ASCII characters. Unless otherwise noted elsewhere in this
document, arguments SHOULD consist of printable US-ASCII
characters. Keywords and arguments MUST be each separated by
one or more US-ASCII SPACE or US-ASCII TAB characters.
Keywords MUST be at least three US-ASCII characters and MUST
NOT exceed 12 US-ASCII characters. Command lines MUST NOT
exceed 512 octets, which includes the terminating US-ASCII
CRLF pair. Arguments MUST NOT exceed 497 octets.
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. All multi-line
Barber [Page 3]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
responses MUST adhere to the following format: After sending
the first line of the response and an US-ASCII CRLF, any
additional lines are sent, each terminated by an US-ASCII CRLF
pair. When all lines of the response have been sent, a final
line MUST be sent, consisting of a termination octet (US-ASCII
decimal code 046, ".") and an US-ASCII CRLF pair. If any line
of the multi-line response begins with the termination octet,
the line MUST be "byte-stuffed" by pre-pending the termination
octet to that line of the response. Hence, a multi-line
response is terminated with the five octets "CRLF.CRLF" (in
US-ASCII). When examining a multi-line response, the client
MUST check to see if the line begins with the termination
octet. If so and if octets other than US-ASCII CRLF follow,
the first octet of the line (the termination octet) MUST be
stripped away. If so and if US-ASCII CRLF immediately follows
the termination character, then the response from the NNTP
server is ended and the line containing ".CRLF" (in US-ASCII)
MUST NOT be considered part of the multi-line response. Where
a response is multi-line, the description of the command will
define the format of the response before "byte-stuffing" takes
place.
An NNTP server MAY have an inactivity autologout timer. Such a
timer MUST be of at least three minutes duration. The receipt
of any command from the client during that interval SHOULD
suffice to reset the autologout timer. When the timer
expires, the server should close the TCP connection without
sending any response to the client.
4.1 Response Codes
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 ok
3xx - Command ok so far, send the rest of it.
4xx - Command was correct, but couldn't be performed for some
reason.
5xx - Command unimplemented, or incorrect, or a serious
program error occurred.
The next digit in the code indicates the function response
category.
x0x - Connection, setup, and miscellaneous messages
Barber [Page 4]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
x1x - Newsgroup selection
x2x - Article selection
x3x - Distribution functions
x4x - Posting
x8x - Reserved for authentication and authorization extensions
x9x - Reserved for private use (non-standard extensions)
Certain responses contain parameters such as numbers and names
in addition to the status indicator. In those cases, the
number and type of such parameters is fixed for each response
code to simplify interpretation by the client (any extension
MUST follow this principle as well). 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 in response to a given command are detailed in the
description of the keyword that is the first part of the
command.
Parameters MUST be separated from the numeric status indicator
and from each other by a single US-ASCII space. All numeric
parameters MUST be in base 10 (decimal) format, and MAY have
leading zeros. String parameters MUST contain at least one
character and MUST NOT contain US-ASCII spaces, CR, LF, or
tab). The server MAY add any text after the response code or
last parameter 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 parameter by at least
one US-ASCII space.
The server MUST respond to any command with the appropriate
generic response (given in section 4.1.1) 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 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).
Each recognized command MUST return 501 (as above) or 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 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
Barber [Page 5]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
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 standard 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 extension registered with IANA
(see section 12) 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.)
4.1.1 Generic Response Codes
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 it is an optional command
or extension 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, the response code 501 MUST be returned. Note that
where a command has variants depending on a keyword (e.g. LIST
ACTIVE and LIST NEWSGROUPS), then 501 MUST be used when the
requested variant is not implemented but the base command is.
If the client is not authorized to use the specified facility
when the server is in its current state, the response code 502
MUST be returned. A different command MIGHT change the server
state and permit the command if it is retried.
If the server does not provide an optional feature, then the
response code 403 MUST be returned if the omission is
temporary (e.g. because a necessary facility is unavailable)
and the code 503 if it is permanent (e.g. because the server
does not store the required information).
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 TCP connection. It MAY give a 401
response code to any command to indicate that termination is
Barber [Page 6]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
imminent (following a 401 response, it MUST NOT close the TCP
connection immediately).
5. The WILDMAT format
The WILDMAT format[5] described here is based on the version
first developed by Rich Salz which was 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. Patterns are implicitly anchored at the beginning
and end of each string when testing for a match. There are
five pattern-matching operations other than a strict one-to-
one match between the pattern and the source to be checked for
a match. The first is an asterisk (*) to match any sequence of
zero or more UTF-8 characters. The second is a question mark
(?) to match any single UTF-8 character. The third specifies a
specific set of characters. The set is specified as a list of
characters, or as a range of characters where the beginning
and end of the range are separated by a minus (or dash)
character, or as any combination of lists and ranges. The dash
can also be included in the set as a character it if is the
beginning or end of the set. This set is enclosed in square
brackets. The close square bracket (]) may be used in a set if
it is the first character in the set. The fourth operation is
the same as the logical not of the third operation and is
specified the same way as the third with the addition of a
caret character (^) at the beginning of the test string just
inside the open square bracket. The final operation uses the
backslash character to invalidate the special meaning of the
open square bracket ([), the asterisk, backslash, or the
question mark. Two backslashes in sequence will result in the
evaluation of the backslash as a character with no special
meaning.
Implementers must be careful to apply the pattern-matching
operators to whole characters encoded in UTF-8, and not to
individual octets.
5.1 Negating the wildmat pattern
The exclamation point can be used at the beginning of a
wildmat to negate it. That is, if the remainder of the pattern
would match the string then the negated pattern does not, and
vice versa. If it appears as any other character other than
the first one, it has no special meaning.
Barber [Page 7]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
5.2 Examples
a) [^]-] -- matches any single character other than a
close square bracket or a minus sign/dash.
b) *bdc -- matches any string that ends with the string
"bdc" including the string "bdc" (without quotes).
c) [0-9a-zA-Z] -- matches any single printable
alphanumeric ASCII character.
d) a??d -- matches any four character string which
begins with a and ends with d.
e)!bc*d -- matches any string that does not start with
"bc" and end with "d" (without quotes)
f)!\\x -- matches any string that does not start with
"\x" (without quotes)
6. Format for Keyword Descriptions
On the following pages are descriptions of each keyword
recognized by the NNTP server and the responses that will be
returned by those commands. These keywords are grouped by the
functional step in which they are used.
Each keyword is shown in upper case for clarity, although the
NNTP server ignores case in the interpretation of commands.
Parameters are shown as follows:
. UPPERCASE indicates literal text to be included in the
command;
. lowercase indicates a token described elsewhere;
. [brackets] indicate that the parameter is optional;
. ellipsis... indicates that the parameter may be repeated
any number of times (it must occur at least once);
. vertical|bar indicates a choice of two mutually exclusive
parameters (exactly one must be provided).
Parameters are case or language specific only when specified
(either in this document or in RFC 1036[6]).
The name "wildmat" for a parameter indicates that it is a
wildmat format pattern as defined in section 5.
7. The GREETING Step
7.1 Initial Connection
There is no keyword 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
Barber [Page 8]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
response informs the client about what steps the client should
take to reach the news exchange step.
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 it 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. 502 MUST be used if
the client is not permitted under any circumstances to
interact with the server and 400 otherwise.
7.1.1 Initial Connection Example
Example of a normal connection from an authorized client
[Initial TCP connection setup completed.]
[C] Initial TCP connection completed
[S] 200 NNTP Service Ready, posting permitted
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of a normal connection from an unauthorized client
[C] Initial TCP connection completed
[S] 502 NNTP Service Unavailable
[Server closes connection.]
Example of a normal connection from an authorized client that
is not permitted to post
[Initial TCP connection setup completed.]
[S] 201 NNTP Service Ready, posting prohibited
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Barber [Page 9]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of a connection from any client where the server is
unable to provide service
[Initial TCP connection setup completed.]
[S] 400 NNTP Service temporarily unavailable
[Server closes connection.]
7.2 MODE READER
MODE READER
MODE READER SHOULD be sent by any client that intends to use
any command other than IHAVE, HEAD, STAT, LIST, LIST
EXTENSIONS, or commands advertised by the server as available
via LIST EXTENSIONS.
Servers MAY require that this command be issued before any
other commands are sent and MAY reject any other commands
until after a MODE READER command has been sent.
The server MUST present a response using the same codes as the
initial greeting (as described in section 7.1) to indicate its
ability to provide reading service to the client.
Clients SHOULD wait for a response to MODE READER after
sending this command and SHOULD NOT send any additional
commands until that response has been received from the
server.
Once MODE READER is sent, IHAVE (and any extensions intended
for peer-to-peer article transfer) MAY no longer be permitted,
even if it were permitted before the MODE READER command. The
results of LIST EXTENSIONS MAY be different following a
MODE READER command than prior to the issuing of that command.
Servers are encouraged to not require this command even though
clients SHOULD send it when appropriate. It is present to
support some news architectures that switch between modes
based on whether a given connection is a peer-to-peer
connection with another server or a news reading client.
7.2.1 Responses
200 Posting Permitted
201 Posting Not Permitted
400 Service temporarily unavailable
502 Service unavailable
Following a 400 or 502 response the server MUST immediately
close the connection.
Barber [Page 10]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Note that the response need not be the same as the one
presented during the initial greeting.
7.2.2 MODE READER Examples
Example of use of the MODE READER command by an authorized
client
[C] MODE READER
[S] 200 NNTP Service Ready, posting permitted
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of use of MODE READER by a client not authorized to
receive service from the server as a news reader
[C] MODE READER
[S] 502 Service Unavailable
[Server closes connection.]
Example of a normal connection from an authorized client that
is not permitted to post
[C] MODE READER
[S] 201 NNTP Service Ready, posting prohibited
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of a connection from any client where the server is
unable to provide news reader service
[C] MODE READER
[S] 400 NNTP Service temporarily unavailable
[Server closes connection.]
Barber [Page 11]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
8. The CAPABILITIES DISCOVERY Step
To discover what extensions are available, an NNTP client can
query the server with the LIST EXTENSIONS command.
If a particular extension is unavailable, the client can
attempt to work around it or it may wish to terminate the
session.
See section 12 for further discussion of extensions.
8.1 LIST EXTENSIONS
The LIST EXTENSIONS command allows a client to determine which
extensions are supported by the server.
To discover what extensions are available, an NNTP client
SHOULD query the server early in the session for extensions
information by issuing the LIST EXTENSIONS command. This
command MAY be issued at anytime during a session. It is not
required that the client issues this command before attempting
to make use of any extension. The response generated by this
command MAY change during a session because of other state
information. However, an NNTP client MUST NOT cache (for use
in another session) any information returned if the LIST
EXTENSIONS command succeeds. That is, an NNTP client is only
able to get the current and correct information concerning
available extensions during a session by issuing a LIST
EXTENSIONS command during that session and processing that
response.
A successful response starts with a 202 code and is followed
by a list of extensions, one per line. Each line MUST begin
with exactly one space followed by an extension-label and
optionally one or more parameters (separated by single
spaces). The extension-label and the meaning of the parameters
are specified as part of the definition of the extension. The
extension-label MUST be in uppercase.
The server MUST NOT list the same extension twice in the
response, and MUST list all supported extensions. The order in
which the extensions are listed is not significant. The server
need not even consistently return the same order.
If the server does not support any extensions, it SHOULD
return a 402 failure response but MAY return an empty list
instead.
Barber [Page 12]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
8.1.1 Responses
202 extension list follows (multiline)
400 service about to terminate
402 no extensions available
503 unable to list extensions
Following a 503 response an extension might still be
available, and the client MAY attempt to use it.
The LIST EXTENSIONS command is optional, and a server MAY
issue a 500 (unknown command) or 501 (syntax error) response
to it.
8.1.1.1 LIST EXTENSIONS Examples
Example of a successful response:
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] OVER
[S] PAT
[S] LISTGROUP
[S] .
The particular extensions shown here are simply examples of
what might be defined in other places, and no particular
meaning should be attributed to them.
Example where no extensions are available, using preferred
format:
[C] LIST EXTENSIONS
[S] 402 Server has no extensions
Example where no extensions are available, using an empty
list:
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] .
Barber [Page 13]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9. The NEWS EXCHANGE Step
During this step, two basic types of transactions occur:
. article retrieval from the server
. article posting to the server
9.1 Article Retrieval
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. One key is the message id
of an article. According to RFC 1036, this identifier should
be globally unique. Another key is composed of the newsgroup
name and the article number within that newsgroup. That key
MUST be unique to a particular server (there will be only one
article with that number within a particular newsgroup), but
is not required to be globally unique. Additionally, because
the same article can be cross-posted to multiple newsgroups,
there may be multiple keys that point to the same article on
the same server. The final 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 4,294,967,295
inclusive. The client and server SHOULD NOT use leading zeroes
in specifying article numbers, and MUST NOT use more than 16
digits. In some situations, the value zero replaces an article
number to show some special situation.
9.1.1 Article Retrieval by Newsgroup Name and Article Number
The following commands are used to set the current newsgroup
name and the "current article pointer" which is used by other
commands for article retrieval. At the start of an NNTP
session, both of these values are undefined.
9.1.1.1 GROUP
GROUP ggg
The required parameter ggg is the name of the newsgroup to be
selected (e.g. "news.software.b"). A list of valid newsgroups
Barber [Page 14]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
may be obtained by using the LIST keyword. See section 9.4
for more information on the LIST keyword.
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 on file in the
group.
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 on file. 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.
. 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.
. All three numbers will be zero.
. 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 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. That is:
. articles may be removed from the group
. 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)
. 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, the
next new article will not have the number one greater
than the reported high water mark)
Barber [Page 15]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
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 sent to any
client. 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 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
internally maintained "current article pointer" MUST be set to
the first article in the group and the name of the current
newsgroup MUST be set to the selected newsgroup name. If an
invalid group is specified, the previously selected group, if
any, and article MUST remain selected. If an empty newsgroup
is selected, the "current article pointer" is in an
indeterminate state and MUST NOT be used.
The GROUP keyword (or the LISTGROUP keyword, if implemented)
MUST be used by a client and a successful response received
before the any other command is used that depends on having
the "current article pointer" be valid.
9.1.1.1.1 Responses
211 n f l s group selected
(n = estimated number of articles in group, f = first
article number in the group, l = last article number
in the group, s = name of the group.)
411 no such newsgroup
9.1.1.1.2 GROUP Examples
Example for a group known to the server
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
Example for a group unknown to the server
[C] GROUP example.is.sob.bradner.or.barber
Barber [Page 16]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 411 example.is.sob.bradner.or.barber is unknown
9.1.1.2 LAST
LAST
If the current newsgroup is valid, the internally maintained
"current article pointer" MUST be set to the previous article
in the current newsgroup. If already positioned at the first
article of the newsgroup, an error message MUST be returned
and the current article MUST remain selected.
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 successful, a response indicating the current article
number and a message-id string MUST be returned. No article
text is sent in response to this command.
9.1.1.2.1 Responses
223 n a article retrieved - request text separately (n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group
9.1.1.2.2 LAST Examples
Example of a successful article retrieval using LAST
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] NEXT
[S] 223 3000237 <66...@domain.com> retrieved
[C] LAST
[S] 223 3000234 <45...@to.to> retrieved
Barber [Page 17]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of an attempt to retrieve an article without having
selected a group (via the GROUP command) first
[S] 200 NNTP Service ready
[C] LAST
[S] 412 no newsgroup selected
Example of an attempt to retrieve an article using the LAST
command when the current article pointer is pointing at the
first article in the group
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] LAST
[S] 422 No previous article to retrieve
Example of an attempt to retrieve an article using the LAST
command when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] LAST
[S] 420 No current article selected
9.1.1.3 NEXT
NEXT
If the current newsgroup is valid, the internally maintained
"current article pointer" MUST be advanced to the next article
in the current newsgroup. If no more articles remain in the
current group, an error message MUST be returned and the
current article MUST remain selected.
If successful, a response indicating the current article
number and the message-id string MUST be returned. No article
text is sent in response to this command.
9.1.1.3.1 Responses
Barber [Page 18]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
223 n a article retrieved - request text separately (n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group
9.1.1.3.2 NEXT Examples
Example of a successful article retrieval using NEXT
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] NEXT
[S] 223 3000237 <66...@domain.com> retrieved
Example of an attempt to retrieve an article without having
selected a group (via the GROUP command) first
[S] 200 NNTP Service ready
[C] NEXT
[S] 412 no newsgroup selected
Example of an attempt to retrieve an article using the NEXT
command when the current article pointer is pointing at the
last article in the group
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] ARTICLE 3002322
[S] 220 3002322 <41...@whitehouse.gov> retrieved
[S] Path: pathost!demo!whitehouse!not-for-mail
[S] From: nobody@whitehouse.gov(Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: The White House, Washington, DC
[S] Message-ID: <41...@whitehouse.gov>
Barber [Page 19]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S]
[S] This is just a test article.
[S] .
[C] NEXT
[S] 422 No next article to retrieve
Example of an attempt to retrieve an article using the NEXT
command when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] NEXT
[S] 420 No current article selected
9.2 Retrieval of Articles and Article Sections
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
commands are described in terms of the differences.
An article, as defined by RFC 1036, consists of two parts: the
article headers and the article body. When responding to one
of these commands, the server presents the entire article or
appropriate part and does not attempt to alter or translate it
in any way.
9.2.1 ARTICLE
ARTICLE <message-id>
ARTICLE [number]
The ARTICLE command selects an article based on the arguments
and presents the header, a blank line, and the body of that
article. The command has two forms.
In the first form, a message-id is specified (including the
angle brackets), and the server presents the article with that
message-id in its headers. In this case, the server MUST NOT
alter the "current article pointer". This is both to
Barber [Page 20]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
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 which may have been posted to more than one
newsgroup.
In the second form, an article number may be specified. If so,
and if there is an article with that number in the currently
selected group, the server MUST set the current article
pointer to that number.
Then, whether or not a number was specified, the article
indicated by the current article pointer is presented to the
client.
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 such an article number MUST be no less than the reported
low water mark for that group.
The server MUST NOT change the currently selected group as a
result of this command. The server MUST NOT change the current
selected article except when an article number argument was
provided and the article exists; in particular, it MUST NOT
change it following an unsuccessful response.
9.2.1.1 Responses
First form (message-id specified):
220 0 a article retrieved and follows (multiline, a =
unique article id)
430 no such article
502 service unavailable
Second form (optional article number specified):
220 n a article retrieved and follows (multiline, n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
The 420 response only occurs if no article number has been
specified.
In the 220 response, the first parameter is 0 for the first
form and the article number (within the current group) for the
Barber [Page 21]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
second form. The second parameter is the message-id of the
article (within angle brackets). This is taken from the
message-id header line of the article (required by RFC 1036).
If there is no such line, the message-id "<0>" MUST be used
instead (without the double quotes).
Since the message-id field 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 headers and body are returned as a multiline
response following the initial response line.
9.2.1.2 Examples
Example of a successful retrieval of an article (using no
article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] ARTICLE
[S] 220 3000234 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S]
[S] This is just a test article.
[S] .
Example of a successful retrieval of an article by message-id
[S] 200 NNTP Service Ready
[C] ARTICLE <45...@to.to>
[S] 220 0 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
Barber [Page 22]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S]
[S] This is just a test article.
[S] .
Example of an unsuccessful retrieval of an article by message-
id
[S] 200 NNTP Service Ready
[C] ARTICLE <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of an article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 news.groups
[C] ARTICLE 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval of an article by number
because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] ARTICLE 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] ARTICLE
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] ARTICLE <i....@nowhere.to>
Barber [Page 23]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 502 Service unavailable
9.2.2 HEAD
HEAD <message-id>
HEAD [number]
The HEAD command behaves identically to the ARTICLE command
except that, if the article exists, only the headers are
presented (the blank line separating the headers and body MUST
NOT be included).
9.2.2.1 Responses
First form (message-id specified):
221 0 a article retrieved, headers follow (multiline)
430 no such article
502 service unavailable
Second form (optional article number specified):
221 n a article retrieved, headers follow (multiline)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Except that only the headers are included in the response, the
221 response behaves identically to the 220 response of the
ARTICLE command.
9.2.2.2 Examples
Example of a successful retrieval of the headers in an article
(using no article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HEAD
[S] 220 3000234 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
Barber [Page 24]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S] .
Example of a successful retrieval of the headers in an article
by message-id
[S] 200 NNTP Service Ready
[C] HEAD <45...@to.to>
[S] 220 0 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S] .
Example of an unsuccessful retrieval of the header of an
article by message-id
[S] 200 NNTP Service Ready
[C] HEAD <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of the header of an
article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HEAD 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval the header of an article
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
Barber [Page 25]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] HEAD 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve the header of an article
when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] HEAD
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] HEAD <i....@nowhere.to>
[S] 502 Service unavailable
9.2.3 BODY
BODY <message-id>
BODY [number]
The BODY command behaves identically to the ARTICLE command
except that, if the article exists, only the body is presented
(the blank line separating the headers and body MUST NOT be
included).
9.2.3.1 Responses
First form (message-id specified):
222 0 a article retrieved, body follows (multiline)
430 no such article
502 service unavailable
Second form (optional article number specified):
222 n a article retrieved, body follows (multiline)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Barber [Page 26]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Except that only the body is included in the response, the 222
response behaves identically to the 220 response of the
ARTICLE command.
9.2.3.2 Examples
Example of a successful retrieval of the body of an article
(using no article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] BODY
[S] 222 3000234 <45...@to.to>
[S] This is just a test article.
[S] .
Example of a successful retrieval of the body of an article by
message-id
[S] 200 NNTP Service Ready
[C] BODY <45...@to.to>
[S] 222 0 <45...@to.to>
[S] This is just a test article.
[S] .
Example of an unsuccessful retrieval of the body of an article
by message-id
[S] 200 NNTP Service Ready
[C] BODY <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of the body of an article
by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] BODY 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval of the body of an article
by number because no newsgroup was selected first
Barber [Page 27]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 200 NNTP Service Ready
[C] BODY 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve the body of an article when
the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] BODY
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] BODY <i....@nowhere.to>
[S] 502 Service unavailable
9.2.4 STAT
STAT <message-id>
STAT [number]
The STAT command behaves identically to the ARTICLE command
except that, if the article exists, it is NOT presented to the
client.
This command allows the client to determine whether an article
exists, and in the second form what its message-id is, without
having to process an arbitrary amount of text.
9.2.4.1 Responses
First form (message-id specified):
223 0 a article exists
430 no such article
502 service unavailable
Second form (optional article number specified):
223 n a article exists
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Barber [Page 28]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
The parameters of the 223 response are identical to those that
would have been given in a 220 response to the equivalent
ARTICLE command. However, the response is NOT multiline.
9.2.4.2 Examples
Example of STAT on an existing article (using no article
number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT
[S] 223 3000234 <45...@to.to>
Example of a STAT of an existing article by message-id
[S] 200 NNTP Service Ready
[C] STAT <45...@to.to>
[S] 223 0 <45...@to.to>
Example of an STAT of an article not on the server by message-
id
[S] 200 NNTP Service Ready
[C] STAT <i....@nowhere.to>
[S] 430 No Such Article Found
Example of STAT of an article not in the server by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT 300256
[S] 423 No such article number in this group
Example of STAT of an article by number when no newsgroup was
selected first
[S] 200 NNTP Service Ready
[C] STAT 300256
[S] 412 No newsgroup selected
Barber [Page 29]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of STAT of an article when the current group selected
is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] STAT
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] STAT <i....@nowhere.to>
[S] 502 Service unavailable
9.3 Article Posting
Article posting is done in one of two modes: individual
article posting from news reading clients and article transfer
from other news servers.
9.3.1 POST
POST
If posting is allowed, response code 340 MUST be returned to
indicate that the article to be posted should be sent.
Response code 440 MUST be sent if that posting is prohibited
for some installation-dependent reason.
If posting is permitted, the article MUST be presented to the
server by the client in the format specified by RFC 1036. The
text forming the header and body of the message to be posted
MUST be sent by the client using the conventions for text
received from the news server: A single period (".") on a line
indicates the end of the text, with lines starting with a
period in the original text having that period doubled during
transmission.
Following the presentation of the termination sequence by the
client, the server MUST return a response code indicating
success or failure of the article transfer. Note that response
codes 340 and 440 are used in direct response to the POST
command. Others are returned following the sending of the
article.
Barber [Page 30]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
No attempt shall be made by the server to filter characters,
fold or limit lines, or otherwise process incoming text. The
intent is that the server just passes the incoming message to
be posted to the server installation's news posting software,
which is not part of this specification.
9.3.1.1 Responses
240 article received ok
340 send article to be posted. End with <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
9.3.1.2 Examples
Example of a successful posting
[S] 200 NNTP Service Ready
[C] POST
[S] 340 Input article. End with <CR-LF>.<CR-LF>
[C] From: demo@testdomain.com(Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: Testdomain, USA
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received ok
Example of an unsuccessful posting
[S] 200 NNTP Service Ready
[C] POST
[S] 340 Input article. End with <CR-LF>.<CR-LF>
[C] From: demo@testdomain.com(Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: Testdomain, USA
[C]
Barber [Page 31]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] This is just a test article.
[C] .
[S] 441 Posting failed
Example of an attempt to posting when posting is not allowed
[S] 201 NNTP Service Ready, read-only
[C] POST
[S] 440 Posting not permitted
9.3.2 IHAVE
IHAVE <message-id>
The IHAVE command informs the server that the client has an
article whose id is <message-id>. If the server desires a copy
of that article, it MUST return a response 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 response indicating that the article is not wanted MUST
be returned.
If transmission of the article is requested, the client MUST
send the entire article, including header and body, in the
manner specified for text transmission from the server. The
server MUST return a response code indicating success or
failure of the transferal of the article.
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. In particular, this function
will invoke the server's news posting program with the
appropriate settings (flags, options, etc.) to indicate that
the forthcoming article is being forwarded from another host.
However, 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 such problems as
inappropriate newsgroups or distributions, disk space
limitations, article lengths, garbled headers, and the like.
These are typically restrictions enforced by the server host's
news software and not necessarily the NNTP server itself.
9.3.2.1 Responses
Barber [Page 32]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
235 article transferred ok
335 send article to be transferred. End with <CR-
LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
Because some host news posting software may not be able to
immediately render status on the whether an article is
inappropriate for posting or forwarding, an NNTP server MAY
acknowledge the successful transfer of the article and later
silently discard it. Thus, an NNTP server MAY return the 235
acknowledgment code and later discard the received article.
9.3.2.2 Examples
Example of successfully sending an article to another site
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 235 Article transferred ok
Example of sending an article to another site that rejects it
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
Barber [Page 33]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 437 Article rejected. Don't send again
Example of sending an article to another site where the
transfer fails
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 436 Transfer failed
Example of sending an article to another site that rejects it
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
Barber [Page 34]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 435 Don't send it again
9.4 The LIST Keyword
9.4.1 LIST
LIST [ACTIVE [wildmat]]
The response to the LIST keyword with no parameters returns a
list of valid newsgroups and associated information. Each
newsgroup is sent as a line of text in the following format:
group first last status
where <group> is the name of the newsgroup, <last> is the
number of the last known article currently in that newsgroup,
<first> is the number of the first article currently in the
newsgroup, and <status> indicates the current status of the
group on this server. Typically, the <status> will be consist
of the US-ASCII character 'y' where posting is permitted, 'n'
where posting is not permitted and 'm' where postings will be
forwarded to the newsgroup moderator by the news server. Other
status strings may exist. The definition of these other values
and the circumstances under which they are returned is covered
in other specifications.
The <first> and <last> fields will always be numeric. They
may have leading zeros. The <first> field corresponds to the
"reported low water mark" and the <last> field corresponds to
the "reported high water mark" described in the GROUP command
(see Section 9.1.1.1).
The status of a newsgroup only indicates how posts to that
newsgroup are processed. It does not indicate if the current
client is permitted to post. That is indicated by the status
code returned as part of the greeting.
Barber [Page 35]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Please note that an empty list (i.e., the text body returned
by this command consists only of the terminating period) is a
possible valid response, and indicates that there are
currently no valid newsgroups.
If the optional wildmat parameter is specified, the list is
limited to only the groups that match the pattern.
Specifying a single group is usually very efficient for the
server. Multiple groups may be specified by using wildmat
patterns (described in section 5).
9.4.1.1 Responses
215 list of newsgroups follows
9.4.1.2 Examples
Example of LIST returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST
[S] 215 list of newsgroups follows
[S] misc.test 3000234 3002322 y
[S] alt.fc-writers.recovery 1 4 y
[S] tx.natives.recovery 56 89 y
[S] .
Example of LIST returning no newsgroups
[S] 200 NNTP Service Ready
[C] LIST
[S] 215 list of newsgroups follows
[S] .
9.4.2 LIST ACTIVE.TIMES
LIST ACTIVE.TIMES [wildmat]
The active.times file is maintained by some news transport
systems to contain information about who created a particular
newsgroup and when. The format of this file includes three
fields. 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 the email address of the entity that created the
newsgroup. When executed, the information is displayed
Barber [Page 36]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
following the 215 response. When display is completed, the
server will send a period on a line by itself. If the
information is not available, the server will return the 503
error response. If the server does not recognize the command,
it SHOULD return the 501 error response.
If the optional wildmat parameter is specified, the list is
limited to only the groups that match the pattern.
Specifying a single group is usually very efficient for the
server. Multiple groups may be specified by using wildmat
patterns (described in section 5).
9.4.2.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.2.2 Examples
Example of LIST ACTIVE.TIMES returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST ACTIVE.TIMES
[S] 215 information follows
[S] misc.test 930445408 <cr...@isc.org>
[S] alt.rfc-writers.recovery 930562309 <m...@nowhere.to>
[S] tx.natives.recovery 930678923 <so...@academ.com>
[S] .
Example of LIST ACTIVE.TIMES returning an error (The server
software is not configured to maintain this information, but
does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST ACTIVE.TIMES
[S] 503 program error, function not performed
Example of LIST ACTIVE.TIMES sent to a server that does not
recognize this argument (e.g. The software does not maintain
this information.)
[S] 200 NNTP Service Ready
Barber [Page 37]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] LIST ACTIVE.TIMES
[S] 501 Syntax Error
9.4.3 LIST DISTRIBUTIONS
LIST DISTRIBUTIONS
The distributions file is maintained by some news transport
systems to contain information about valid values for the
Distribution: line in a news article header and about what the
values mean. Each line contains two fields, the value and a
short explanation on the meaning of the value. When executed,
the information is displayed following the 215 response. When
display is completed, the server will send a period on a line
by itself. If the information is not available, the server
will return the 503 error response. If the server does not
recognize this command, it SHOULD return the 501 error
response.
9.4.3.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.3.2 Examples
Example of LIST DISTRIBUTIONS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 215 information follows
[S] usa United States of America
[S] na North America
[S] world All over the World
[S] .
Example of LIST DISTRIBUTIONS returning an error (e.g. The
server software is not configured to maintain this
information, but does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 503 program error, function not performed
Barber [Page 38]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of LIST DISTRIBUTIONS sent to a server that does not
recognize the command (e.g. The server does not maintain this
information regardless of configuration.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 501 Syntax Error
9.4.4 LIST DISTRIB.PATS
LIST DISTRIB.PATS
The distrib.pats file is maintained by some news transport
systems to allow clients to choose a value for the
Distribution: line in the header of a news article being
posted. The information returned consists of lines, in no
particular order, each of which contains three fields
separated by colons. These fields are a weight, a group name
or wildmat pattern, and a Distribution: value, in that order.
The client MAY use this information to select a Distribution:
value based on the name of a newsgroup. To do so, it should
determine the lines whose second field matches the newsgroup
name, select that line with the highest weight (with 0 being
the lowest), and use the Distribution: field from that line.
When executed, the information is displayed following the 215
response. When display is completed, the server will send a
period on a line by itself. If the information is not
available, the server will return the 503 error response. If
this command is not recognized, the server SHOULD return the
501 error response.
9.4.4.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.4.2 Examples
Example of LIST DISTRIB.PATS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 215 information follows
[S] 10:local.*:local
Barber [Page 39]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] .
Example of LIST DISTRIB.PATS returning an error (e.g. The
server software is not configured to maintain this
information, but does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 503 program error, function not performed
Example of LIST DISTRIB.PATS sent to a server that does not
recognize the command (e.g. The software does not maintain
this information regardless of configuration.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 501 Syntax Error
9.4.5 LIST NEWSGROUPS
LIST NEWSGROUPS [wildmat]
The newsgroups file is maintained by some news transport
systems to contain the name of each newsgroup that is
active on the server and a short description about the
purpose of each newsgroup. Each line in the file contains
two fields, the newsgroup name and a short explanation of
the purpose of that newsgroup. When executed, the
information is displayed following the 215 response. When
display is completed, the server will send a period on a
line by itself. If the information is not available, the
server will return the 503 response. If the server does not
recognize the command it should return a 501 response. If
the optional matching parameter is specified, the list is
limited to only the groups that match the pattern (no
matching is done on the group descriptions). Specifying a
single group is usually very efficient for the server, and
multiple groups may be specified by using a wildmat(see
section 5), not regular expressions. If nothing is matched
an empty list is returned, not an error.
9.4.5.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
Barber [Page 40]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9.4.5.2 Examples
Example of LIST NEWSGROUPS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] 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] .
Example of LIST NEWSGROUPS returning an error (e.g. The server
software recognizes the command as valid, but the information
is not available.)
[S] 200 NNTP Service Ready
[C] LIST NEWSGROUPS
[S] 503 program error, function not performed
9.5 Standard extensions
Each of the following sections describes an extension that a
server MAY provide. If the server provides the extension, it
MUST include the appropriate extension label in the response
to LIST EXTENSIONS. If it does not provide it, it MUST NOT
include the appropriate extension label. The descriptions of
facilities in each section are written as if the extension is
provided. If it is not provided, the entire section should be
ignored.
9.5.1 LISTGROUP extension
This extension provides one command and has the extension
label LISTGROUP.
9.5.1.1 The LISTGROUP Command
LISTGROUP [ggg]
The LISTGROUP command is used to get a listing of all the
article numbers in a particular newsgroup.
Barber [Page 41]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
The optional parameter ggg is the name of the newsgroup to
be selected (e.g. "news.software.b"). A list of valid
newsgroups may be obtained from the LIST command. If no
group is specified, the current group is used as the
default argument.
The successful selection response will be a list of the
article numbers in the group followed by a period on a line
by itself. The list starts on the next line following the
211 response code.
When a valid group is selected by means of this command,
the internally maintained "current article pointer" MUST be
set to the first article in the group and the name of the
current newsgroup MUST be set to the selected newsgroup
name. If an invalid group is specified, the previously
selected group and article remain selected. If an empty
newsgroup is selected, the "current article pointer" may be
in an indeterminate state and should not be used.
The LISTGROUP keyword MAY be used by a client as a
replacement for the GROUP command in establishing a valid
"current article pointer." After a successful response is
received, any other command may be used that depends on
having the "current article pointer" be valid.
The group name MUST match a newsgroup obtained from the
LIST command or an error will result, else the server will
respond with the 411 error code.
A server that does not implement this command SHOULD return
a 500 error response.
9.5.1.1.1 Responses
211 list of article numbers follow
411 No such group
412 Not currently in newsgroup
500 Command not recognized
9.5.1.1.2 Examples
Example of a successful execution with a group that exists on
the server
[S] 200 NNTP Service Ready
[C] LISTGROUP misc.test
[S] 211 list of article numbers follow
Barber [Page 42]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 3000234
[S] 3000237
[S] 3000238
[S] 3000239
[S] 3002322
[S] .
Example of an unsuccessful execution with a group that does
not exist on the server
[S] 200 NNTP Service Ready
[C] LISTGROUP this.group.is.not.here
[S] 411 no such group
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] LISTGROUP example.empty.newsgroup
[S] 412 No current article selected
9.5.2 The OVER Extension
This extension provides two commands, OVER and LIST
OVERVIEW.FMT. The label for this extension is OVER.
9.5.2.1 LIST OVERVIEW.FMT
LIST OVERVIEW.FMT
The overview.fmt file is maintained by some news transport
systems to contain the order in which header information is
stored in the overview databases for each newsgroup. When
executed, news article header fields are displayed one line at
a time in the order in which they are stored in the overview
database[6] following the 215 response. When display is
completed, the server will send a period on a line by itself.
If the information is not available, the server will return
the 503 response.
If the header has the word "full" (without quotes) after the
colon, the header's name is prepended to its field in the
output returned by the server.
This is command is part of the optional OVER extension which
includes the OVER command defined in section . If the OVER
Barber [Page 43]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
extension is not implemented, then this command MUST NOT be
implemented. If that case, the server MUST return a 501 error
response when this command is presented by the client.
9.5.2.1.1 Responses
215 information follows
501 Syntax Error
503 program error, function not performed
9.5.2.1.2 Examples
Example of LIST OVERVIEW.FMT returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST OVERVIEW.FMT
[S] 215 Order of fields in overview database.
[S] Subject:
[S] From:
[S] Date:
[S] Message-ID:
[S] .
Example of LIST OVERVIEW.FMT returning an error
[S] 200 NNTP Service Ready
[C] LIST OVERVIEW.FMT
[S] 503 program error, function not performed
9.5.2.2 OVER
OVER [range]
The OVER command returns specific header information for the
article(s) specified from the current selected group. The
information returned in the response to this command can be
used by clients to follow discussion threads.
The optional range argument may be any of the following:
. an article number
. an article number followed by a dash to indicate all
following
Barber [Page 44]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
. an article number followed by a dash followed by another
article number
If no argument is specified, then information from the current
article is displayed. Successful responses start with a 224
response followed by the overview information for all matched
messages. Once the output is complete, a period is sent on a
line by itself. If no argument is specified, the information
for the current article is returned. A newsgroup must have
been selected earlier, else a 412 error response is returned.
If no articles are in the range specified, the server returns
a 420 error response. A 502 response will be returned if the
client only has permission to transfer articles. A 500
response SHOULD be returned by servers do not implement this
command.
The output consists of one line per article, sorted in
numerical order of article number. Each line consists of a
number of fields separated by an US-ASCII TAB character. The
first 8 fields MUST be the following, in order:
article number, subject, author, date, message-ID, references,
byte count, line count
The content of any subsequent field is given by the response
to the LIST OVERVIEW.FMT command. A field may be empty (in
which case there will be two adjacent US-ASCII tabs, and a
sequence of trailing US-ASCII tabs may be omitted). Any
sequence of US-ASCII space or non-printing characters in a
field MUST be replaced by a single US-ASCII space.
The server SHOULD not produce output for articles that no
longer exist.
9.5.2.2.1 Responses
224 Overview information follows
412 No newsgroup current selected
420 No article(s) selected
500 Command not recognized
502 Service Unavailable
9.5.2.2.2 Examples
Example of a successful retrieval of overview information for
an article (using no article number)
[S] 200 NNTP Service Ready
Barber [Page 45]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER
[S] 224 Overview information follows
300234|I am just a test article|nobody@nowhere.to
(Demo User)|6 Oct 1998 04:38:40 -0500|
<45...@to.to>
[S] .
[Please note that the line that begins with 300234 is all one
line that has been wrapped for readability. A vertical bar has
been inserted to show where the US-ASCII TAB should actually
be.]
Example of an unsuccessful retrieval of overview information
on an article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER 300256
[S] 420 No such article in this group
Example of an unsuccessful retrieval of overview information
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] OVER
[S] 412 No newsgroup selected
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] OVER
[S] 420 No current article selected
9.5.3 The HDR Extension
This extension provides one new command, HDR. The label for
this extension is PAT.
Barber [Page 46]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9.5.3.1 HDR
HDR range|<message-id>
The HDR command is used to retrieve specific headers from
specific articles in the currently selected group.
The required header parameter is the name of a header line
(e.g. "subject") in a newsgroup article. See RFC-1036 for a
list of valid header lines. The required range argument may be
any of the following:
. an article number
. an article number followed by a dash to indicate all
following
. an article number followed by a dash followed by another
article number.
The required message-id argument indicates a specific article.
The range and message-id arguments are mutually exclusive.
A successful response consists of a 221 code followed by the
output from the command. The output consists of one line for
each article where the relevant header line exists. The line
consists of the article number, a US-ASCII space, and then the
contents of the header (without the header name). A valid
response includes an empty list (indicating that there were no
matches). Once the output is complete, a period is sent on a
line by itself. If the optional argument is a message-id and
no such article exists, a 430 error response shall be
returned. A 502 response shall be returned if the client only
has permission to transfer articles. A 500 response SHOULD be
issued by all servers that do not recognize this command.
9.5.3.1.1 Responses
221 Header follows
412 no newsgroup selected
430 no such article
500 Command not recognized
502 Service Unavailable
9.5.3.1.2 Examples
Example of a successful retrieval of subject lines from a
range of articles
Barber [Page 47]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238
[S] 221 Header Follows
[S] 3000234 I am just a test article
[S] 3000237 Re: I am just a test article
[S] 3000238 Ditto
[S] .
Example of a successful retrieval of header from an article by
message-id
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR subject <i....@nowhere.to>
[S] 221 Header information follows
[S] 3000345 I am just a test article
[S] .
Example of an unsuccessful retrieval of a header from an
article by message-id
[S] 200 NNTP Service Ready
[C] HDR subject <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of headers from articles
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] HDR subject 300256-
[S] 412 No newsgroup selected
Example of an unsuccessful retrieval of headers from articles
by message-id because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] HDR subject <i....@nowhere.to>
[S] 412 No newsgroup selected
Barber [Page 48]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of retrieving header information when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] HDR subject 0-
[S] 221 Headers follow
.
Example of a failure due to restrictions configured into the
server
[S] 200 NNTP Service Ready
[C] GROUP news.group
[S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238
[S] 502 Service Unavailable
10. The CONCLUSION Step
10.1 QUIT
QUIT
The server process 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 its
transactions with the NNTP server.
If a client simply disconnects (or 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.
10.1.1 Responses
205 closing connection - goodbye!
10.1.2 Example
[S] 200 NNTP Service Ready
[C] QUIT
[S] 205 closing connection
Barber [Page 49]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[Server closes connection.]
11. Other Keywords
There are other keywords that may be used at any time between
the beginning of a session and its termination. Using these
keywords does not alter any state information, but the
response generated from the use of these keywords may provide
useful information to clients that use them.
11.1 DATE
DATE
This command exists to help clients find out the current
Coordinated Universal Time[7] from the server's perspective.
This command SHOULD NOT be used as a substitute for NTP[8],
but to provide information that might be useful when using the
NEWNEWS command (see section 11.4). A system providing NNTP
service SHOULD implement NTP for the purposes of keeping the
system clock as accurate as possible.
This command returns a one-line response code of 111 followed
by the date and time on the server in the form YYYYMMDDhhmmss.
11.1.1 Responses
111 YYYYMMDDhhmmss
11.1.2 Example
[S] 200 NNTP Service Ready
[C] DATE
[S] 111 19990623135624
11.2 The HELP Command
HELP
This command provides a short summary of commands that are
understood by this implementation of the server. The help text
will be presented as a textual response terminated by a single
period on a line by itself.
This text is not guaranteed to be in any particular format and
SHALL NOT be used by clients as a replacement for the LIST
EXTENSIONS command described in section 8.1.
Barber [Page 50]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
11.2.1 Responses
100 help text follows
11.2.2 Example
[S] 200 NNTP Service Ready
[C] 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] .
11.3 NEWGROUPS
NEWGROUPS date time [GMT]
A list of newsgroups created since <date and time> MUST be
listed in the same format as the LIST command.
The date is sent as 6 or 8 digits in the format [XX]YYMMDD,
where XX is the first two digits of the year, YY is the last
two digits of the year, MM is the two digits of the month
(with leading zero, if appropriate), and DD is the day of the
month (with leading zero, if appropriate). If the first two
digits of the year are not specified, the year is to be taken
from the current century if YY is smaller than or equal to the
current year, otherwise the year is from the previous century.
Time must also be specified. It must be as 6 digits HHMMSS
with HH being hours in the 24-hour clock 00-23, MM minutes 00-
59, and SS seconds 00-60, which allows for leap seconds. The
token "GMT" specifies that the date and time are given in
Coordinated Universal Time. If the token "GMT" is omitted then
the date and time are specified in the server's local
timezone. Note that there is no way within this specification
of NNTP to establish the server's local timezone.
Note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible
valid response, and indicates that there are currently no new
newsgroups.
Barber [Page 51]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Clients SHOULD make all queries using Coordinated Universal
Time when possible.
11.3.1 Responses
231 list of new newsgroups follows
11.3.2 Examples
Example where there are new groups
[S] 200 NNTP Service Ready
[C] NEWGROUPS 19990624 000000 GMT
[S] 230 list of new newsgroups follows
[S] alt.rfc-writers.recovery
[S] tx.natives.recovery
[S] .
Example where there are no new groups
[S] 200 NNTP Service Ready
[C] NEWGROUPS 19990624 000000 GMT
[S] 230 list of new newsgroups follows
[S] .
11.4 NEWNEWS
NEWNEWS newsgroups date time [GMT]
A list of message-ids of articles posted or received to the
specified newsgroup or groups since "date" will be listed. The
format of the listing will be one message-id per line, as
though text were being sent. Each message-id SHALL appear only
once in a response. The order of the response has no specific
significance and may vary from response to response in the
same session. A single line consisting solely of one period
followed by CR-LF will terminate the list.
Date and time are in the same format as the NEWGROUPS command.
The newsgroups parameter MUST be in wildmat format and MAY
consist of multiple wildmat constructs separated by an US-
ASCII comma character.
Note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible
valid response, and indicates that there is currently no new
news.
Barber [Page 52]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Clients SHOULD make all queries in Coordinated Universal Time
when possible.
11.4.1 Responses
230 list of new articles by message-id follows
11.4.2 Examples
Example where there are new articles
[S] 200 NNTP Service Ready
[C] NEWNEWS news.*,sci.* 19990624 000000
[S] 230 list of new articles by message-id follows
[S] <i....@nowhere.to>
[S] <i....@nowhere.to>
Example where there are no new articles
[S] 200 NNTP Service Ready
[C] NEWNEWS alt.* 19990624 000000
[S] 230 list of new articles by message-id follows
[S] .
12. Framework for NNTP Extensions
Although NNTP is widely and robustly deployed, some parts of
the Internet community might wish to extend the NNTP service.
This memo defines a means whereby an extended NNTP client may
query the server to determine the service extensions that it
supports.
It must be emphasized that any extension to the NNTP service
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.
Barber [Page 53]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Given this environment, the framework for the extensions
described in this memo consists of:
a)a mechanism for clients to determine a server's available
extensions
b)a registry of NNTP service extensions
The LIST EXTENSIONS command is described in section 8.1 of
this memo and is the mechanism for clients to use to determine
what extensions are available for client use.
The IANA shall maintain a registry of NNTP service extensions.
An extension is identified by a unique extension-label, which
is a string of 1 to 12 uppercase letters. The extension-label
will often be the name of a new command that the extension
adds. However this is not a requirement: an extension might
not add any new commands or keywords.
An extension is either a private extension or else it is
included in the IANA registry and is defined in an RFC. Such
RFCs either must be on the standards-track or must define an
IESG-approved experimental protocol.
The definition of an extension must include:
. a descriptive name for the extension
. the extension-label (which is returned by LIST EXTENSIONS
to indicate to the client that the server supports this
particular extension)
. the syntax, values, and meanings of any parameters
following the extension-label in the output of LIST
EXTENSIONS
. any new NNTP keywords associated with the extension
. the syntax and possible values of parameters associated
with the new NNTP keywords
. any new parameters the extension associates with any
other pre-existing NNTP keywords
. how support for the extension affects the behavior of a
server and NNTP client
. any increase in the maximum length of commands over the
value specified in this memo
The extension-label of private extensions MUST begin with "X".
The extension-label of registered extensions MUST NOT begin
with "X".
Any keyword values presented in the NNTP response that do not
begin with "X" MUST correspond to a standard, standards-track,
Barber [Page 54]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
or IESG-approved experimental NNTP service extension
registered with IANA. A conforming server MUST NOT offer non
"X" prefixed keyword values that are not described in a
registered extension.
Except where stated otherwise, the commands in this document
are understood (even if not supported) by all servers and are
not described in the list of features returned by the LIST
EXTENSIONS command.
A server MAY provide additional keywords - either new commands
or new parameters to existing commands - as part of a private
extension. These new keywords MUST begin with "X".
A server MUST NOT send different response codes to basic NNTP
commands documented here or commands documented in registered
extensions in response to the availability or use of a private
extension.
12.1 Initial IANA Registry
The IANA's initial registry of NNTP service extensions
consists of these entries:
Service Extension NNTP Extension Label Added Behavior
Overview Support OVER Defined in this
document
Specific Article LISTGROUP Defined in this
Numbers document
Header Pattern HDR Defined in this
Matching document
13. Augmented BNF[9] Syntax for NNTP Commands
This syntax defines the non-terminal "command". The non-terminal
"parameter" is used for command parameters whose syntax is
specified elsewhere. The syntax is in alphabetical order. Note
that ABNF strings are case insensitive.
article-command = "ARTICLE" [1*WSP (msg-id / article-number)]
*WSP CRLF
article-number = 1*16DIGIT
argument = parameter ; excluding sequence ".."
body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP
CRLF
command = article-command /
body-command /
Barber [Page 55]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
date-command /
group-command /
head-command /
help-command /
ihave-command /
last-command /
list-active-times-command /
list-distrib-pats-command /
list-distributions-command /
list-extensions-command /
list-newsgroups-command /
list-overview-fmt-command /
list-command /
listgroup-command /
mode-reader-command /
newgroups-command /
newnews-command /
next-command /
over-command /
hdr-command /
post-command /
quit-command /
stat-command
CR = %x0D
CRLF = CR LF
date-command = "DATE" *WSP CRLF
date = 6*8DIGIT
DIGIT = %x30-39
group-command = "GROUP" 1*WSP newsgroup *WSP CRLF
hdr-command = "PAT" 1*WSP header 1*WSP (range / msg-id) *WSP
CRLF
head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP
CRLF
header = parameter
help-command = "HELP" *WSP CRLF
HT = %x09
ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF
last-command = "LAST" *WSP CRLF
LF = %x0A
list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES"
[1*WSP wildmat] *WSP CRLF
list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP
CRLF
list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP
CRLF
list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP
CRLF
Barber [Page 56]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF
list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP
wildmat]
*WSP CRLF
list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP
CRLF
listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF
mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF
msg-id = <defined in RFC822>
newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP
"GMT"] *WSP CRLF
newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup)
1*WSP date 1*WSP time [1*WSP "GMT"]
*WSP CRLF
newsgroup = parameter
next-command = "NEXT" *WSP CRLF
over-command = "OVER" [1*WSP range] *WSP CRLF
parameter = 1*(%x21-FF) ; generic command parameter
post-command = "POST" *WSP CRLF
quit-command = "QUIT" *WSP CRLF
range = article-number ["-" [article-number]]
SP = %x20
stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP
CRLF
time = 6DIGIT
UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
wildmat = ["!"]1*("*" / "?" / wildmat-exact / wildmat-set /
"\" (%x22-7F / UTF-8-non-ascii))
wildmat-exact = %x22-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8-
non-ascii ; exclude space ! * ? [ \
wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ;
exclude space -
wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen"["-"
wildmat-non-hyphen]) ["-"]
WSP = SP / HT
14. Security Considerations
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
Barber [Page 57]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
include definitive solutions to the problems revealed, though
it does make some suggestions for reducing security risks.
14.1 Personal and Proprietary Information
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 personal and/or
proprietary information is not disclosed inadvertently.
Additionally, effective and easily understood mechanisms to
manage the distribution of news articles must be provided to
NNTP Server administrators, so that they are able to report
with confidence what information is and is not being forwarded
in news articles passing though their servers.
14.2 Abuse of Server Log Information
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 the NNTP 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.
14.3 DNS Spoofing
Clients and Servers using NNTP rely heavily on the Domain Name
Service, and are thus 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 caching 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.
Barber [Page 58]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
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 grow. Observing this requirement thus reduces this
potential security vulnerability.
This requirement also improves the load-balancing behavior 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.
14.4 Weak Authentication and Access Control
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 the
NNTP protocol itself for such purposes. 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.
15. References
[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol",
RFC-977, U.C. San Diego and U.C. Berkeley.
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, Alis Technologies.
[3] Coded Character Set-7-bit American Standard Code for
Information Interchange, ANSI x3.4-1986.
[4]Bradner, Scott, "Keywords for use in RFCs to Indicate
Requirement Levels", RFC-2119, Harvard University.
[5] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
distribution, UUNET Technologies, Revision 1.10, April, 1992.
[6] Robertson, Rob, "FAQ: Overview database / NOV General
Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
nov.Z, January, 1995.
[7] International Telecommunications Union-Radio, "Glossary",
ITU-R Recommendation TF.686-1, October, 1997.
[8] Mills, David L., "Network Time Protocol (Version 3),
Specification, Implementation and Analysis", RFC-1305,
University of Delaware, March 1992.
Barber [Page 59]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[9] Crocker, D. and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC-2234, Internet Mail Consortium and
Demon Internet, Ltd.
16. Notes
UNIX is a registered trademark of the X/Open Consortium.
17. Acknowledgments
The author acknowledges the original authors of NNTP as
documented in RFC 977: Brian Kantor and Phil Lapsey.
The author gratefully acknowledges the work of the NNTP
committee chaired by Eliot Lear. The organization of this
document was influenced by the last available draft from this
working group. A special thanks to Eliot for generously
providing the original machine-readable sources for that
document.
The author gratefully acknowledges the work of the Marshall
Rose & John G. Meyers in RFC 1939 and the work of the DRUMS
working group, specifically RFC 1869, which is the basis of
the NNTP extensions mechanism detailed in this document.
The author gratefully acknowledges the authors of RFC 2616 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.
The author gratefully acknowledges the comments and additional
information provided by the following individuals in preparing
one of the progenitors of this document:
. Russ Allbery <rr...@stanford.edu>
. Wayne Davison <da...@armory.com>
. Clive D.W. Feather <cl...@demon.net>
. Chris Lewis <cl...@bnr.ca>
. Tom Limoncelli <ta...@mars.superlink.net>
. Eric Schnoebelen <er...@egsner.cirr.com>
. Rich Salz <rs...@osf.org>
Barber [Page 60]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
This work was motivated by the work of various news reader
authors and news server authors, which includes 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
. 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
18. Author's Address
Stan Barber
P.O. Box 300481
Houston, Texas 77230
Email: sob@academ.com
This document expires October 30, 2001.
Barber [Page 61]
1.1 jakarta-james/www/rfclist/rfc1036.txt
Index: rfc1036.txt
===================================================================
Network Working Group M. Horton
Request for Comments: 1036 AT&T Bell Laboratories
Obsoletes: RFC-850 R. Adams
Center for Seismic Studies
December 1987
Standard for Interchange of USENET Messages
STATUS OF THIS MEMO
This document 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
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.
1. Introduction
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.
2. Message Format
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 RFC-822. The USENET
News standard is more restrictive than the Internet standard,
Horton & Adams [Page 1]
RFC 1036 Standard for USENET Messages December 1987
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, RFC-822 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: <64...@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
Horton & Adams [Page 2]
RFC 1036 Standard for USENET Messages December 1987
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.
2.1. Required Header lines
2.1.1. From
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.
RFC-822 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:
Horton & Adams [Page 3]
RFC 1036 Standard for USENET Messages December 1987
From: mark@cbosgd.ATT.COM
From: mark@cbosgd.ATT.COM (Mark Horton)
From: Mark Horton <ma...@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.
2.1.2. Date
The "Date" line (formerly "Posted") is the date that the message was
originally posted to the network. Its format must be acceptable
both in RFC-822 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 RFC-822 date. However,
since older software still generates this format, news
implementations are encouraged to accept this format and translate
it into an acceptable format.
There is no hope of having a complete list of timezones. Universal
Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
supported. It is recommended that times in message headers be
transmitted in GMT and displayed in the local time zone.
2.1.3. Newsgroups
The "Newsgroups" line specifies the newsgroup or newsgroups in which
the message belongs. Multiple newsgroups may be specified,
separated by a comma. Newsgroups specified must all be the names of
existing newsgroups, as no new newsgroups will be created by simply
posting to them.
Horton & Adams [Page 4]
RFC 1036 Standard for USENET Messages December 1987
Wildcards (e.g., the word "all") are never allowed in a "News-
groups" line. For example, a newsgroup comp.all is illegal,
although a newsgroup rec.sport.football is permitted.
If a message is received with a "Newsgroups" line listing some valid
newsgroups and some invalid newsgroups, a host should not remove
invalid newsgroups from the list. Instead, the invalid newsgroups
should be ignored. For example, suppose host A subscribes to the
classes btl.all and comp.all, and exchanges news messages with host
B, which subscribes to comp.all but not btl.all. Suppose A receives
a message with Newsgroups: comp.unix,btl.general.
This message is passed on to B because B receives comp.unix, but B
does not receive btl.general. A must leave the "Newsgroups" line
unchanged. If it were to remove btl.general, the edited header
could eventually re-enter the btl.all class, resulting in a message
that is not shown to users subscribing to btl.general. Also,
follow-ups from outside btl.all would not be shown to such users.
2.1.4. Subject
The "Subject" line (formerly "Title") tells what the message is
about. It should be suggestive enough of the contents of the
message to enable a reader to make a decision whether to read the
message based on the subject alone. If the message is submitted in
response to another message (e.g., is a follow-up) the default
subject should begin with the four characters "Re:", and the
"References" line is required. For follow-ups, the use of the
"Summary" line is encouraged.
2.1.5. Message-ID
The "Message-ID" line gives the message a unique identifier. The
Message-ID may not be reused during the lifetime of any previous
message with the same Message-ID. (It is recommended that no
Message-ID be reused for at least two years.) Message-ID's have the
syntax:
<string not containing blank or ">">
In order to conform to RFC-822, the Message-ID must have the format:
<un...@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).
Horton & Adams [Page 5]
RFC 1036 Standard for USENET Messages December 1987
For example, the unique part could be an integer representing a
sequence number for messages submitted to the network, or a short
string derived from the date and time the message was created. For
example, a valid Message-ID for a message submitted from host ucbvax
in domain "Berkeley.EDU" would be "<41...@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.
2.1.6. Path
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
Horton & Adams [Page 6]
RFC 1036 Standard for USENET Messages December 1987
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.
2.2. Optional Headers
2.2.1. Reply-To
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.
2.2.2. Sender
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.
Horton & Adams [Page 7]
RFC 1036 Standard for USENET Messages December 1987
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.
2.2.3. Followup-To
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.
2.2.4. Expires
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.
Horton & Adams [Page 8]
RFC 1036 Standard for USENET Messages December 1987
2.2.5. References
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.
2.2.6. Control
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.
Horton & Adams [Page 9]
RFC 1036 Standard for USENET Messages December 1987
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.
2.2.7. Distribution
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.
2.2.8. Organization
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.
2.2.9. Keywords
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.
2.2.10. Summary
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
Horton & Adams [Page 10]
RFC 1036 Standard for USENET Messages December 1987
is very useful to the reader in determining whether to read the
message.
2.2.11. Approved
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.
2.2.12. Lines
This contains a count of the number of lines in the body of the
message.
2.2.13. Xref
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: <56...@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.
3. Control Messages
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
Horton & Adams [Page 11]
RFC 1036 Standard for USENET Messages December 1987
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.
3.1. Cancel
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.
3.2. Ihave/Sendme
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
"<12...@ucbvax.Berkeley.edu>", and wishes to transmit the message to
host B.
A sends the control message "ihave <12...@ucbvax.Berkeley.edu> A" to
host B (by posting it to newsgroup to.B). B responds with the
control message "sendme <12...@ucbvax.Berkeley.edu> B" (on newsgroup
to.A), if it has not already received the message. Upon receiving
Horton & Adams [Page 12]
RFC 1036 Standard for USENET Messages December 1987
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.
3.3. Newgroup
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.
3.4. Rmgroup
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.
Horton & Adams [Page 13]
RFC 1036 Standard for USENET Messages December 1987
3.5. Sendsys
sendsys (no arguments)
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
3.6. Version
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").
3.7. Checkgroups
Horton & Adams [Page 14]
RFC 1036 Standard for USENET Messages December 1987
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.
4. Transmission Methods
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.
4.1. Remote Execution
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
Horton & Adams [Page 15]
RFC 1036 Standard for USENET Messages December 1987
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.
4.2. Transfer by Mail
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:
Horton & Adams [Page 16]
RFC 1036 Standard for USENET Messages December 1987
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: <17...@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.
4.3. Batching
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:
Horton & Adams [Page 17]
RFC 1036 Standard for USENET Messages December 1987
#! 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: <64...@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: <64...@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.
5. The News Propagation Algorithm
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
Horton & Adams [Page 18]
RFC 1036 Standard for USENET Messages December 1987
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]
1.1 jakarta-james/www/rfclist/rfc2980.txt
Index: rfc2980.txt
===================================================================
Network Working Group S. Barber
Request for Comments: 2980 Academ Consulting Services
Category: Informational October 2000
Common NNTP Extensions
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
In this document, a number of popular extensions to the Network News
Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
and discussed. While this document is not intended to serve as a
standard of any kind, it will hopefully serve as a reference document
for future implementers of the NNTP protocol. In the role, this
document would hopefully create the possibility for some level of
interoperability among implementations that make use of extensions.
Introduction
RFC 977 [1] defines the NNTP protocol and was released over a decade
ago. Since then, NNTP has become one of the most popular protocols
in use on the Internet. Many implementations of the protocol have
been created on many different platforms and operating systems. With
the growth in use of the protocol, work began on a revision to NNTP
in 1991, but that work did not result in a new standard protocol
specification. However, many ideas from that working group did find
their way into many implementations of NNTP. Additionally, many
other extensions, often created by newsreader authors, are also in
use. This document will capture and define all known extensions to
NNTP available in official NNTP server releases of some type as of
this writing. Where possible, the server software first implementing
a particular extension will be noted. It is the hope of the author
that using this document in tandem with RFC 977 will limit the
addition of new extensions that essentially do the same thing.
Software developers may wish to use this document and others [2] as a
resource for the development of new software.
Barber Informational [Page 1]
RFC 2980 Common NNTP Extensions October 2000
This document does not specify an Internet Standard of any kind. It
only attempts to document current practices. While this document may
clarify some ambiguity in RFC 977, RFC 977 should be regarded as
authoritative in all cases. There are some implementations that are
not strictly RFC 977 compliant and where necessary, these deviations
from the standard will be noted. This document does reflect the work
of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
Barber.
This document is provided to help implementers have a uniform source
of information about extensions, however, it is important for any
prospective implementer to understand that the extensions listed here
are NOT part of any current standard for NNTP. In fact, some of the
ones listed in this document should not be included in new NNTP
implementations as they should no longer be used modern NNTP
environments. Such commands should be considered historic and are
documented as such in this document.
Extensions fall into three categories: transport, newsreader and
other. Transport extensions are additions to the NNTP specification
that were made specifically to move news articles from one server to
another server. Newsreader extensions are additions to the NNTP
specification that were made to assist NNTP clients in selecting and
retrieving news articles from servers. Other extensions to the NNTP
specification are those which did not specifically fall into either
of the other two categories. Examples of other extensions include
authentication and time-of-day extensions. For each command, the
format of section 3 of RFC 977 will be used.
1. Transport Extensions
A transport extension is one which is primarily used in inter-server
communications. Following are the descriptions of each transport
extension commands and the responses which will be returned by those
commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted. A parameter that may be
repeated is followed by an ellipsis.
Barber Informational [Page 2]
RFC 2980 Common NNTP Extensions October 2000
1.1.1 The CHECK command
CHECK <message-id>
CHECK is used by a peer to discover if the article with the specified
message-id should be sent to the server using the TAKETHIS command.
The peer does not have to wait for a response from the server before
sending the next command.
From using the responses to the sequence of CHECK commands, a list of
articles to be sent can be constructed for subsequent use by the
TAKETHIS command.
The use of the CHECK command for streaming is optional. Some
implementations will directly use the TAKETHIS command and send all
articles in the send queue on that peer for the server.
On some implementations, the use of the CHECK command is not
permitted when the server is in slave mode (via the SLAVE command).
Responses that are of the form X3X must specify the message-id in the
response.
1.1.2. Responses
238 no such article found, please send it to me
400 not accepting articles
431 try sending it again later
438 already have it, please don't send it to me
480 Transfer permission denied
500 Command not understood
1.2.1 The MODE STREAM command
MODE STREAM
MODE STREAM is used by a peer to indicate to the server that it would
like to suspend the lock step conversational nature of NNTP and send
commands in streams. This command should be used before TAKETHIS and
CHECK. See the section on the commands TAKETHIS and CHECK for more
details.
1.2.2. Responses
203 Streaming is OK
500 Command not understood
Barber Informational [Page 3]
RFC 2980 Common NNTP Extensions October 2000
1.3.1 The TAKETHIS command
TAKETHIS <message-id>
TAKETHIS is used to send articles to a server when in streaming mode.
The entire article (header and body, in that sequence) is sent
immediately after the peer sends the TAKETHIS command. The peer does
not have to wait for a response from the server before sending the
next command and the associated article.
During transmission of the article, the peer should send the entire
article, including header and body, in the manner specified for text
transmission from the server. See RFC 977, Section 2.4.1 for
details.
Responses that are of the form X3X must specify the message-id in the
response.
1.3.2. Responses
239 article transferred ok
400 not accepting articles
439 article transfer failed
480 Transfer permission denied
500 Command not understood
1.4.1 The XREPLIC command
XREPLIC ggg:nnn[,ggg:nnn...]
The XREPLIC command makes is possible to exactly duplicate the news
spool structure of one server in another server. It first appeared
in INN.
This command works similarly to the IHAVE command as specified in RFC
977. The same response codes are used. The command line arguments
consist of entries separated by a single comma. Each entry consists
of a news group name, a colon, and an article number. If the server
responds with a 335 response, the article should be filed in the news
group(s) and article number(s) specified in the XREPLIC command line.
If the server cannot do successfully install the article once it has
accepted it, a 436 or 437 response code can be used to indicate the
failure.
This command should only be used when the receiving server is being
fed by only one other server. It is likely that when used with
servers that have multiple feeds that this command will frequently
fail.
Barber Informational [Page 4]
RFC 2980 Common NNTP Extensions October 2000
XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
INN now has the ability to slave servers via transparent means,
simply by having the article's Xref header transferred. (In previous
versions, this header was generated locally and stripped off on
outgoing feeds.)
It is likely that future versions of INN will no longer support
XREPLIC.
1.4.2. Responses
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
2. Newsreader Extensions
Newsreader extensions are those which are primarily used by
newsreading clients. Following are the descriptions of each
newsreader extension commands and the responses which will be
returned by those commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted. A parameter that may be
repeated is followed by an ellipsis. Mutually exclusive parameters
are separated by a vertical bar (|) character. For example,
ggg|<message-id> indicates that a group name or a <message-id> may
be specified, but not both. Some parameters, notably <message-id>,
is case specific. See RFC 1036 for these details.
Also, certain commands make use of a pattern for selection of
multiple news groups. The pattern in all cases is based on the
wildmat [4] format introduced by Rich Salz in 1986. Arguments
expected to be in wildmat format will be represented by the string
wildmat. This format is discussed in detail in section 3.3 of this
document.
2.1.1 Extensions to the LIST command
The original LIST command took no arguments in RFC 977 and returned
the contents of the active file in a specific format. Since the
original newsreaders made use of other information available in the
news transport software in addition to the active file, extensions to
Barber Informational [Page 5]
RFC 2980 Common NNTP Extensions October 2000
the LIST command were created to make that information available to
NNTP newsreaders. There may be other extensions to the LIST command
that simply return the contents of a file. This approach is
suggested over the addition of over verbs. For example, LIST MOTD
could be used instead of adding XMOTD.
2.1.2 LIST ACTIVE
LIST ACTIVE [wildmat]
LIST ACTIVE is exactly the same as the LIST command specified in RFC
977. The responses and the format should exactly match the LIST
command without arguments. If the optional matching parameter is
specified, the list is limited to only the groups that match the
pattern. Specifying a single group is usually very efficient for the
server, and multiple groups may be specified by using wildmat
patterns (described later in this document), not regular expressions.
If nothing is matched an empty list is returned, not an error. This
command first appeared in the UNIX reference version.
2.1.3 LIST ACTIVE.TIMES
LIST ACTIVE.TIMES
The active.times file is maintained by some news transports systems
to contain information about the when and who created a particular
news group. The format of this file generally include three fields.
The first field is the name of the news group. The second is the
time when this group was created on this news server measured in
seconds since January 1, 1970. The third is the email address of the
entity that created the news group. When executed, the information
is displayed following the 215 response. When display is completed,
the server will send a period on a line by itself. If the
information is not available, the server will return the 503 error
response. This command first appeared in the UNIX reference version.
2.1.3.1 Responses
215 information follows
503 program error, function not performed
2.1.4 LIST DISTRIBUTIONS
LIST DISTRIBUTIONS
The distributions file is maintained by some news transport systems
to contain information about valid values for the Distribution: line
in a news article header and about what the values mean. Each line
Barber Informational [Page 6]
RFC 2980 Common NNTP Extensions October 2000
contains two fields, the value and a short explanation on the meaning
of the value. When executed, the information is displayed following
the 215 response. When display is completed, the server will send a
period on a line by itself. If the information is not available, the
server will return the 503 error response. This command first
appeared in the UNIX reference version.
2.1.4.1 Responses
215 information follows
503 program error, function not performed
2.1.5 LIST DISTRIB.PATS
LIST DISTRIB.PATS
The distrib.pats file is maintained by some news transport systems to
contain default values for the Distribution: line in a news article
header when posting to particular news groups. This information
could be used to provide a default value for the Distribution: line
in the header when posting an article. The information returned
involves three fields separated by colons. The first column is a
weight. The second is a group name or a pattern that can be used to
match a group name in the wildmat format. The third is the value of
the Distribution: line that should be used when the group name
matches and the weight value is the highest. All this processing is
done by the news posting client and not by the server itself. The
server just provides this information to the client for it to use or
ignore as it chooses. When executed, the information is displayed
following the 215 response. When display is completed, the server
will send a period on a line by itself. If the information is not
available, the server will return the 503 error response. This
command first appeared in INN.
2.1.5.1 Responses
215 information follows
503 program error, function not performed
2.1.6 LIST NEWSGROUPS
LIST NEWSGROUPS [wildmat]
The newsgroups file is maintained by some news transport systems to
contain the name of each news group which is active on the server and
a short description about the purpose of each news group. Each line
in the file contains two fields, the news group name and a short
explanation of the purpose of that news group. When executed, the
Barber Informational [Page 7]
RFC 2980 Common NNTP Extensions October 2000
information is displayed following the 215 response. When display is
completed, the server will send a period on a line by itself. If the
information is not available, the server will return the 503
response. If the optional matching parameter is specified, the list
is limited to only the groups that match the pattern (no matching is
done on the group descriptions). Specifying a single group is
usually very efficient for the server, and multiple groups may be
specified by using wildmat patterns (similar to file globbing), not
regular expressions. If nothing is matched an empty list is
returned, not an error.
When the optional parameter is specified, this command is equivalent
to the XGTITLE command, though the response code are different.
215 information follows
503 program error, function not performed
2.1.7 LIST OVERVIEW.FMT
LIST OVERVIEW.FMT
The overview.fmt file is maintained by some news transport systems to
contain the order in which header information is stored in the
overview databases for each news group. When executed, news article
header fields are displayed one line at a time in the order in which
they are stored in the overview database [5] following the 215
response. When display is completed, the server will send a period
on a line by itself. If the information is not available, the server
will return the 503 response.
Please note that if the header has the word "full" (without quotes)
after the colon, the header's name is prepended to its field in the
output returned by the server.
Many newsreaders work better if Xref: is one of the optional fields.
It is STRONGLY recommended that this command be implemented in any
server that implements the XOVER command. See section 2.8 for more
details about the XOVER command.
2.1.7.1 Responses
215 information follows
503 program error, function not performed
Barber Informational [Page 8]
RFC 2980 Common NNTP Extensions October 2000
2.1.8 LIST SUBSCRIPTIONS
LIST SUBSCRIPTIONS
This command is used to get a default subscription list for new users
of this server. The order of groups is significant.
When this list is available, it is preceded by the 215 response and
followed by a period on a line by itself. When this list is not
available, the server returns a 503 response code.
2.1.8.1 Responses
215 information follows
503 program error, function not performed
2.2 LISTGROUP
LISTGROUP [ggg]
The LISTGROUP command is used to get a listing of all the article
numbers in a particular news group.
The optional parameter ggg is the name of the news group to be
selected (e.g. "news.software.b"). A list of valid news groups may
be obtained from the LIST command. If no group is specified, the
current group is used as the default argument.
The successful selection response will be a list of the article
numbers in the group followed by a period on a line by itself.
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
news group is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the news group is not case-dependent. It must
otherwise match a news group obtained from the LIST command or an
error will result.
2.2.1 Responses
211 list of article numbers follow
412 Not currently in newsgroup
502 no permission
Barber Informational [Page 9]
RFC 2980 Common NNTP Extensions October 2000
2.3 MODE READER
MODE READER is used by the client to indicate to the server that it
is a news reading client. Some implementations make use of this
information to reconfigure themselves for better performance in
responding to news reader commands. This command can be contrasted
with the SLAVE command in RFC 977, which was not widely implemented.
MODE READER was first available in INN.
2.3.1 Responses
200 Hello, you can post
201 Hello, you can't post
2.4 XGTITLE
XGTITLE [wildmat]
The XGTITLE command is used to retrieve news group descriptions for
specific news groups.
This extension first appeared in ANU-NEWS, an NNTP implementation for
DEC's VMS. The optional parameter is a pattern in wildmat format.
When executed, a 282 response is given followed by lines that have
two fields, the news group name (which matches the pattern in the
argument) and a short explanation of the purpose of the news group.
When no argument is specified, the default argument is the current
group name. When display is completed, the server sends a period on
a line by itself.
Please note that this command and the LIST NEWSGROUP command provide
the same functionality with different response codes.
Since this command provides the same functionality as LIST NEWSGROUP
it is suggested that this extension be deprecated and no longer be
used in newsreading clients.
Note that there is a conflict in one of the response codes from
XGTITLE and some of the authentication extensions.
2.5.1 Responses
481 Groups and descriptions unavailable
282 list of groups and descriptions follows
Barber Informational [Page 10]
RFC 2980 Common NNTP Extensions October 2000
2.6 XHDR
XHDR header [range|<message-id>]
The XHDR command is used to retrieve specific headers from specific
articles.
The required parameter is the name of a header line (e.g. "subject")
in a news group article. See RFC 1036 for a list of valid header
lines. The optional range argument may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
The optional message-id argument indicates a specific article. The
range and message-id arguments are mutually exclusive. If no
argument is specified, then information from the current article is
displayed. Successful responses start with a 221 response followed
by a the matched headers from all matched messages. Each line
containing matched headers returned by the server has an article
number (or message ID, if a message ID was specified in the command),
then one or more spaces, then the value of the requested header in
that article. Once the output is complete, a period is sent on a
line by itself. If the optional argument is a message-id and no such
article exists, the 430 error response is returned. If a range is
specified, a news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Some implementations will return "(none)" followed by a period on a
line by itself if no headers match in any of the articles searched.
Others return the 221 response code followed by a period on a line by
itself.
The XHDR command has been available in the UNIX reference
implementation from its first release. However, until now, it has
been documented only in the source for the server.
Barber Informational [Page 11]
RFC 2980 Common NNTP Extensions October 2000
2.6.1 Responses
221 Header follows
412 No news group current selected
420 No current article selected
430 no such article
502 no permission
2.7 XINDEX
XINDEX ggg
The XINDEX command is used to retrieve an index file in the format of
originally created for use by the TIN [6] news reader.
The required parameter ggg is the name of the news group to be
selected (e.g. "news.software.b"). A list of valid news groups may
be obtained from the LIST command.
The successful selection response will return index file in the
format used by the TIN news reader followed by a period on a line by
itself.
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
news group is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the news group is not case-dependent. It must
otherwise match a news group obtained from the LIST command or an
error will result.
The format of the tin-style index file is discussed in the
documentation for the TIN newsreader. Since more recent versions of
TIN support the news overview (NOV) format, it is recommended that
this extension become historic and no longer be used in current
servers or future implementations.
2.7.1 Responses
218 tin-style index follows
418 no tin-style index is available for this news group
Barber Informational [Page 12]
RFC 2980 Common NNTP Extensions October 2000
2.8 XOVER
XOVER [range]
The XOVER command returns information from the overview database for
the article(s) specified. This command was originally suggested as
part of the OVERVIEW work described in "The Design of a Common
Newsgroup Overview Database for Newsreaders" by Geoff Collyer. This
document is distributed in the Cnews distribution. The optional
range argument may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
If no argument is specified, then information from the current
article is displayed. Successful responses start with a 224 response
followed by the overview information for all matched messages. Once
the output is complete, a period is sent on a line by itself. If no
argument is specified, the information for the current article is
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Each line of output will be formatted with the article number,
followed by each of the headers in the overview database or the
article itself (when the data is not available in the overview
database) for that article separated by a tab character. The
sequence of fields must be in this order: subject, author, date,
message-id, references, byte count, and line count. Other optional
fields may follow line count. Other optional fields may follow line
count. These fields are specified by examining the response to the
LIST OVERVIEW.FMT command. Where no data exists, a null field must
be provided (i.e. the output will have two tab characters adjacent to
each other). Servers should not output fields for articles that have
been removed since the XOVER database was created.
The LIST OVERVIEW.FMT command should be implemented if XOVER is
implemented. A client can use LIST OVERVIEW.FMT to determine what
optional fields and in which order all fields will be supplied by
the XOVER command. See Section 2.1.7 for more details about the LIST
OVERVIEW.FMT command.
Barber Informational [Page 13]
RFC 2980 Common NNTP Extensions October 2000
Note that any tab and end-of-line characters in any header data that
is returned will be converted to a space character.
2.8.1 Responses
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
2.9 XPAT
XPAT header range|<message-id> pat [pat...]
The XPAT command is used to retrieve specific headers from specific
articles, based on pattern matching on the contents of the header.
This command was first available in INN.
The required header parameter is the name of a header line (e.g.
"subject") in a news group article. See RFC 1036 for a list of valid
header lines. The required range argument may be any of the
following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
The required message-id argument indicates a specific article. The
range and message-id arguments are mutually exclusive. At least one
pattern in wildmat must be specified as well. If there are
additional arguments the are joined together separated by a single
space to form one complete pattern. Successful responses start with
a 221 response followed by a the headers from all messages in which
the pattern matched the contents of the specified header line. This
includes an empty list. Once the output is complete, a period is
sent on a line by itself. If the optional argument is a message-id
and no such article exists, the 430 error response is returned. A
502 response will be returned if the client only has permission to
transfer articles.
2.9.1 Responses
221 Header follows
430 no such article
502 no permission
Barber Informational [Page 14]
RFC 2980 Common NNTP Extensions October 2000
2.10 The XPATH command
XPATH <message-id>
The XPATH command is used to determine the filenames in which an
article is filed. It first appeared in INN.
The required parameter message-id is the message id of an article as
shown in that article's message-id header. According to RFC 1036
[3], all message ids for all articles within the netnews environment
are unique, but articles may be crossposted to multiple groups. The
response to an XPATH command will include a listing of all filenames
in which an article is stored separated by spaces or a response
indicating that no article with the specified message-id exists. The
returned data is only useful if the news client knows the
implementation details of the server. Because of this, it is
recommended that client avoid using this command.
2.10.1 Responses
223 path1[ path2 ...]
430 no such article on server
2.11 The XROVER command
XROVER [range]
The XROVER command returns reference information from the overview
database for the article(s) specified. This command first appeared
in the Unix reference implementation. The optional range argument
may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
Successful responses start with a 224 response followed by the
contents of reference information for all matched messages. Once the
output is complete, a period is sent on a line by itself. If no
argument is specified, the information for the current article is
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Barber Informational [Page 15]
RFC 2980 Common NNTP Extensions October 2000
The output will be formatted with the article number, followed by the
contents of the References: line for that article, but does not
contain the field name itself.
This command provides the same basic functionality as using the XHDR
command and "references" as the header argument.
2.11.1 Responses
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
2.12 XTHREAD
XTHREAD [DBINIT|THREAD]
The XTHREAD command is used to retrieve threading information
in format of originally created for use by the TRN [6] news
reader.
The command XTHREAD DBINIT may be issued prior to entering
any groups to see if a thread database exists. If it does,
the database's byte order and version number are returned
as binary data.
If no parameter is given, XTHREAD THREAD is assumed.
To use XTHREAD THREAD, a news group must have been selected
earlier, else a 412 error response is returned.
A 502 response will be returned if the client only has
permission to transfer articles. A 503 response is returned
if the threading files are not available.
The format of the trn-style thread format is discussed in
the documentation for the TRN newsreader. Since more recent
versions of TRN support the news overview (NOV) format, it
is recommended that this extension become historic and no
longer be used in current servers or future implementations.
2.12.1 Responses
288 Binary data to follow
412 No newsgroup current selected
502 No permission
503 program error, function not performed
Barber Informational [Page 16]
RFC 2980 Common NNTP Extensions October 2000
3. Other Extensions
3.1 AUTHINFO
AUTHINFO is used to inform a server about the identity of a user of
the server. In all cases, clients must provide this information when
requested by the server. Servers are not required to accept
authentication information that is volunteered by the client.
Clients must accommodate servers that reject any authentication
information volunteered by the client.
There are three forms of AUTHINFO in use. The original version, an
NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
which is called AUTHINFO GENERIC.
3.1.1 Original AUTHINFO
AUTHINFO USER username
AUTHINFO PASS password
The original AUTHINFO is used to identify a specific entity to the
server using a simple username/password combination. It first
appeared in the UNIX reference implementation.
When authorization is required, the server will send a 480 response
requesting authorization from the client. The client must enter
AUTHINFO USER followed by the username. Once sent, the server will
cache the username and may send a 381 response requesting the
password associated with that username. Should the server request a
password using the 381 response, the client must enter AUTHINFO PASS
followed by a password and the server will then check the
authentication database to see if the username/password combination
is valid. If the combination is valid or if no password is required,
the server will return a 281 response. The client should then retry
the original command to which the server responded with the 480
response. The command should then be processed by the server
normally. If the combination is not valid, the server will return a
502 response.
Clients must provide authentication when requested by the server. It
is possible that some implementations will accept authentication
information at the beginning of a session, but this was not the
original intent of the specification. If a client attempts to
reauthenticate, the server may return 482 response indicating that
the new authentication data is rejected by the server. The 482 code
will also be returned when the AUTHINFO commands are not entered in
the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
PASS preceding AUTHINFO USER).
Barber Informational [Page 17]
RFC 2980 Common NNTP Extensions October 2000
All information is passed in cleartext.
When authentication succeeds, the server will create an email address
for the client from the user name supplied in the AUTHINFO USER
command and the hostname generated by a reverse lookup on the IP
address of the client. If the reverse lookup fails, the IP address,
represented in dotted-quad format, will be used. Once authenticated,
the server shall generate a Sender: line using the email address
provided by authentication if it does not match the client-supplied
From: line. Additionally, the server should log the event, including
the email address. This will provide a means by which subsequent
statistics generation can associate newsgroup references with unique
entities - not necessarily by name.
3.1.1.1 Responses
281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission
3.1.2 AUTHINFO SIMPLE
AUTHINFO SIMPLE
user password
This version of AUTHINFO was part of a proposed NNTP V2
specification, which was started in 1991 but never completed, and is
implemented in some servers and clients. It is a refinement of the
original AUTHINFO and provides the same basic functionality, but the
sequence of commands is much simpler.
When authorization is required, the server sends a 450 response
requesting authorization from the client. The client must enter
AUTHINFO SIMPLE. If the server will accept this form of
authentication, the server responds with a 350 response. The client
must then send the username followed by one or more space characters
followed by the password. If accepted, the server returns a 250
response and the client should then retry the original command to
which the server responded with the 450 response. The command should
then be processed by the server normally. If the combination is not
valid, the server will return a 452 response.
Note that the response codes used here were part of the proposed NNTP
V2 specification and are violations of RFC 977. It is recommended
that this command not be implemented, but use either or both of the
other forms of AUTHINFO if such functionality if required.
Barber Informational [Page 18]
RFC 2980 Common NNTP Extensions October 2000
3.1.2.1 Responses
250 Authorization accepted
350 Continue with authorization sequence
450 Authorization required for this command
452 Authorization rejected
3.1.3 AUTHINFO GENERIC
AUTHINFO GENERIC authenticator arguments...
AUTHINFO GENERIC is used to identify a specific entity to the server
using arbitrary authentication or identification protocols. The
desired protocol is indicated by the authenticator parameter, and any
number of parameters can be passed to the authenticator.
When authorization is required, the server will send a 480 response
requesting authorization from the client. The client should enter
AUTHINFO GENERIC followed by the authenticator name, and the
arguments if any. The authenticator and arguments must not contain
the sequence "..".
The server will attempt to engage the server end authenticator,
similarly, the client should engage the client end authenticator.
The server end authenticator will then initiate authentication using
the NNTP sockets (if appropriate for that authentication protocol),
using the protocol specified by the authenticator name. These
authentication protocols are not included in this document, but are
similar in structure to those referenced in RFC 1731 [8] for the
IMAP-4 protocol.
If the server returns 501, this means that the authenticator
invocation was syntactically incorrect, or that AUTHINFO GENERIC is
not supported. The client should retry using the AUTHINFO USER
command.
If the requested authenticator capability is not found, the server
returns the 503 response code.
If there is some other unspecified server program error, the server
returns the 500 response code.
The authenticators converse using their protocol until complete. If
the authentication succeeds, the server authenticator will terminate
with a 281, and the client can continue by reissuing the command that
prompted the 380. If the authentication fails, the server will
respond with a 502.
Barber Informational [Page 19]
RFC 2980 Common NNTP Extensions October 2000
The client must provide authentication when requested by the server.
The server may request authentication at any time. Servers may
request authentication more than once during a single session.
When the server authenticator completes, it provides to the server
(by a mechanism herein undefined) the email address of the user, and
potentially what the user is allowed to access. Once authenticated,
the server shall generate a Sender: line using the email address
provided by the authenticator if it does not match the user-supplied
From: line. Additionally, the server should log the event, including
the user's authenticated email address (if available). This will
provide a means by which subsequent statistics generation can
associate newsgroup references with unique entities - not necessarily
by name.
Some implementations make it possible to obtain a list of
authentication procedures available by sending the server AUTHINFO
GENERIC with no arguments. The server then returns a list of
supported mechanisms followed by a period on a line by itself.
3.1.3.1 Responses
281 Authentication succeeded
480 Authentication required
500 Command not understood
501 Command not supported
502 No permission
503 Program error, function not performed
nnn authenticator-specific protocol.
3.2 DATE
DATE
The first NNTP working group discussed and proposed a syntax for this
command to help clients find out the current time from the server's
perspective. At the time this command was discussed (1991-1992), the
Network Time Protocol [9] (NTP) was not yet in wide use and there was
also some concern that small systems may not be able to make
effective use of NTP.
This command returns a one-line response code of 111 followed by the
GMT date and time on the server in the form YYYYMMDDhhmmss.
3.2.1 Responses
111 YYYYMMDDhhmmss
Barber Informational [Page 20]
RFC 2980 Common NNTP Extensions October 2000
3.3 The WILDMAT format
The WILDMAT format was first developed by Rich Salz based on 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. Patterns are
implicitly anchored at the beginning and end of each string when
testing for a match. There are five pattern matching operations
other than a strict one-to-one match between the pattern and the
source to be checked for a match. The first is an asterisk (*) to
match any sequence of zero or more characters. The second is a
question mark (?) to match any single character. The third specifies
a specific set of characters. The set is specified as a list of
characters, or as a range of characters where the beginning and end
of the range are separated by a minus (or dash) character, or as any
combination of lists and ranges. The dash can also be included in
the set as a character it if is the beginning or end of the set.
This set is enclosed in square brackets. The close square bracket
(]) may be used in a set if it is the first character in the set.
The fourth operation is the same as the logical not of the third
operation and is specified the same way as the third with the
addition of a caret character (^) at the beginning of the test string
just inside the open square bracket. The final operation uses the
backslash character to invalidate the special meaning of the a open
square bracket ([), the asterisk, backslash or the question mark.
Two backslashes in sequence will result in the evaluation of the
backslash as a character with no special meaning.
3.3.1 Examples
a. [^]-] -- matches any single character other than a close square
bracket or a minus sign/dash.
b. *bdc -- matches any string that ends with the string "bdc"
including the string "bdc" (without quotes).
c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
character.
d. a??d -- matches any four character string which begins
with a and ends with d.
Barber Informational [Page 21]
RFC 2980 Common NNTP Extensions October 2000
3.4 Additional Headers
Many NNTP implementations add headers to Usenet articles when then
are POSTed via NNTP. These headers are discussed in this section.
None of these headers conflict with those specified in RFC 1036 and
should be passed unchanged by Usenet transports conforming to RFC
1036.
3.4.1 NNTP-Posting-Host
This line is added to the header of a posted article by the server.
The contents of the header is either the IP address or the fully
qualified domain name of the client host posting the article. The
fully qualified domain name should be determined by doing a reverse
lookup in the DNS on the IP address of the client. If the client
article contains this line, it is removed by the server before
acceptance of the article by the Usenet transport system.
This header provides some idea of the actual host posting the article
as opposed to information in the Sender or From lines that may be
present in the article. This is not a fool-proof methodology since
reverse lookups in the DNS are vulnerable to certain types of
spoofing, but such discussions are outside the scope of this
document.
3.4.2 X-Newsreader and others
There are other lines that are added by clients as well. Most of
these indicate the type of newsreader software that is posting the
article.
4.0 Common Implementation Issues
Many NNTP implementations do not follow the specifications in RFC
977. In this section, some common implementation issues are
summarized.
4.1 The Response to the LIST command
RFC 977 says that the fourth field of the "list of valid newsgroups
associated information" returned must be "either 'y' or 'n'
indicating whether posting to this newsgroup is allowed ('y') or
prohibited ('n'). Most implementations simply output the exact
contents of the transport system's active newsgroup list. For more
implementations, the fourth field usually has more values that 'y' or
'n'.
Barber Informational [Page 22]
RFC 2980 Common NNTP Extensions October 2000
4.2 The Required Headers in an Article and the POST command
RFC 977 notes in section 3.10.1 that articles presented "should
include all required header lines." In fact, modern implementations
only require From, Subject, and Newsgroups header lines and will
supply the rest; further, many implementers believe that it is best
for clients to generate as few headers as possible, since clients
often do not format other headers correctly.
This implementation behavior is consistent with both Bnews and Cnews
which would supply missing headers for articles directly submitted to
them.
4.3 Article Numbering
RFC 977 does not directly address the rules concerning articles
number. However, the current practice is simple: article numbers are
monotonically increasing, articles may disappear, and therefore the
high and low water marks returned in a GROUP command should be
treated as maximum minima, and minimum maxima, respectively.
4.4 Availability of commands defined in RFC 977
Some implementations permit administrators to disable commands
defined RFC 977. Some implementations have some set of commands
disabled by default. This means that client implementations cannot
depend on the availability of the disabled set of commands. This
increases the complexity of the client and does not encourage
implementors to optimize the implementation of commands that don't
perform well.
NEWNEWS is one of the commands frequently disabled.
4.5 The Distribution header and NEWNEWS
In section 12.4 of RFC 977, the optional distributions argument is
described. This argument, according to RFC 977, would limit the
responses to articles that were in newsgroups with prefixes that
matched the optional distributions argument.
Some implementations implement this by matching the Distributions
header in articles to the distribution argument. Others do the match
against segments of the newsgroup's name.
This variation is probably best explained by the evolution of the
USENET article format. At the time RFC 977 was specified, the
newsgroup name defined how the group was distributed throughout
USENET. RFC 1036 changed this convention. So, those that are
Barber Informational [Page 23]
RFC 2980 Common NNTP Extensions October 2000
strictly implementing RFC 977 would match the newsgroup name prefix
against the distribution argument and only display matches. Those
that implement against the intent of the command (as modified by the
redefinition of the article format)would match the Distributions
header against the distribution argument and only display those
matches.
5.0 Further Work
With the continued use of NNTP on the Internet, there remains an
interest in creating an optimized transport protocol for server-to-
server transfers and an optimized client protocol for client-to-
server interactions. There is also considerable interest is building
better mechanisms to provide audit information on which news groups
are being read by which users.
An IETF working group has been formed and it is the hope of this
author that these issues will be addressed in that forum.
6.0 Security Considerations
The use of the AUTHINFO is optional. This command as documented has
a number of security implications. In the original and simple forms,
all passwords are passed in plaintext and could be discovered by
various forms of network or system surveillance. The AUTHINFO
GENERIC command has the potential for the same problems if a
mechanism is used that also passes cleartext passwords. RFC 1731 [8]
discusses these issues in greater detail.
7.0 References
[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
977, February 1986.
[2] Limoncelli, Tom, "Read This Before You Write a Newsreader",
http://mars.superlink.net/tal/news-software-authors.html, June,
1996.
[3] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[4] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
distribution, UUNET Technologies, Revision 1.10, April, 1992.
[5] Robertson, Rob, "FAQ: Overview database / NOV General
Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
nov.Z, January, 1995.
Barber Informational [Page 24]
RFC 2980 Common NNTP Extensions October 2000
[6] Lea, Iain, "FAQ about the TIN newsreader",
http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
[7] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
software/readers/%5Bnews.software.readers%5D_trn_newsreader
_FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
-hierarchy/news/software/readers/%5Bnews.software.readers
%5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
[8] Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
December 1994.
[9] Mills, D., "Network Time Protocol (Version 3), Specification,
Implementation and Analysis", RFC 1305, March 1992.
8.0 Notes
DEC is a registered trademark of Compaq Computer Corporation. UNIX
is a registered trademark of The Open Group. VMS is a registered
trademark of Compaq Computer Corporation.
9.0 Acknowledgments
The author gratefully acknowledges the comments and additional
information provided by the following individuals:
Wayne Davison <da...@armory.com>
Chris Lewis <cl...@bnr.ca>
Tom Limoncelli <ta...@lucent.com>
Eric Schnoebelen <er...@egsner.cirr.com>
Rich Salz <rs...@osf.org>
This work was precipitated by the work of various newsreader authors
and newsserver authors which includes those listed below:
Rick Adams -- Original author of the NNTP extensions to the RN
newsreader and last maintainer of Bnews
Stan Barber -- Original author of the NNTP extensions to the
newsreaders 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 newsreader
Wayne Davison -- Author of the first threading extensions to the
RN newsreader (commonly called TRN).
Geoff Huston -- Original author of ANU NEWS
Barber Informational [Page 25]
RFC 2980 Common NNTP Extensions October 2000
Phil Lapsey -- Original author of the UNIX reference
implementation
Iain Lea -- Original maintainer of the TIN newsreader
Chris Lewis -- First known implementor 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 newsreader
10.0 Author's Address
Stan Barber
P.O. Box 300481
Houston, Texas, 77230
EMail: sob@academ.com
Barber Informational [Page 26]
RFC 2980 Common NNTP Extensions October 2000
11.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Barber Informational [Page 27]
1.1 jakarta-james/www/rfclist/rfc822.txt
Index: rfc822.txt
===================================================================
RFC # 822
Obsoletes: RFC #733 (NIC #41952)
STANDARD FOR THE FORMAT OF
ARPA INTERNET TEXT MESSAGES
August 13, 1982
Revised by
David H. Crocker
Dept. of Electrical Engineering
University of Delaware, Newark, DE 19711
Network: DCrocker @ UDel-Relay
Standard for ARPA Internet Text Messages
TABLE OF CONTENTS
PREFACE .................................................... ii
1. INTRODUCTION ........................................... 1
1.1. Scope ............................................ 1
1.2. Communication Framework .......................... 2
2. NOTATIONAL CONVENTIONS ................................. 3
3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
3.1. General Description .............................. 5
3.2. Header Field Definitions ......................... 9
3.3. Lexical Tokens ................................... 10
3.4. Clarifications ................................... 11
4. MESSAGE SPECIFICATION .................................. 17
4.1. Syntax ........................................... 17
4.2. Forwarding ....................................... 19
4.3. Trace Fields ..................................... 20
4.4. Originator Fields ................................ 21
4.5. Receiver Fields .................................. 23
4.6. Reference Fields ................................. 23
4.7. Other Fields ..................................... 24
5. DATE AND TIME SPECIFICATION ............................ 26
5.1. Syntax ........................................... 26
5.2. Semantics ........................................ 26
6. ADDRESS SPECIFICATION .................................. 27
6.1. Syntax ........................................... 27
6.2. Semantics ........................................ 27
6.3. Reserved Address ................................. 33
7. BIBLIOGRAPHY ........................................... 34
APPENDIX
A. EXAMPLES ............................................... 36
B. SIMPLE FIELD PARSING ................................... 40
C. DIFFERENCES FROM RFC #733 .............................. 41
D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
August 13, 1982 - i - RFC #822
Standard for ARPA Internet Text Messages
PREFACE
By 1977, the Arpanet employed several informal standards for
the text messages (mail) sent among its host computers. It was
felt necessary to codify these practices and provide for those
features that seemed imminent. The result of that effort was
Request for Comments (RFC) #733, "Standard for the Format of ARPA
Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
The specification attempted to avoid major changes in existing
software, while permitting several new features.
This document revises the specifications in RFC #733, in
order to serve the needs of the larger and more complex ARPA
Internet. Some of RFC #733's features failed to gain adequate
acceptance. In order to simplify the standard and the software
that follows it, these features have been removed. A different
addressing scheme is used, to handle the case of inter-network
mail; and the concept of re-transmission has been introduced.
This specification is intended for use in the ARPA Internet.
However, an attempt has been made to free it of any dependence on
that environment, so that it can be applied to other network text
message systems.
The specification of RFC #733 took place over the course of
one year, using the ARPANET mail environment, itself, to provide
an on-going forum for discussing the capabilities to be included.
More than twenty individuals, from across the country, partici-
pated in the original discussion. The development of this
revised specification has, similarly, utilized network mail-based
group discussion. Both specification efforts greatly benefited
from the comments and ideas of the participants.
The syntax of the standard, in RFC #733, was originally
specified in the Backus-Naur Form (BNF) meta-language. Ken L.
Harrenstien, of SRI International, was responsible for re-coding
the BNF into an augmented BNF that makes the representation
smaller and easier to understand.
August 13, 1982 - ii - RFC #822
Standard for ARPA Internet Text Messages
1. INTRODUCTION
1.1. SCOPE
This standard specifies a syntax for text messages that are
sent among computer users, within the framework of "electronic
mail". The standard supersedes the one specified in ARPANET
Request for Comments #733, "Standard for the Format of ARPA Net-
work Text Messages".
In this context, messages are viewed as having an envelope
and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. The contents
compose the object to be delivered to the recipient. This stan-
dard applies only to the format and some of the semantics of mes-
sage contents. It contains no specification of the information
in the envelope.
However, some message systems may use information from the
contents to create the envelope. It is intended that this stan-
dard facilitate the acquisition of such information by programs.
Some message systems may store messages in formats that
differ from the one specified in this standard. This specifica-
tion is intended strictly as a definition of what message content
format is to be passed BETWEEN hosts.
Note: This standard is NOT intended to dictate the internal for-
mats used by sites, the specific message system features
that they are expected to support, or any of the charac-
teristics of user interface programs that create or read
messages.
A distinction should be made between what the specification
REQUIRES and what it ALLOWS. Messages can be made complex and
rich with formally-structured components of information or can be
kept small and simple, with a minimum of such information. Also,
the standard simplifies the interpretation of differing visual
formats in messages; only the visual aspect of a message is
affected and not the interpretation of information within it.
Implementors may choose to retain such visual distinctions.
The formal definition is divided into four levels. The bot-
tom level describes the meta-notation used in this document. The
second level describes basic lexical analyzers that feed tokens
to higher-level parsers. Next is an overall specification for
messages; it permits distinguishing individual fields. Finally,
there is definition of the contents of several structured fields.
August 13, 1982 - 1 - RFC #822
Standard for ARPA Internet Text Messages
1.2. COMMUNICATION FRAMEWORK
Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
and the standard tends to be free with the number of bits con-
sumed. For example, field names are specified as free text,
rather than special terse codes.
A general "memo" framework is used. That is, a message con-
sists of some information in a rigid format, followed by the main
part of the message, with a format that is not specified in this
document. The syntax of several fields of the rigidly-formated
("headers") section is defined in this specification; some of
these fields must be included in all messages.
The syntax that distinguishes between header fields is
specified separately from the internal syntax for particular
fields. This separation is intended to allow simple parsers to
operate on the general structure of messages, without concern for
the detailed structure of individual header fields. Appendix B
is provided to facilitate construction of these parsers.
In addition to the fields specified in this document, it is
expected that other fields will gain common use. As necessary,
the specifications for these "extension-fields" will be published
through the same mechanism used to publish this document. Users
may also wish to extend the set of fields that they use
privately. Such "user-defined fields" are permitted.
The framework severely constrains document tone and appear-
ance and is primarily useful for most intra-organization communi-
cations and well-structured inter-organization communication.
It also can be used for some types of inter-process communica-
tion, such as simple file transfer and remote job entry. A more
robust framework might allow for multi-font, multi-color, multi-
dimension encoding of information. A less robust one, as is
present in most single-machine message systems, would more
severely constrain the ability to add fields and the decision to
include specific fields. In contrast with paper-based communica-
tion, it is interesting to note that the RECEIVER of a message
can exercise an extraordinary amount of control over the
message's appearance. The amount of actual control available to
message receivers is contingent upon the capabilities of their
individual message systems.
August 13, 1982 - 2 - RFC #822
Standard for ARPA Internet Text Messages
2. NOTATIONAL CONVENTIONS
This specification uses an augmented Backus-Naur Form (BNF)
notation. The differences from standard BNF involve naming rules
and indicating repetition and "local" alternatives.
2.1. RULE NAMING
Angle brackets ("<", ">") are not used, in general. The
name of a rule is simply the name itself, rather than "<name>".
Quotation-marks enclose literal text (which may be upper and/or
lower case). Certain basic rules are in uppercase, such as
SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in
rule definitions, and in the rest of this document, whenever
their presence will facilitate discerning the use of rule names.
2.2. RULE1 / RULE2: ALTERNATIVES
Elements separated by slash ("/") are alternatives. There-
fore "foo / bar" will accept foo or bar.
2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
Elements enclosed in parentheses are treated as a single
element. Thus, "(elem (foo / bar) elem)" allows the token
sequences "elem foo elem" and "elem bar elem".
2.4. *RULE: REPETITION
The character "*" preceding an element indicates repetition.
The full form is:
<l>*<m>element
indicating at least <l> and at most <m> occurrences of element.
Default values are 0 and infinity so that "*(element)" allows any
number, including zero; "1*element" requires at least one; and
"1*2element" allows one or two.
2.5. [RULE]: OPTIONAL
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
2.6. NRULE: SPECIFIC REPETITION
"<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
number, and 3ALPHA is a string of three alphabetic characters.
August 13, 1982 - 3 - RFC #822
Standard for ARPA Internet Text Messages
2.7. #RULE: LISTS
A construct "#" is defined, similar to "*", as follows:
<l>#<m>element
indicating at least <l> and at most <m> elements, each separated
by one or more commas (","). This makes the usual form of lists
very easy; a rule such as '(element *("," element))' can be shown
as "1#element". Wherever this construct is used, null elements
are allowed, but do not contribute to the count of elements
present. That is, "(element),,(element)" is permitted, but
counts as only two elements. Therefore, where at least one ele-
ment is required, at least one non-null element must be present.
Default values are 0 and infinity so that "#(element)" allows any
number, including zero; "1#element" requires at least one; and
"1#2element" allows one or two.
2.8. ; COMMENTS
A semi-colon, set off some distance to the right of rule
text, starts a comment that continues to the end of line. This
is a simple way of including useful notes in parallel with the
specifications.
August 13, 1982 - 4 - RFC #822
Standard for ARPA Internet Text Messages
3. LEXICAL ANALYSIS OF MESSAGES
3.1. GENERAL DESCRIPTION
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
3.1.1. LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted. Thus, the single line
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
can be represented as:
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
and
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
and
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.
Note: While the standard permits folding wherever linear-
white-space is permitted, it is recommended that struc-
tured fields, such as those containing addresses, limit
folding to higher-level syntactic breaks. For address
fields, it is recommended that such folding occur
August 13, 1982 - 5 - RFC #822
Standard for ARPA Internet Text Messages
between addresses, after the separating comma.
3.1.2. STRUCTURE OF HEADER FIELDS
Once a field has been unfolded, it may be viewed as being com-
posed of a field-name followed by a colon (":"), followed by a
field-body, and terminated by a carriage-return/line-feed.
The field-name must be composed of printable ASCII characters
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of any
ASCII characters, except CR or LF. (While CR and/or LF may be
present in the actual text, they are removed by the action of
unfolding the field.)
Certain field-bodies of headers may be interpreted according
to an internal syntax that some systems may wish to parse.
These fields are called "structured fields". Examples
include fields containing dates and addresses. Other fields,
such as "Subject" and "Comments", are regarded simply as
strings of text.
Note: Any field which has a field-body that is defined as
other than simply <text> is to be treated as a struc-
tured field.
Field-names, unstructured field bodies and structured
field bodies each are scanned by their own, independent
"lexical" analyzers.
3.1.3. UNSTRUCTURED FIELD BODIES
For some fields, such as "Subject" and "Comments", no struc-
turing is assumed, and they are treated simply as <text>s, as
in the message body. Rules of folding apply to these fields,
so that such field bodies which occupy several lines must
therefore have the second and successive lines indented by at
least one LWSP-char.
3.1.4. STRUCTURED FIELD BODIES
To aid in the creation and reading of structured fields, the
free insertion of linear-white-space (which permits folding
by inclusion of CRLFs) is allowed between lexical tokens.
Rather than obscuring the syntax specifications for these
structured fields with explicit syntax for this linear-white-
space, the existence of another "lexical" analyzer is assumed.
This analyzer does not apply for unstructured field bodies
that are simply strings of text, as described above. The
analyzer provides an interpretation of the unfolded text
August 13, 1982 - 6 - RFC #822
Standard for ARPA Internet Text Messages
composing the body of the field as a sequence of lexical sym-
bols.
These symbols are:
- individual special characters
- quoted-strings
- domain-literals
- comments
- atoms
The first four of these symbols are self-delimiting. Atoms
are not; they are delimited by the self-delimiting symbols and
by linear-white-space. For the purposes of regenerating
sequences of atoms and quoted-strings, exactly one SPACE is
assumed to exist, and should be used, between them. (Also, in
the "Clarifications" section on "White Space", below, note the
rules about treatment of multiple contiguous LWSP-chars.)
So, for example, the folded body of an address field
":sysmail"@ Some-Group. Some-Org,
Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
August 13, 1982 - 7 - RFC #822
Standard for ARPA Internet Text Messages
is analyzed into the following lexical symbols and types:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
The canonical representations for the data in these addresses
are the following strings:
":sysmail"@Some-Group.Some-Org
and
Muhammed.Ali@Vegas.WBA
Note: For purposes of display, and when passing such struc-
tured information to other systems, such as mail proto-
col services, there must be NO linear-white-space
between <word>s that are separated by period (".") or
at-sign ("@") and exactly one SPACE between all other
<word>s. Also, headers should be in a folded form.
August 13, 1982 - 8 - RFC #822
Standard for ARPA Internet Text Messages
3.2. HEADER FIELD DEFINITIONS
These rules show a field meta-syntax, without regard for the
particular type or internal syntax. Their purpose is to permit
detection of fields; also, they present to higher-level parsers
an image of each field as fitting on one line.
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
August 13, 1982 - 9 - RFC #822
Standard for ARPA Internet Text Messages
3.3. LEXICAL TOKENS
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to higher level parsers. See the
ANSI references, in the Bibliography.
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF
LWSP-char = SPACE / HTAB ; semantics = SPACE
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
delimiters = specials / linear-white-space / comment
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
domain-literal = "[" *(dtext / quoted-pair) "]"
August 13, 1982 - 10 - RFC #822
Standard for ARPA Internet Text Messages
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
phrase = 1*word ; Sequence of words
word = atom / quoted-string
3.4. CLARIFICATIONS
3.4.1. QUOTING
Some characters are reserved for special interpretation, such
as delimiting lexical tokens. To permit use of these charac-
ters as uninterpreted data, a quoting mechanism is provided.
To quote a character, precede it with a backslash ("\").
This mechanism is not fully general. Characters may be quoted
only within a subset of the lexical constructs. In particu-
lar, quoting is limited to use within:
- quoted-string
- domain-literal
- comment
Within these constructs, quoting is REQUIRED for CR and "\"
and for the character(s) that delimit the token (e.g., "(" and
")" for a comment). However, quoting is PERMITTED for any
character.
Note: In particular, quoting is NOT permitted within atoms.
For example when the local-part of an addr-spec must
contain a special character, a quoted string must be
used. Therefore, a specification such as:
Full\ Name@Domain
is not legal and must be specified as:
"Full Name"@Domain
August 13, 1982 - 11 - RFC #822
Standard for ARPA Internet Text Messages
3.4.2. WHITE SPACE
Note: In structured field bodies, multiple linear space ASCII
characters (namely HTABs and SPACEs) are treated as
single spaces and may freely surround any symbol. In
all header fields, the only place in which at least one
LWSP-char is REQUIRED is at the beginning of continua-
tion lines in a folded field.
When passing text to processes that do not interpret text
according to this standard (e.g., mail protocol servers), then
NO linear-white-space characters should occur between a period
(".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
be used in place of arbitrary linear-white-space and comment
sequences.
Note: Within systems conforming to this standard, wherever a
member of the list of delimiters is allowed, LWSP-chars
may also occur before and/or after it.
Writers of mail-sending (i.e., header-generating) programs
should realize that there is no network-wide definition of the
effect of ASCII HT (horizontal-tab) characters on the appear-
ance of text at another network host; therefore, the use of
tabs in message headers, though permitted, is discouraged.
3.4.3. COMMENTS
A comment is a set of ASCII characters, which is enclosed in
matching parentheses and which is not within a quoted-string
The comment construct permits message originators to add text
which will be useful for human readers, but which will be
ignored by the formal semantics. Comments should be retained
while the message is subject to interpretation according to
this standard. However, comments must NOT be included in
other cases, such as during protocol exchanges with mail
servers.
Comments nest, so that if an unquoted left parenthesis occurs
in a comment string, there must also be a matching right
parenthesis. When a comment acts as the delimiter between a
sequence of two lexical symbols, such as two atoms, it is lex-
ically equivalent with a single SPACE, for the purposes of
regenerating the sequence, such as when passing the sequence
onto a mail protocol server. Comments are detected as such
only within field-bodies of structured fields.
If a comment is to be "folded" onto multiple lines, then the
syntax for folding must be adhered to. (See the "Lexical
August 13, 1982 - 12 - RFC #822
Standard for ARPA Internet Text Messages
Analysis of Messages" section on "Folding Long Header Fields"
above, and the section on "Case Independence" below.) Note
that the official semantics therefore do not "see" any
unquoted CRLFs that are in comments, although particular pars-
ing programs may wish to note their presence. For these pro-
grams, it would be reasonable to interpret a "CRLF LWSP-char"
as being a CRLF that is part of the comment; i.e., the CRLF is
kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a
backslash followed by a CR followed by a LF) still must be
followed by at least one LWSP-char.
3.4.4. DELIMITING AND QUOTING CHARACTERS
The quote character (backslash) and characters that delimit
syntactic units are not, generally, to be taken as data that
are part of the delimited or quoted unit(s). In particular,
the quotation-marks that define a quoted-string, the
parentheses that define a comment and the backslash that
quotes a following character are NOT part of the quoted-
string, comment or quoted character. A quotation-mark that is
to be part of a quoted-string, a parenthesis that is to be
part of a comment and a backslash that is to be part of either
must each be preceded by the quote-character backslash ("\").
Note that the syntax allows any character to be quoted within
a quoted-string or comment; however only certain characters
MUST be quoted to be included as data. These characters are
the ones that are not part of the alternate text group (i.e.,
ctext or qtext).
The one exception to this rule is that a single SPACE is
assumed to exist between contiguous words in a phrase, and
this interpretation is independent of the actual number of
LWSP-chars that the creator places between the words. To
include more than one SPACE, the creator must make the LWSP-
chars be part of a quoted-string.
Quotation marks that delimit a quoted string and backslashes
that quote the following character should NOT accompany the
quoted-string when the string is passed to processes that do
not interpret data according to this specification (e.g., mail
protocol servers).
3.4.5. QUOTED-STRINGS
Where permitted (i.e., in words in structured fields) quoted-
strings are treated as a single symbol. That is, a quoted-
string is equivalent to an atom, syntactically. If a quoted-
string is to be "folded" onto multiple lines, then the syntax
for folding must be adhered to. (See the "Lexical Analysis of
August 13, 1982 - 13 - RFC #822
Standard for ARPA Internet Text Messages
Messages" section on "Folding Long Header Fields" above, and
the section on "Case Independence" below.) Therefore, the
official semantics do not "see" any bare CRLFs that are in
quoted-strings; however particular parsing programs may wish
to note their presence. For such programs, it would be rea-
sonable to interpret a "CRLF LWSP-char" as being a CRLF which
is part of the quoted-string; i.e., the CRLF is kept and the
LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol-
lowed by a CR followed by a LF) are also subject to rules of
folding, but the presence of the quoting character (backslash)
explicitly indicates that the CRLF is data to the quoted
string. Stripping off the first following LWSP-char is also
appropriate when parsing quoted CRLFs.
3.4.6. BRACKETING CHARACTERS
There is one type of bracket which must occur in matched pairs
and may have pairs nested within each other:
o Parentheses ("(" and ")") are used to indicate com-
ments.
There are three types of brackets which must occur in matched
pairs, and which may NOT be nested:
o Colon/semi-colon (":" and ";") are used in address
specifications to indicate that the included list of
addresses are to be treated as a group.
o Angle brackets ("<" and ">") are generally used to
indicate the presence of a one machine-usable refer-
ence (e.g., delimiting mailboxes), possibly including
source-routing to the machine.
o Square brackets ("[" and "]") are used to indicate the
presence of a domain-literal, which the appropriate
name-domain is to use directly, bypassing normal
name-resolution mechanisms.
3.4.7. CASE INDEPENDENCE
Except as noted, alphabetic strings may be represented in any
combination of upper and lower case. The only syntactic units
August 13, 1982 - 14 - RFC #822
Standard for ARPA Internet Text Messages
which requires preservation of case information are:
- text
- qtext
- dtext
- ctext
- quoted-pair
- local-part, except "Postmaster"
When matching any other syntactic unit, case is to be ignored.
For example, the field-names "From", "FROM", "from", and even
"FroM" are semantically equal and should all be treated ident-
ically.
When generating these units, any mix of upper and lower case
alphabetic characters may be used. The case shown in this
specification is suggested for message-creating processes.
Note: The reserved local-part address unit, "Postmaster", is
an exception. When the value "Postmaster" is being
interpreted, it must be accepted in any mixture of
case, including "POSTMASTER", and "postmaster".
3.4.8. FOLDING LONG HEADER FIELDS
Each header field may be represented on exactly one line con-
sisting of the name of the field and its body, and terminated
by a CRLF; this is what the parser sees. For readability, the
field-body portion of long header fields may be "folded" onto
multiple lines of the actual field. "Long" is commonly inter-
preted to mean greater than 65 or 72 characters. The former
length serves as a limit, when the message is to be viewed on
most simple terminals which use simple display software; how-
ever, the limit is not imposed by this standard.
Note: Some display software often can selectively fold lines,
to suit the display terminal. In such cases, sender-
provided folding can interfere with the display
software.
3.4.9. BACKSPACE CHARACTERS
ASCII BS characters (Backspace, decimal 8) may be included in
texts and quoted-strings to effect overstriking. However, any
use of backspaces which effects an overstrike to the left of
the beginning of the text or quoted-string is prohibited.
August 13, 1982 - 15 - RFC #822
Standard for ARPA Internet Text Messages
3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
During transmission through heterogeneous networks, it may be
necessary to force data to conform to a network's local con-
ventions. For example, it may be required that a CR be fol-
lowed either by LF, making a CRLF, or by <null>, if the CR is
to stand alone). Such transformations are reversed, when the
message exits that network.
When crossing network boundaries, the message should be
treated as passing through two modules. It will enter the
first module containing whatever network-specific transforma-
tions that were necessary to permit migration through the
"current" network. It then passes through the modules:
o Transformation Reversal
The "current" network's idiosyncracies are removed and
the message is returned to the canonical form speci-
fied in this standard.
o Transformation
The "next" network's local idiosyncracies are imposed
on the message.
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
Conformance
with standard
||
\/
------------------
| Impose Net-B | ==> To
| idiosyncracies | Net-B
------------------
August 13, 1982 - 16 - RFC #822
Standard for ARPA Internet Text Messages
4. MESSAGE SPECIFICATION
4.1. SYNTAX
Note: Due to an artifact of the notational conventions, the syn-
tax indicates that, when present, some fields, must be in
a particular order. Header fields are NOT required to
occur in any particular order, except that the message
body must occur AFTER the headers. It is recommended
that, if present, headers be sent in the order "Return-
Path", "Received", "Date", "From", "Subject", "Sender",
"To", "cc", etc.
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
The following syntax for the bodies of various fields should
be thought of as describing each field body as a single long
string (or line). The "Lexical Analysis of Message" section on
"Long Header Fields", above, indicates how such long strings can
be represented on more than one line in the actual transmitted
message.
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
trace = return ; path to sender
1*received ; receipt tags
return = "Return-path" ":" route-addr ; return address
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
August 13, 1982 - 17 - RFC #822
Standard for ARPA Internet Text Messages
";" date-time ; time received
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
dates = orig-date ; Original
[ resent-date ] ; Forwarded
orig-date = "Date" ":" date-time
resent-date = "Resent-Date" ":" date-time
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
msg-id = "<" addr-spec ">" ; Unique message id
August 13, 1982 - 18 - RFC #822
Standard for ARPA Internet Text Messages
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
4.2. FORWARDING
Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
Whenever the string "Resent-" begins a field name, the field
has the same semantics as a field whose name does not have the
prefix. However, the message is assumed to have been forwarded
by an original recipient who attached the "Resent-" field. This
new field is treated as being more recent than the equivalent,
original field. For example, the "Resent-From", indicates the
person that forwarded the message, whereas the "From" field indi-
cates the original author.
Use of such precedence information depends upon partici-
pants' communication needs. For example, this standard does not
dictate when a "Resent-From:" address should receive replies, in
lieu of sending them to the "From:" address.
Note: In general, the "Resent-" fields should be treated as con-
taining a set of information that is independent of the
set of original fields. Information for one set should
not automatically be taken from the other. The interpre-
tation of multiple "Resent-" fields, of the same type, is
undefined.
In the remainder of this specification, occurrence of legal
"Resent-" fields are treated identically with the occurrence of
August 13, 1982 - 19 - RFC #822
Standard for ARPA Internet Text Messages
fields whose names do not contain this prefix.
4.3. TRACE FIELDS
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
The list of known "via" and "with" values are registered
with the Network Information Center, SRI International, Menlo
Park, California.
4.3.1. RETURN-PATH
This field is added by the final transport system that
delivers the message to its recipient. The field is intended
to contain definitive information about the address and route
back to the message's originator.
Note: The "Reply-To" field is added by the originator and
serves to direct replies, whereas the "Return-Path"
field is used to identify a path back to the origina-
tor.
While the syntax indicates that a route specification is
optional, every attempt should be made to provide that infor-
mation in this field.
4.3.2. RECEIVED
A copy of this field is added by each transport service that
relays the message. The information in the field can be quite
useful for tracing transport problems.
The names of the sending and receiving hosts and time-of-
receipt may be specified. The "via" parameter may be used, to
indicate what physical mechanism the message was sent over,
such as Arpanet or Phonenet, and the "with" parameter may be
used to indicate the mail-, or connection-, level protocol
that was used, such as the SMTP mail protocol, or X.25 tran-
sport protocol.
Note: Several "with" parameters may be included, to fully
specify the set of protocols that were used.
Some transport services queue mail; the internal message iden-
tifier that is assigned to the message may be noted, using the
"id" parameter. When the sending host uses a destination
address specification that the receiving host reinterprets, by
August 13, 1982 - 20 - RFC #822
Standard for ARPA Internet Text Messages
expansion or transformation, the receiving host may wish to
record the original specification, using the "for" parameter.
For example, when a copy of mail is sent to the member of a
distribution list, this parameter may be used to record the
original address that was used to specify the list.
4.4. ORIGINATOR FIELDS
The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
4.4.2. SENDER / RESENT-SENDER
This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.
The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.
August 13, 1982 - 21 - RFC #822
Standard for ARPA Internet Text Messages
Since the critical function served by the "Sender" field is
identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their
behavior, it is strongly recommended that when a computer pro-
gram generates a message, the HUMAN who is responsible for
that program be referenced as part of the "Sender" field mail-
box specification.
4.4.3. REPLY-TO / RESENT-REPLY-TO
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.
Note: The "Return-Path" field is added by the mail transport
service, at the time of final deliver. It is intended
to identify a path back to the orginator of the mes-
sage. The "Reply-To" field is added by the message
originator and is intended to direct replies.
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
For systems which automatically generate address lists for
replies to messages, the following recommendations are made:
o The "Sender" field mailbox should be sent notices of
any problems in transport or delivery of the original
messages. If there is no "Sender" field, then the
"From" field mailbox should be used.
o The "Sender" field mailbox should NEVER be used
automatically, in a recipient's reply message.
o If the "Reply-To" field exists, then the reply should
go to the addresses indicated in that field and not to
the address(es) indicated in the "From" field.
August 13, 1982 - 22 - RFC #822
Standard for ARPA Internet Text Messages
o If there is a "From" field, but no "Reply-To" field,
the reply should be sent to the address(es) indicated
in the "From" field.
Sometimes, a recipient may actually wish to communicate with
the person that initiated the message transfer. In such
cases, it is reasonable to use the "Sender" address.
This recommendation is intended only for automated use of
originator-fields and is not intended to suggest that replies
may not also be sent to other recipients of messages. It is
up to the respective mail-handling programs to decide what
additional facilities will be provided.
Examples are provided in Appendix A.
4.5. RECEIVER FIELDS
4.5.1. TO / RESENT-TO
This field contains the identity of the primary recipients of
the message.
4.5.2. CC / RESENT-CC
This field contains the identity of the secondary (informa-
tional) recipients of the message.
4.5.3. BCC / RESENT-BCC
This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.
4.6. REFERENCE FIELDS
4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
This field contains a unique identifier (the local-part
address unit) which refers to THIS version of THIS message.
The uniqueness of the message identifier is guaranteed by the
host which generates it. This identifier is intended to be
machine readable and not necessarily meaningful to humans. A
message identifier pertains to exactly one instantiation of a
particular message; subsequent revisions to the message should
August 13, 1982 - 23 - RFC #822
Standard for ARPA Internet Text Messages
each receive new message identifiers.
4.6.2. IN-REPLY-TO
The contents of this field identify previous correspon-
dence which this message answers. Note that if message iden-
tifiers are used in this field, they must use the msg-id
specification format.
4.6.3. REFERENCES
The contents of this field identify other correspondence
which this message references. Note that if message identif-
iers are used, they must use the msg-id specification format.
4.6.4. KEYWORDS
This field contains keywords or phrases, separated by
commas.
4.7. OTHER FIELDS
4.7.1. SUBJECT
This is intended to provide a summary, or indicate the
nature, of the message.
4.7.2. COMMENTS
Permits adding text comments onto the message without
disturbing the contents of the message's body.
4.7.3. ENCRYPTED
Sometimes, data encryption is used to increase the
privacy of message contents. If the body of a message has
been encrypted, to keep its contents private, the "Encrypted"
field can be used to note the fact and to indicate the nature
of the encryption. The first <word> parameter indicates the
software used to encrypt the body, and the second, optional
<word> is intended to aid the recipient in selecting the
proper decryption key. This code word may be viewed as an
index to a table of keys held by the recipient.
Note: Unfortunately, headers must contain envelope, as well
as contents, information. Consequently, it is neces-
sary that they remain unencrypted, so that mail tran-
sport services may access them. Since names,
addresses, and "Subject" field contents may contain
August 13, 1982 - 24 - RFC #822
Standard for ARPA Internet Text Messages
sensitive information, this requirement limits total
message privacy.
Names of encryption software are registered with the Net-
work Information Center, SRI International, Menlo Park, Cali-
fornia.
4.7.4. EXTENSION-FIELD
A limited number of common fields have been defined in
this document. As network mail requirements dictate, addi-
tional fields may be standardized. To provide user-defined
fields with a measure of safety, in name selection, such
extension-fields will never have names that begin with the
string "X-".
Names of Extension-fields are registered with the Network
Information Center, SRI International, Menlo Park, California.
4.7.5. USER-DEFINED-FIELD
Individual users of network mail are free to define and
use additional header fields. Such fields must have names
which are not already used in the current specification or in
any definitions of extension-fields, and the overall syntax of
these user-defined-fields must conform to this specification's
rules for delimiting and folding fields. Due to the
extension-field publishing process, the name of a user-
defined-field may be pre-empted
Note: The prefatory string "X-" will never be used in the
names of Extension-fields. This provides user-defined
fields with a protected set of names.
August 13, 1982 - 25 - RFC #822
Standard for ARPA Internet Text Messages
5. DATE AND TIME SPECIFICATION
5.1. SYNTAX
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
5.2. SEMANTICS
If included, day-of-week must be the day implied by the date
specification.
Time zone may be indicated in several ways. "UT" is Univer-
sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
mitted as a reference to Universal Time. The military standard
uses a single character for each zone. "Z" is Universal Time.
"A" indicates one hour earlier, and "M" indicates 12 hours ear-
lier; "N" is one hour later, and "Y" is 12 hours later. The
letter "J" is not used. The other remaining two forms are taken
from ANSI standard X3.51-1975. One allows explicit indication of
the amount of offset from UT; the other uses common 3-character
strings for indicating time zones in North America.
August 13, 1982 - 26 - RFC #822
Standard for ARPA Internet Text Messages
6. ADDRESS SPECIFICATION
6.1. SYNTAX
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-relative
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference
6.2. SEMANTICS
A mailbox receives mail. It is a conceptual entity which
does not necessarily pertain to file storage. For example, some
sites may choose to print mail on their line printer and deliver
the output to the addressee's desk.
A mailbox specification comprises a person, system or pro-
cess name reference, a domain-dependent string, and a name-domain
reference. The name reference is optional and is usually used to
indicate the human name of a recipient. The name-domain refer-
ence specifies a sequence of sub-domains. The domain-dependent
string is uninterpreted, except by the final sub-domain; the rest
of the mail service merely transmits it as a literal string.
6.2.1. DOMAINS
A name-domain is a set of registered (mail) names. A name-
domain specification resolves to a subordinate name-domain
specification or to a terminal domain-dependent string.
Hence, domain specification is extensible, permitting any
number of registration levels.
August 13, 1982 - 27 - RFC #822
Standard for ARPA Internet Text Messages
Name-domains model a global, logical, hierarchical addressing
scheme. The model is logical, in that an address specifica-
tion is related to name registration and is not necessarily
tied to transmission path. The model's hierarchy is a
directed graph, called an in-tree, such that there is a single
path from the root of the tree to any node in the hierarchy.
If more than one path actually exists, they are considered to
be different addresses.
The root node is common to all addresses; consequently, it is
not referenced. Its children constitute "top-level" name-
domains. Usually, a service has access to its own full domain
specification and to the names of all top-level name-domains.
The "top" of the domain addressing hierarchy -- a child of the
root -- is indicated by the right-most field, in a domain
specification. Its child is specified to the left, its child
to the left, and so on.
Some groups provide formal registration services; these con-
stitute name-domains that are independent logically of
specific machines. In addition, networks and machines impli-
citly compose name-domains, since their membership usually is
registered in name tables.
In the case of formal registration, an organization implements
a (distributed) data base which provides an address-to-route
mapping service for addresses of the form:
person@registry.organization
Note that "organization" is a logical entity, separate from
any particular communication network.
A mechanism for accessing "organization" is universally avail-
able. That mechanism, in turn, seeks an instantiation of the
registry; its location is not indicated in the address specif-
ication. It is assumed that the system which operates under
the name "organization" knows how to find a subordinate regis-
try. The registry will then use the "person" string to deter-
mine where to send the mail specification.
The latter, network-oriented case permits simple, direct,
attachment-related address specification, such as:
user@host.network
Once the network is accessed, it is expected that a message
will go directly to the host and that the host will resolve
August 13, 1982 - 28 - RFC #822
Standard for ARPA Internet Text Messages
the user name, placing the message in the user's mailbox.
6.2.2. ABBREVIATED DOMAIN SPECIFICATION
Since any number of levels is possible within the domain
hierarchy, specification of a fully qualified address can
become inconvenient. This standard permits abbreviated domain
specification, in a special case:
For the address of the sender, call the left-most
sub-domain Level N. In a header address, if all of
the sub-domains above (i.e., to the right of) Level N
are the same as those of the sender, then they do not
have to appear in the specification. Otherwise, the
address must be fully qualified.
This feature is subject to approval by local sub-
domains. Individual sub-domains may require their
member systems, which originate mail, to provide full
domain specification only. When permitted, abbrevia-
tions may be present only while the message stays
within the sub-domain of the sender.
Use of this mechanism requires the sender's sub-domain
to reserve the names of all top-level domains, so that
full specifications can be distinguished from abbrevi-
ated specifications.
For example, if a sender's address is:
sender@registry-A.registry-1.organization-X
and one recipient's address is:
recipient@registry-B.registry-1.organization-X
and another's is:
recipient@registry-C.registry-2.organization-X
then ".registry-1.organization-X" need not be specified in the
the message, but "registry-C.registry-2" DOES have to be
specified. That is, the first two addresses may be abbrevi-
ated, but the third address must be fully specified.
When a message crosses a domain boundary, all addresses must
be specified in the full format, ending with the top-level
name-domain in the right-most field. It is the responsibility
of mail forwarding services to ensure that addresses conform
August 13, 1982 - 29 - RFC #822
Standard for ARPA Internet Text Messages
with this requirement. In the case of abbreviated addresses,
the relaying service must make the necessary expansions. It
should be noted that it often is difficult for such a service
to locate all occurrences of address abbreviations. For exam-
ple, it will not be possible to find such abbreviations within
the body of the message. The "Return-Path" field can aid
recipients in recovering from these errors.
Note: When passing any portion of an addr-spec onto a process
which does not interpret data according to this stan-
dard (e.g., mail protocol servers). There must be NO
LWSP-chars preceding or following the at-sign or any
delimiting period ("."), such as shown in the above
examples, and only ONE SPACE between contiguous
<word>s.
6.2.3. DOMAIN TERMS
A domain-ref must be THE official name of a registry, network,
or host. It is a symbolic reference, within a name sub-
domain. At times, it is necessary to bypass standard mechan-
isms for resolving such references, using more primitive
information, such as a network host address rather than its
associated host name.
To permit such references, this standard provides the domain-
literal construct. Its contents must conform with the needs
of the sub-domain in which it is interpreted.
Domain-literals which refer to domains within the ARPA Inter-
net specify 32-bit Internet addresses, in four 8-bit fields
noted in decimal, as described in Request for Comments #820,
"Assigned Numbers." For example:
[10.0.3.19]
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
is permitted only as a means of bypassing temporary
system limitations, such as name tables which are not
complete.
The names of "top-level" domains, and the names of domains
under in the ARPA Internet, are registered with the Network
Information Center, SRI International, Menlo Park, California.
6.2.4. DOMAIN-DEPENDENT LOCAL STRING
The local-part of an addr-spec in a mailbox specification
(i.e., the host's name for the mailbox) is understood to be
August 13, 1982 - 30 - RFC #822
Standard for ARPA Internet Text Messages
whatever the receiving mail protocol server allows. For exam-
ple, some systems do not understand mailbox references of the
form "P. D. Q. Bach", but others do.
This specification treats periods (".") as lexical separators.
Hence, their presence in local-parts which are not quoted-
strings, is detected. However, such occurrences carry NO
semantics. That is, if a local-part has periods within it, an
address parser will divide the local-part into several tokens,
but the sequence of tokens will be treated as one uninter-
preted unit. The sequence will be re-assembled, when the
address is passed outside of the system such as to a mail pro-
tocol service.
For example, the address:
First.Last@Registry.Org
is legal and does not require the local-part to be surrounded
with quotation-marks. (However, "First Last" DOES require
quoting.) The local-part of the address, when passed outside
of the mail system, within the Registry.Org domain, is
"First.Last", again without quotation marks.
6.2.5. BALANCING LOCAL-PART AND DOMAIN
In some cases, the boundary between local-part and domain can
be flexible. The local-part may be a simple string, which is
used for the final determination of the recipient's mailbox.
All other levels of reference are, therefore, part of the
domain.
For some systems, in the case of abbreviated reference to the
local and subordinate sub-domains, it may be possible to
specify only one reference within the domain part and place
the other, subordinate name-domain references within the
local-part. This would appear as:
mailbox.sub1.sub2@this-domain
Such a specification would be acceptable to address parsers
which conform to RFC #733, but do not support this newer
Internet standard. While contrary to the intent of this stan-
dard, the form is legal.
Also, some sub-domains have a specification syntax which does
not conform to this standard. For example:
sub-net.mailbox@sub-domain.domain
August 13, 1982 - 31 - RFC #822
Standard for ARPA Internet Text Messages
uses a different parsing sequence for local-part than for
domain.
Note: As a rule, the domain specification should contain
fields which are encoded according to the syntax of
this standard and which contain generally-standardized
information. The local-part specification should con-
tain only that portion of the address which deviates
from the form or intention of the domain field.
6.2.6. MULTIPLE MAILBOXES
An individual may have several mailboxes and wish to receive
mail at whatever mailbox is convenient for the sender to
access. This standard does not provide a means of specifying
"any member of" a list of mailboxes.
A set of individuals may wish to receive mail as a single unit
(i.e., a distribution list). The <group> construct permits
specification of such a list. Recipient mailboxes are speci-
fied within the bracketed part (":" - ";"). A copy of the
transmitted message is to be sent to each mailbox listed.
This standard does not permit recursive specification of
groups within groups.
While a list must be named, it is not required that the con-
tents of the list be included. In this case, the <address>
serves only as an indication of group distribution and would
appear in the form:
name:;
Some mail services may provide a group-list distribution
facility, accepting a single mailbox reference, expanding it
to the full distribution list, and relaying the mail to the
list's members. This standard provides no additional syntax
for indicating such a service. Using the <group> address
alternative, while listing one mailbox in it, can mean either
that the mailbox reference will be expanded to a list or that
there is a group with one member.
6.2.7. EXPLICIT PATH SPECIFICATION
At times, a message originator may wish to indicate the
transmission path that a message should follow. This is
called source routing. The normal addressing scheme, used in
an addr-spec, is carefully separated from such information;
the <route> portion of a route-addr is provided for such occa-
sions. It specifies the sequence of hosts and/or transmission
August 13, 1982 - 32 - RFC #822
Standard for ARPA Internet Text Messages
services that are to be traversed. Both domain-refs and
domain-literals may be used.
Note: The use of source routing is discouraged. Unless the
sender has special need of path restriction, the choice
of transmission route should be left to the mail tran-
sport service.
6.3. RESERVED ADDRESS
It often is necessary to send mail to a site, without know-
ing any of its valid addresses. For example, there may be mail
system dysfunctions, or a user may wish to find out a person's
correct address, at that site.
This standard specifies a single, reserved mailbox address
(local-part) which is to be valid at each site. Mail sent to
that address is to be routed to a person responsible for the
site's mail system or to a person with responsibility for general
site operation. The name of the reserved local-part address is:
Postmaster
so that "Postmaster@domain" is required to be valid.
Note: This reserved local-part must be matched without sensi-
tivity to alphabetic case, so that "POSTMASTER", "postmas-
ter", and even "poStmASteR" is to be accepted.
August 13, 1982 - 33 - RFC #822
Standard for ARPA Internet Text Messages
7. BIBLIOGRAPHY
ANSI. "USA Standard Code for Information Interchange," X3.4.
American National Standards Institute: New York (1968). Also
in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand-
book", NIC 7104.
ANSI. "Representations of Universal Time, Local Time Differen-
tials, and United States Time Zone References for Information
Interchange," X3.51-1975. American National Standards Insti-
tute: New York (1975).
Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
1979).
Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
ford and Appleton Laboratory: Didcot, England.
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
"Standardizing Network Mail Headers," ARPANET Request for
Comments No. 561, Network Information Center No. 18516; SRI
International: Menlo Park (September 1973).
Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D.
"Grapevine: An Exercise in Distributed Computing," Communica-
tions of the ACM 25, 4 (April 1982), 260-274.
Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A.
"Standard for the Format of ARPA Network Text Message,"
ARPANET Request for Comments No. 733, Network Information
Center No. 41952. SRI International: Menlo Park (November
1977).
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net-
work Information Center No. 7104 (NTIS AD A003890). SRI
International: Menlo Park (April 1976).
Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
(1969).
Levin, R. and Schroeder, M. "Transport of Electronic Messages
through a Network," TeleInformatics 79, pp. 29-33. North
Holland (1979). Also as Xerox Palo Alto Research Center
Technical Report CSL-79-4.
Myer, T.H. and Henderson, D.A. "Message Transmission Protocol,"
ARPANET Request for Comments, No. 680, Network Information
Center No. 32116. SRI International: Menlo Park (1975).
August 13, 1982 - 34 - RFC #822
Standard for ARPA Internet Text Messages
NBS. "Specification of Message Format for Computer Based Message
Systems, Recommended Federal Information Processing Standard."
National Bureau of Standards: Gaithersburg, Maryland
(October 1981).
NIC. Internet Protocol Transition Workbook. Network Information
Center, SRI-International, Menlo Park, California (March
1982).
Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized
Agent for Locating Named Objects in a Distributed Environ-
ment," OPD-T8103. Xerox Office Products Division: Palo Alto,
CA. (October 1981).
Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
No. 820. SRI International: Menlo Park (August 1982).
Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
for Comments, No. 821. SRI International: Menlo Park (August
1982).
Shoch, J.F. "Internetwork naming, addressing and routing," in
Proc. 17th IEEE Computer Society International Conference, pp.
72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
Su, Z. and Postel, J. "The Domain Naming Convention for Internet
User Applications," ARPANET Request for Comments, No. 819.
SRI International: Menlo Park (August 1982).
August 13, 1982 - 35 - RFC #822
Standard for ARPA Internet Text Messages
APPENDIX
A. EXAMPLES
A.1. ADDRESSES
A.1.1. Alfred Neuman <Ne...@BBN-TENEXA>
A.1.2. Neuman@BBN-TENEXA
These two "Alfred Neuman" examples have identical seman-
tics, as far as the operation of the local host's mail sending
(distribution) program (also sometimes called its "mailer")
and the remote host's mail protocol server are concerned. In
the first example, the "Alfred Neuman" is ignored by the
mailer, as "Neuman@BBN-TENEXA" completely specifies the reci-
pient. The second example contains no superfluous informa-
tion, and, again, "Neuman@BBN-TENEXA" is the intended reci-
pient.
Note: When the message crosses name-domain boundaries, then
these specifications must be changed, so as to indicate
the remainder of the hierarchy, starting with the top
level.
A.1.3. "George, Ted" <Sh...@Group.Arpanet>
This form might be used to indicate that a single mailbox
is shared by several users. The quoted string is ignored by
the originating host's mailer, because "Shared@Group.Arpanet"
completely specifies the destination mailbox.
A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
The "(the Stilt)" is a comment, which is NOT included in
the destination mailbox address handed to the originating
system's mailer. The local-part of the address is the string
"Wilt.Chamberlain", with NO space between the first and second
words.
A.1.5. Address Lists
Gourmets: Pompous Person <Wh...@Cordon-Bleu>,
Childs@WGBH.Boston, Galloping Gourmet@
ANT.Down-Under (Australian National Television),
Cheapie@Discount-Liquors;,
Cruisers: Port@Portugal, Jones@SEA;,
Another@Somewhere.SomeOrg
August 13, 1982 - 36 - RFC #822
Standard for ARPA Internet Text Messages
This group list example points out the use of comments and the
mixing of addresses and groups.
A.2. ORIGINATOR ITEMS
A.2.1. Author-sent
George Jones logs into his host as "Jones". He sends
mail himself.
From: Jones@Group.Org
or
From: George Jones <Jo...@Group.Org>
A.2.2. Secretary-sent
George Jones logs in as Jones on his host. His secre-
tary, who logs in as Secy sends mail for him. Replies to the
mail should go to George.
From: George Jones <Jo...@Group>
Sender: Secy@Other-Group
A.2.3. Secretary-sent, for user of shared directory
George Jones' secretary sends mail for George. Replies
should go to George.
From: George Jones<Sh...@Group.Org>
Sender: Secy@Other-Group
Note that there need not be a space between "Jones" and the
"<", but adding a space enhances readability (as is the case
in other examples.
A.2.4. Committee activity, with one author
George is a member of a committee. He wishes to have any
replies to his message go to all committee members.
From: George Jones <Jo...@Host.Net>
Sender: Jones@Host
Reply-To: The Committee: Jones@Host.Net,
Smith@Other.Org,
Doe@Somewhere-Else;
Note that if George had not included himself in the
August 13, 1982 - 37 - RFC #822
Standard for ARPA Internet Text Messages
enumeration of The Committee, he would not have gotten an
implicit reply; the presence of the "Reply-to" field SUPER-
SEDES the sending of a reply to the person named in the "From"
field.
A.2.5. Secretary acting as full agent of author
George Jones asks his secretary (Secy@Host) to send a
message for him in his capacity as Group. He wants his secre-
tary to handle all replies.
From: George Jones <Gr...@Host>
Sender: Secy@Host
Reply-To: Secy@Host
A.2.6. Agent for user without online mailbox
A friend of George's, Sarah, is visiting. George's
secretary sends some mail to a friend of Sarah in computer-
land. Replies should go to George, whose mailbox is Jones at
Registry.
From: Sarah Friendly <Se...@Registry>
Sender: Secy-Name <Se...@Registry>
Reply-To: Jones@Registry.
A.2.7. Agent for member of a committee
George's secretary sends out a message which was authored
jointly by all the members of a committee. Note that the name
of the committee cannot be specified, since <group> names are
not permitted in the From field.
From: Jones@Host,
Smith@Other-Host,
Doe@Somewhere-Else
Sender: Secy@SHost
August 13, 1982 - 38 - RFC #822
Standard for ARPA Internet Text Messages
A.3. COMPLETE HEADERS
A.3.1. Minimum required
Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org or From: Jones@Registry.Org
Bcc: To: Smith@Registry.Org
Note that the "Bcc" field may be empty, while the "To" field
is required to have at least one address.
A.3.2. Using some of the additional fields
Date: 26 Aug 76 1430 EDT
From: George Jones<Gr...@Host>
Sender: Secy@SHOST
To: "Al Neuman"@Mad-Host,
Sam.Irving@Other-Host
Message-ID: <so...@SHOST>
A.3.3. About as complex as you're going to get
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KD...@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Gr...@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Ba...@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jo...@Tops-20-Host>;
Comment : Sam is away on business. He asked me to handle
his mail for him. He'll be able to provide a
more accurate explanation when he returns
next week.
In-Reply-To: <so...@DBM.Group>, George's message
X-Special-action: This is a sample of user-defined field-
names. There could also be a field-name
"Special-action", but its name might later be
preempted
Message-ID: <42...@Other-Host>
August 13, 1982 - 39 - RFC #822
Standard for ARPA Internet Text Messages
B. SIMPLE FIELD PARSING
Some mail-reading software systems may wish to perform only
minimal processing, ignoring the internal syntax of structured
field-bodies and treating them the same as unstructured-field-
bodies. Such software will need only to distinguish:
o Header fields from the message body,
o Beginnings of fields from lines which continue fields,
o Field-names from field-contents.
The abbreviated set of syntactic rules which follows will
suffice for this purpose. It describes a limited view of mes-
sages and is a subset of the syntactic rules provided in the main
part of this specification. One small exception is that the con-
tents of field-bodies consist only of text:
B.1. SYNTAX
message = *field *(CRLF *text)
field = field-name ":" [field-body] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = *text [CRLF LWSP-char field-body]
B.2. SEMANTICS
Headers occur before the message body and are terminated by
a null line (i.e., two contiguous CRLFs).
A line which continues a header field begins with a SPACE or
HTAB character, while a line beginning a field starts with a
printable character which is not a colon.
A field-name consists of one or more printable characters
(excluding colon, space, and control-characters). A field-name
MUST be contained on one line. Upper and lower case are not dis-
tinguished when comparing field-names.
August 13, 1982 - 40 - RFC #822
Standard for ARPA Internet Text Messages
C. DIFFERENCES FROM RFC #733
The following summarizes the differences between this stan-
dard and the one specified in Arpanet Request for Comments #733,
"Standard for the Format of ARPA Network Text Messages". The
differences are listed in the order of their occurrence in the
current specification.
C.1. FIELD DEFINITIONS
C.1.1. FIELD NAMES
These now must be a sequence of printable characters. They
may not contain any LWSP-chars.
C.2. LEXICAL TOKENS
C.2.1. SPECIALS
The characters period ("."), left-square bracket ("["), and
right-square bracket ("]") have been added. For presentation
purposes, and when passing a specification to a system that
does not conform to this standard, periods are to be contigu-
ous with their surrounding lexical tokens. No linear-white-
space is permitted between them. The presence of one LWSP-
char between other tokens is still directed.
C.2.2. ATOM
Atoms may not contain SPACE.
C.2.3. SPECIAL TEXT
ctext and qtext have had backslash ("\") added to the list of
prohibited characters.
C.2.4. DOMAINS
The lexical tokens <domain-literal> and <dtext> have been
added.
C.3. MESSAGE SPECIFICATION
C.3.1. TRACE
The "Return-path:" and "Received:" fields have been specified.
August 13, 1982 - 41 - RFC #822
Standard for ARPA Internet Text Messages
C.3.2. FROM
The "From" field must contain machine-usable addresses (addr-
spec). Multiple addresses may be specified, but named-lists
(groups) may not.
C.3.3. RESENT
The meta-construct of prefacing field names with the string
"Resent-" has been added, to indicate that a message has been
forwarded by an intermediate recipient.
C.3.4. DESTINATION
A message must contain at least one destination address field.
"To" and "CC" are required to contain at least one address.
C.3.5. IN-REPLY-TO
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
C.3.6. REFERENCE
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
C.3.7. ENCRYPTED
A field has been specified that permits senders to indicate
that the body of a message has been encrypted.
C.3.8. EXTENSION-FIELD
Extension fields are prohibited from beginning with the char-
acters "X-".
C.4. DATE AND TIME SPECIFICATION
C.4.1. SIMPLIFICATION
Fewer optional forms are permitted and the list of three-
letter time zones has been shortened.
C.5. ADDRESS SPECIFICATION
August 13, 1982 - 42 - RFC #822
Standard for ARPA Internet Text Messages
C.5.1. ADDRESS
The use of quoted-string, and the ":"-atom-":" construct, have
been removed. An address now is either a single mailbox
reference or is a named list of addresses. The latter indi-
cates a group distribution.
C.5.2. GROUPS
Group lists are now required to to have a name. Group lists
may not be nested.
C.5.3. MAILBOX
A mailbox specification may indicate a person's name, as
before. Such a named list no longer may specify multiple
mailboxes and may not be nested.
C.5.4. ROUTE ADDRESSING
Addresses now are taken to be absolute, global specifications,
independent of transmission paths. The <route> construct has
been provided, to permit explicit specification of transmis-
sion path. RFC #733's use of multiple at-signs ("@") was
intended as a general syntax for indicating routing and/or
hierarchical addressing. The current standard separates these
specifications and only one at-sign is permitted.
C.5.5. AT-SIGN
The string " at " no longer is used as an address delimiter.
Only at-sign ("@") serves the function.
C.5.6. DOMAINS
Hierarchical, logical name-domains have been added.
C.6. RESERVED ADDRESS
The local-part "Postmaster" has been reserved, so that users can
be guaranteed at least one valid address at a site.
August 13, 1982 - 43 - RFC #822
Standard for ARPA Internet Text Messages
D. ALPHABETICAL LISTING OF SYNTAX RULES
address = mailbox ; one addressee
/ group ; named list
addr-spec = local-part "@" domain ; global address
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
atom = 1*<any CHAR except specials, SPACE and CTLs>
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
comment = "(" *(ctext / quoted-pair / comment) ")"
CR = <ASCII CR, carriage return> ; ( 15, 13.)
CRLF = CR LF
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
dates = orig-date ; Original
[ resent-date ] ; Forwarded
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
delimiters = specials / linear-white-space / comment
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; symbolic reference
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
August 13, 1982 - 44 - RFC #822
Standard for ARPA Internet Text Messages
field = field-name ":" [ field-body ] CRLF
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
local-part = word *("." word) ; uninterpreted
; case-preserved
LWSP-char = SPACE / HTAB ; semantics = SPACE
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
msg-id = "<" addr-spec ">" ; Unique message id
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
orig-date = "Date" ":" date-time
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
phrase = 1*word ; Sequence of words
August 13, 1982 - 45 - RFC #822
Standard for ARPA Internet Text Messages
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
";" date-time ; time received
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
resent-date = "Resent-Date" ":" date-time
return = "Return-path" ":" route-addr ; return address
route = 1#("@" domain) ":" ; path-relative
route-addr = "<" [route] addr-spec ">"
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
time = hour zone ; ANSI and Military
trace = return ; path to sender
1*received ; receipt tags
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
word = atom / quoted-string
August 13, 1982 - 46 - RFC #822
Standard for ARPA Internet Text Messages
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
<"> = <ASCII quote mark> ; ( 42, 34.)
August 13, 1982 - 47 - RFC #822
1.1 jakarta-james/www/rfclist/rfc977.txt
Index: rfc977.txt
===================================================================
Network Working Group Brian Kantor (U.C. San Diego)
Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
February 1986
Network News Transfer Protocol
A Proposed Standard for the Stream-Based
Transmission of News
Status of This Memo
NNTP specifies a protocol for the distribution, inquiry, retrieval,
and posting of news articles using a reliable stream-based
transmission of news among the ARPA-Internet community. NNTP is
designed so that news articles are stored in a central database
allowing a subscriber to select only those items he wishes to read.
Indexing, cross-referencing, and expiration of aged messages are also
provided. This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
1. Introduction
For many years, the ARPA-Internet community has supported the
distribution of bulletins, information, and data in a timely fashion
to thousands of participants. We collectively refer to such items of
information as "news". Such news provides for the rapid
dissemination of items of interest such as software bug fixes, new
product reviews, technical tips, and programming pointers, as well as
rapid-fire discussions of matters of concern to the working computer
professional. News is very popular among its readers.
There are popularly two methods of distributing such news: the
Internet method of direct mailing, and the USENET news system.
1.1. Internet Mailing Lists
The Internet community distributes news by the use of mailing lists.
These are lists of subscriber's mailbox addresses and remailing
sublists of all intended recipients. These mailing lists operate by
remailing a copy of the information to be distributed to each
subscriber on the mailing list. Such remailing is inefficient when a
mailing list grows beyond a dozen or so people, since sending a
separate copy to each of the subscribers occupies large quantities of
network bandwidth, CPU resources, and significant amounts of disk
storage at the destination host. There is also a significant problem
in maintenance of the list itself: as subscribers move from one job
to another; as new subscribers join and old ones leave; and as hosts
come in and out of service.
Kantor & Lapsley [Page 1]
RFC 977 February 1986
Network News Transfer Protocol
1.2. The USENET News System
Clearly, a worthwhile reduction of the amount of these resources used
can be achieved if articles are stored in a central database on the
receiving host instead of in each subscriber's mailbox. The USENET
news system provides a method of doing just this. There is a central
repository of the news articles in one place (customarily a spool
directory of some sort), and a set of programs that allow a
subscriber to select those items he wishes to read. Indexing,
cross-referencing, and expiration of aged messages are also provided.
1.3. Central Storage of News
For clusters of hosts connected together by fast local area networks
(such as Ethernet), it makes even more sense to consolidate news
distribution onto one (or a very few) hosts, and to allow access to
these news articles using a server and client model. Subscribers may
then request only the articles they wish to see, without having to
wastefully duplicate the storage of a copy of each item on each host.
1.4. A Central News Server
A way to achieve these economies is to have a central computer system
that can provide news service to the other systems on the local area
network. Such a server would manage the collection of news articles
and index files, with each person who desires to read news bulletins
doing so over the LAN. For a large cluster of computer systems, the
savings in total disk space is clearly worthwhile. Also, this allows
workstations with limited disk storage space to participate in the
news without incoming items consuming oppressive amounts of the
workstation's disk storage.
We have heard rumors of somewhat successful attempts to provide
centralized news service using IBIS and other shared or distributed
file systems. While it is possible that such a distributed file
system implementation might work well with a group of similar
computers running nearly identical operating systems, such a scheme
is not general enough to offer service to a wide range of client
systems, especially when many diverse operating systems may be in use
among a group of clients. There are few (if any) shared or networked
file systems that can offer the generality of service that stream
connections using Internet TCP provide, particularly when a wide
range of host hardware and operating systems are considered.
NNTP specifies a protocol for the distribution, inquiry, retrieval,
and posting of news articles using a reliable stream (such as TCP)
server-client model. NNTP is designed so that news articles need only
Kantor & Lapsley [Page 2]
RFC 977 February 1986
Network News Transfer Protocol
be stored on one (presumably central) host, and subscribers on other
hosts attached to the LAN may read news articles using stream
connections to the news host.
NNTP is modelled upon the news article specifications in RFC 850,
which describes the USENET news system. However, NNTP makes few
demands upon the structure, content, or storage of news articles, and
thus we believe it easily can be adapted to other non-USENET news
systems.
Typically, the NNTP server runs as a background process on one host,
and would accept connections from other hosts on the LAN. This works
well when there are a number of small computer systems (such as
workstations, with only one or at most a few users each), and a large
central server.
1.5. Intermediate News Servers
For clusters of machines with many users (as might be the case in a
university or large industrial environment), an intermediate server
might be used. This intermediate or "slave" server runs on each
computer system, and is responsible for mediating news reading
requests and performing local caching of recently-retrieved news
articles.
Typically, a client attempting to obtain news service would first
attempt to connect to the news service port on the local machine. If
this attempt were unsuccessful, indicating a failed server, an
installation might choose to either deny news access, or to permit
connection to the central "master" news server.
For workstations or other small systems, direct connection to the
master server would probably be the normal manner of operation.
This specification does not cover the operation of slave NNTP
servers. We merely suggest that slave servers are a logical addition
to NNTP server usage which would enhance operation on large local
area networks.
1.6. News Distribution
NNTP has commands which provide a straightforward method of
exchanging articles between cooperating hosts. Hosts which are well
connected on a local area or other fast network and who wish to
actually obtain copies of news articles for local storage might well
find NNTP to be a more efficient way to distribute news than more
traditional transfer methods (such as UUCP).
Kantor & Lapsley [Page 3]
RFC 977 February 1986
Network News Transfer Protocol
In the traditional method of distributing news articles, news is
propagated from host to host by flooding - that is, each host will
send all its new news articles on to each host that it feeds. These
hosts will then in turn send these new articles on to other hosts
that they feed. Clearly, sending articles that a host already has
obtained a copy of from another feed (many hosts that receive news
are redundantly fed) again is a waste of time and communications
resources, but for transport mechanisms that are single-transaction
based rather than interactive (such as UUCP in the UNIX-world <1>),
distribution time is diminished by sending all articles and having
the receiving host simply discard the duplicates. This is an
especially true when communications sessions are limited to once a
day.
Using NNTP, hosts exchanging news articles have an interactive
mechanism for deciding which articles are to be transmitted. A host
desiring new news, or which has new news to send, will typically
contact one or more of its neighbors using NNTP. First it will
inquire if any new news groups have been created on the serving host
by means of the NEWGROUPS command. If so, and those are appropriate
or desired (as established by local site-dependent rules), those new
newsgroups can be created.
The client host will then inquire as to which new articles have
arrived in all or some of the newsgroups that it desires to receive,
using the NEWNEWS command. It will receive a list of new articles
from the server, and can request transmission of those articles that
it desires and does not already have.
Finally, the client can advise the server of those new articles which
the client has recently received. The server will indicate those
articles that it has already obtained copies of, and which articles
should be sent to add to its collection.
In this manner, only those articles which are not duplicates and
which are desired are transferred.
Kantor & Lapsley [Page 4]
RFC 977 February 1986
Network News Transfer Protocol
2. The NNTP Specification
2.1. Overview
The news server specified by this document uses a stream connection
(such as TCP) and SMTP-like commands and responses. It is designed
to accept connections from hosts, and to provide a simple interface
to the news database.
This server is only an interface between programs and the news
databases. It does not perform any user interaction or presentation-
level functions. These "user-friendly" functions are better left to
the client programs, which have a better understanding of the
environment in which they are operating.
When used via Internet TCP, the contact port assigned for this
service is 119.
2.2. Character Codes
Commands and replies are composed of characters from the ASCII
character set. 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.
2.3. Commands
Commands consist of a command word, which in some cases may be
followed by a parameter. Commands with parameters must separate the
parameters from each other and from the command by one or more space
or tab characters. Command lines must be complete with all required
parameters, and may not contain more than one command.
Commands and command parameters are not case sensitive. That is, a
command or parameter word may be upper case, lower case, or any
mixture of upper and lower case.
Each command line must be terminated by a CR-LF (Carriage Return -
Line Feed) pair.
Command lines shall not exceed 512 characters in length, counting all
characters including spaces, separators, punctuation, and the
trailing CR-LF (thus there are 510 characters maximum allowed for the
command and its parameters). There is no provision for continuation
command lines.
Kantor & Lapsley [Page 5]
RFC 977 February 1986
Network News Transfer Protocol
2.4. Responses
Responses are of two kinds, textual and status.
2.4.1. Text Responses
Text is sent only after a numeric status response line has been sent
that indicates that text will follow. Text is sent as a series of
successive lines of textual matter, each terminated with CR-LF pair.
A single line containing only a period (.) is sent to indicate the
end of the text (i.e., the server will send a CR-LF pair at the end
of the last line of text, a period, and another CR-LF pair).
If the text contained a period as the first character of the text
line in the original, that first period is doubled. Therefore, the
client must examine the first character of each line received, and
for those beginning with a period, determine either that this is the
end of the text or whether to collapse the doubled period to a single
one.
The intention is that text messages will usually be displayed on the
user's terminal whereas command/status responses will be interpreted
by the client program before any possible display is done.
2.4.2. Status Responses
These are status reports from the server and indicate the response to
the last command received from the client.
Status response lines begin with a 3 digit numeric code which is
sufficient to distinguish all responses. Some of these may herald
the subsequent transmission of text.
The first digit of the response broadly indicates the success,
failure, or progress of the previous command.
1xx - Informative message
2xx - Command ok
3xx - Command ok so far, send the rest of it.
4xx - Command was correct, but couldn't be performed for
some reason.
5xx - Command unimplemented, or incorrect, or a serious
program error occurred.
Kantor & Lapsley [Page 6]
RFC 977 February 1986
Network News Transfer Protocol
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 - Nonstandard (private implementation) extensions
x9x - Debugging output
The exact response codes that should be expected from each command
are detailed in the description of that command. In addition, below
is listed a general set of response codes that may be received at any
time.
Certain status responses contain parameters such as numbers and
names. The number and type of such parameters is fixed for each
response code to simplify interpretation of the response.
Parameters are separated from the numeric response code and from each
other by a single space. All numeric parameters are decimal, and may
have leading zeros. All string parameters begin after the separating
space, and end before the following separating space or the CR-LF
pair at the end of the line. (String parameters may not, therefore,
contain spaces.) All text, if any, in the response which is not a
parameter of the response must follow and be separated from the last
parameter by a space. Also, note that the text following a response
number may vary in different implementations of the server. The
3-digit numeric code should be used to determine what response was
sent.
Response codes not specified in this standard may be used for any
installation-specific additional commands also not specified. These
should be chosen to fit the pattern of x8x specified above. (Note
that debugging is provided for explicitly in the x9x response codes.)
The use of unspecified response codes for standard commands is
prohibited.
We have provided a response pattern x9x for debugging. Since much
debugging output may be classed as "informative messages", we would
expect, therefore, that responses 190 through 199 would be used for
various debugging outputs. There is no requirement in this
specification for debugging output, but if such is provided over the
connected stream, it must use these response codes. If appropriate
to a specific implementation, other x9x codes may be used for
debugging. (An example might be to use e.g., 290 to acknowledge a
remote debugging request.)
Kantor & Lapsley [Page 7]
RFC 977 February 1986
Network News Transfer Protocol
2.4.3. General Responses
The following is a list of general response codes that may be sent by
the NNTP server. These are not specific to any one command, but may
be returned as the result of a connection, a failure, or some unusual
condition.
In general, 1xx codes may be ignored or displayed as desired; code
200 or 201 is sent upon initial connection to the NNTP server
depending upon posting permission; code 400 will be sent when the
NNTP server discontinues service (by operator request, for example);
and 5xx codes indicate that the command could not be performed for
some unusual reason.
100 help text
190
through
199 debug output
200 server ready - posting allowed
201 server ready - no posting allowed
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
3. Command and Response Details
On the following pages are descriptions of each command recognized by
the NNTP server and the responses which will be returned by those
commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted.
Every command described in this section must be implemented by all
NNTP servers.
Kantor & Lapsley [Page 8]
RFC 977 February 1986
Network News Transfer Protocol
There is no prohibition against additional commands being added;
however, it is recommended that any such unspecified command begin
with the letter "X" to avoid conflict with later revisions of this
specification.
Implementors are reminded that such additional commands may not
redefine specified status response codes. Using additional
unspecified responses for standard commands is also prohibited.
3.1. The ARTICLE, BODY, HEAD, and STAT commands
There are two forms to the ARTICLE command (and the related BODY,
HEAD, and STAT commands), each using a different method of specifying
which article is to be retrieved. When the ARTICLE command is
followed by a message-id in angle brackets ("<" and ">"), the first
form of the command is used; when a numeric parameter or no parameter
is supplied, the second form is invoked.
The text of the article is returned as a textual response, as
described earlier in this document.
The HEAD and BODY commands are identical to the ARTICLE command
except that they respectively return only the header lines or text
body of the article.
The STAT command is similar to the ARTICLE command except that no
text is returned. When selecting by message number within a group,
the STAT command serves to set the current article pointer without
sending text. The returned acknowledgement response will contain the
message-id, which may be of some value. Using the STAT command to
select by message-id is valid but of questionable value, since a
selection by message-id does NOT alter the "current article pointer".
3.1.1. ARTICLE (selection by message-id)
ARTICLE <message-id>
Display the header, a blank line, then the body (text) of the
specified article. Message-id is the message id of an article as
shown in that article's header. It is anticipated that the client
will obtain the message-id from a list provided by the NEWNEWS
command, from references contained within another article, or from
the message-id provided in the response to some other commands.
Please note that the internally-maintained "current article pointer"
is NOT ALTERED by this command. This is both to facilitate the
presentation of articles that may be referenced within an article
Kantor & Lapsley [Page 9]
RFC 977 February 1986
Network News Transfer Protocol
being read, and because of the semantic difficulties of determining
the proper sequence and membership of an article which may have been
posted to more than one newsgroup.
3.1.2. ARTICLE (selection by number)
ARTICLE [nnn]
Displays the header, a blank line, then the body (text) of the
current or specified article. The optional parameter nnn is the
numeric id of an article in the current newsgroup and must be chosen
from the range of articles provided when the newsgroup was selected.
If it is omitted, the current article is assumed.
The internally-maintained "current article pointer" is set by this
command if a valid article number is specified.
[the following applies to both forms of the article command.] A
response indicating the current article number, a message-id string,
and that text is to follow will be returned.
The message-id string returned is an identification string contained
within angle brackets ("<" and ">"), which is derived from the header
of the article itself. The Message-ID header line (required by
RFC850) from the article must be used to supply this information. If
the message-id header line is missing from the article, a single
digit "0" (zero) should be supplied within the angle brackets.
Since the message-id field is unique with each article, it may be
used by a news reading program to skip duplicate displays of articles
that have been posted more than once, or to more than one newsgroup.
3.1.3. Responses
220 n <a> article retrieved - head and body follow
(n = article number, <a> = message-id)
221 n <a> article retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately
412 no newsgroup has been selected
420 no current article has been selected
423 no such article number in this group
430 no such article found
Kantor & Lapsley [Page 10]
RFC 977 February 1986
Network News Transfer Protocol
3.2. The GROUP command
3.2.1. GROUP
GROUP ggg
The required parameter ggg is the name of the newsgroup to be
selected (e.g. "net.news"). A list of valid newsgroups may be
obtained from the LIST command.
The successful selection response will return the article numbers of
the first and last articles in the group, and an estimate of the
number of articles on file in the group. It is not necessary that
the estimate be correct, although that is helpful; it must only be
equal to or larger than the actual number of articles on file. (Some
implementations will actually count the number of articles on file.
Others will just subtract first article number from last to get an
estimate.)
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
newsgroup is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the newsgroup is not case-dependent. It must
otherwise match a newsgroup obtained from the LIST command or an
error will result.
3.2.2. Responses
211 n f l s group selected
(n = estimated number of articles in group,
f = first article number in the group,
l = last article number in the group,
s = name of the group.)
411 no such news group
Kantor & Lapsley [Page 11]
RFC 977 February 1986
Network News Transfer Protocol
3.3. The HELP command
3.3.1. HELP
HELP
Provides a short summary of commands that are understood by this
implementation of the server. The help text will be presented as a
textual response, terminated by a single period on a line by itself.
3.3.2. Responses
100 help text follows
3.4. The IHAVE command
3.4.1. IHAVE
IHAVE <messageid>
The IHAVE command informs the server that the client has an article
whose id is <messageid>. If the server desires a copy of that
article, it will return a response 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 response indicating
that the article is not wanted will be returned.
If transmission of the article is requested, the client should send
the entire article, including header and body, in the manner
specified for text transmission from the server. A response code
indicating success or failure of the transferral of the article will
be returned.
This function differs from the POST command in that it is intended
for use in transferring already-posted articles between hosts.
Normally it will not be used when the client is a personal
newsreading program. In particular, this function will invoke the
server's news posting program with the appropriate settings (flags,
options, etc) to indicate that the forthcoming article is being
forwarded from another host.
The server may, however, elect not to post or forward the article if
after further examination of the article it deems it inappropriate to
do so. The 436 or 437 error codes may be returned as appropriate to
the situation.
Reasons for such subsequent rejection of an article may include such
Kantor & Lapsley [Page 12]
RFC 977 February 1986
Network News Transfer Protocol
problems as inappropriate newsgroups or distributions, disk space
limitations, article lengths, garbled headers, and the like. These
are typically restrictions enforced by the server host's news
software and not necessarily the NNTP server itself.
3.4.2. Responses
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
An implementation note:
Because some host news posting software may not be able to decide
immediately that an article is inappropriate for posting or
forwarding, it is acceptable to acknowledge the successful transfer
of the article and to later silently discard it. Thus it is
permitted to return the 235 acknowledgement code and later discard
the received article. This is not a fully satisfactory solution to
the problem. Perhaps some implementations will wish to send mail to
the author of the article in certain of these cases.
3.5. The LAST command
3.5.1. LAST
LAST
The internally maintained "current article pointer" is set to the
previous article in the current newsgroup. If already positioned at
the first article of the newsgroup, an error message is returned and
the current article remains selected.
The internally-maintained "current article pointer" is set by this
command.
A response indicating the current article number, and a message-id
string will be returned. No text is sent in response to this
command.
3.5.2. Responses
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
Kantor & Lapsley [Page 13]
RFC 977 February 1986
Network News Transfer Protocol
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group
3.6. The LIST command
3.6.1. LIST
LIST
Returns a list of valid newsgroups and associated information. Each
newsgroup is sent as a line of text in the following format:
group last first p
where <group> is the name of the newsgroup, <last> is the number of
the last known article currently in that newsgroup, <first> is the
number of the first article currently in the newsgroup, and <p> is
either 'y' or 'n' indicating whether posting to this newsgroup is
allowed ('y') or prohibited ('n').
The <first> and <last> fields will always be numeric. They may have
leading zeros. If the <last> field evaluates to less than the
<first> field, there are no articles currently on file in the
newsgroup.
Note that posting may still be prohibited to a client even though the
LIST command indicates that posting is permitted to a particular
newsgroup. See the POST command for an explanation of client
prohibitions. The posting flag exists for each newsgroup because
some newsgroups are moderated or are digests, and therefore cannot be
posted to; that is, articles posted to them must be mailed to a
moderator who will post them for the submitter. This is independent
of the posting permission granted to a client by the NNTP server.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there are currently no valid newsgroups.
3.6.2. Responses
215 list of newsgroups follows
Kantor & Lapsley [Page 14]
RFC 977 February 1986
Network News Transfer Protocol
3.7. The NEWGROUPS command
3.7.1. NEWGROUPS
NEWGROUPS date time [GMT] [<distributions>]
A list of newsgroups created since <date and time> will be listed in
the same format as the LIST command.
The date is sent as 6 digits in the format YYMMDD, where YY is the
last two digits of the year, MM is the two digits of the month (with
leading zero, if appropriate), and DD is the day of the month (with
leading zero, if appropriate). The closest century is assumed as
part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
1999, 00 is 2000).
Time must also be specified. It must be as 6 digits HHMMSS with HH
being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
00-59. The time is assumed to be in the server's timezone unless the
token "GMT" appears, in which case both time and date are evaluated
at the 0 meridian.
The optional parameter "distributions" is a list of distribution
groups, enclosed in angle brackets. If specified, the distribution
portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
examined for a match with the distribution categories listed, and
only those new newsgroups which match will be listed. If more than
one distribution group is to be listed, they must be separated by
commas within the angle brackets.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there are currently no new newsgroups.
3.7.2. Responses
231 list of new newsgroups follows
Kantor & Lapsley [Page 15]
RFC 977 February 1986
Network News Transfer Protocol
3.8. The NEWNEWS command
3.8.1. NEWNEWS
NEWNEWS newsgroups date time [GMT] [<distribution>]
A list of message-ids of articles posted or received to the specified
newsgroup since "date" will be listed. The format of the listing will
be one message-id per line, as though text were being sent. A single
line consisting solely of one period followed by CR-LF will terminate
the list.
Date and time are in the same format as the NEWGROUPS command.
A newsgroup name containing a "*" (an asterisk) may be specified to
broaden the article search to some or all newsgroups. The asterisk
will be extended to match any part of a newsgroup name (e.g.,
net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
if only an asterisk is given as the newsgroup name, all newsgroups
will be searched for new news.
(Please note that the asterisk "*" expansion is a general
replacement; in particular, the specification of e.g., net.*.unix
should be correctly expanded to embrace names such as net.wombat.unix
and net.whocares.unix.)
Conversely, if no asterisk appears in a given newsgroup name, only
the specified newsgroup will be searched for new articles. Newsgroup
names must be chosen from those returned in the listing of available
groups. Multiple newsgroup names (including a "*") may be specified
in this command, separated by a comma. No comma shall appear after
the last newsgroup in the list. [Implementors are cautioned to keep
the 512 character command length limit in mind.]
The exclamation point ("!") may be used to negate a match. This can
be used to selectively omit certain newsgroups from an otherwise
larger list. For example, a newsgroups specification of
"net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
matched. If used, the exclamation point must appear as the first
character of the given newsgroup name or pattern.
The optional parameter "distributions" is a list of distribution
groups, enclosed in angle brackets. If specified, the distribution
portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
be examined for a match with the distribution categories listed, and
only those articles which have at least one newsgroup belonging to
Kantor & Lapsley [Page 16]
RFC 977 February 1986
Network News Transfer Protocol
the list of distributions will be listed. If more than one
distribution group is to be supplied, they must be separated by
commas within the angle brackets.
The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
news is discussed in an earlier part of this document.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there is currently no new news.
3.8.2. Responses
230 list of new articles by message-id follows
3.9. The NEXT command
3.9.1. NEXT
NEXT
The internally maintained "current article pointer" is advanced to
the next article in the current newsgroup. If no more articles
remain in the current group, an error message is returned and the
current article remains selected.
The internally-maintained "current article pointer" is set by this
command.
A response indicating the current article number, and the message-id
string will be returned. No text is sent in response to this
command.
3.9.2. Responses
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group
Kantor & Lapsley [Page 17]
RFC 977 February 1986
Network News Transfer Protocol
3.10. The POST command
3.10.1. POST
POST
If posting is allowed, response code 340 is returned to indicate that
the article to be posted should be sent. Response code 440 indicates
that posting is prohibited for some installation-dependent reason.
If posting is permitted, the article should be presented in the
format specified by RFC850, and should include all required header
lines. After the article's header and body have been completely sent
by the client to the server, a further response code will be returned
to indicate success or failure of the posting attempt.
The text forming the header and body of the message to be posted
should be sent by the client using the conventions for text received
from the news server: A single period (".") on a line indicates the
end of the text, with lines starting with a period in the original
text having that period doubled during transmission.
No attempt shall be made by the server to filter characters, fold or
limit lines, or otherwise process incoming text. It is our intent
that the server just pass the incoming message to be posted to the
server installation's news posting software, which is separate from
this specification. See RFC850 for more details.
Since most installations will want the client news program to allow
the user to prepare his message using some sort of text editor, and
transmit it to the server for posting only after it is composed, the
client program should take note of the herald message that greeted it
when the connection was first established. This message indicates
whether postings from that client are permitted or not, and can be
used to caution the user that his access is read-only if that is the
case. This will prevent the user from wasting a good deal of time
composing a message only to find posting of the message was denied.
The method and determination of which clients and hosts may post is
installation dependent and is not covered by this specification.
3.10.2. Responses
240 article posted ok
340 send article to be posted. End with <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
Kantor & Lapsley [Page 18]
RFC 977 February 1986
Network News Transfer Protocol
(for reference, one of the following codes will be sent upon initial
connection; the client program should determine whether posting is
generally permitted from these:) 200 server ready - posting allowed
201 server ready - no posting allowed
3.11. The QUIT command
3.11.1. QUIT
QUIT
The server process acknowledges the QUIT command and then closes the
connection to the client. This is the preferred method for a client
to indicate that it has finished all its transactions with the NNTP
server.
If a client simply disconnects (or the connection times out, or some
other fault occurs), the server should gracefully cease its attempts
to service the client.
3.11.2. Responses
205 closing connection - goodbye!
3.12. The SLAVE command
3.12.1. SLAVE
SLAVE
Indicates to the server that this client connection is to a slave
server, rather than a user.
This command is intended for use in separating connections to single
users from those to subsidiary ("slave") servers. It may be used to
indicate that priority should therefore be given to requests from
this client, as it is presumably serving more than one person. It
might also be used to determine which connections to close when
system load levels are exceeded, perhaps giving preference to slave
servers. The actual use this command is put to is entirely
implementation dependent, and may vary from one host to another. In
NNTP servers which do not give priority to slave servers, this
command must nonetheless be recognized and acknowledged.
3.12.2. Responses
202 slave status noted
Kantor & Lapsley [Page 19]
RFC 977 February 1986
Network News Transfer Protocol
4. Sample Conversations
These are samples of the conversations that might be expected with
the news server in hypothetical sessions. The notation C: indicates
commands sent to the news server from the client program; S: indicate
responses received from the server by the client.
4.1. Example 1 - relative access with NEXT
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 wombatvax news server ready - posting ok
(client asks for a current newsgroup list)
C: LIST
S: 215 list of newsgroups follows
S: net.wombats 00543 00501 y
S: net.unix-wizards 10125 10011 y
(more information here)
S: net.idiots 00100 00001 n
S: .
(client selects a newsgroup)
C: GROUP net.unix-wizards
S: 211 104 10011 10125 net.unix-wizards group selected
(there are 104 articles on file, from 10011 to 10125)
(client selects an article to read)
C: STAT 10110
S: 223 10110 <23...@sdcsvax.ARPA> article retrieved - statistics
only (article 10110 selected, its message-id is
<23...@sdcsvax.ARPA>)
(client examines the header)
C: HEAD
S: 221 10110 <23...@sdcsvax.ARPA> article retrieved - head
follows (text of the header appears here)
S: .
(client wants to see the text body of the article)
C: BODY
S: 222 10110 <23...@sdcsvax.ARPA> article retrieved - body
follows (body text here)
S: .
(client selects next article in group)
Kantor & Lapsley [Page 20]
RFC 977 February 1986
Network News Transfer Protocol
C: NEXT
S: 223 10113 <21...@nudebch.uucp> article retrieved - statistics
only (article 10113 was next in group)
(client finishes session)
C: QUIT
S: 205 goodbye.
4.2. Example 2 - absolute article access with ARTICLE
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 UCB-VAX netnews server ready -- no posting allowed
C: GROUP msgs
S: 211 103 402 504 msgs Your new group is msgs
(there are 103 articles, from 402 to 504)
C: ARTICLE 401
S: 423 No such article in this newsgroup
C: ARTICLE 402
S: 220 402 <41...@ucbvax.ARPA> Article retrieved, text follows
S: (article header and body follow)
S: .
C: HEAD 403
S: 221 403 <31...@mcvax.UUCP> Article retrieved, header follows
S: (article header follows)
S: .
C: QUIT
S: 205 UCB-VAX news server closing connection. Goodbye.
4.3. Example 3 - NEWGROUPS command
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 Imaginary Institute News Server ready (posting ok)
(client asks for new newsgroups since April 3, 1985)
C: NEWGROUPS 850403 020000
S: 231 New newsgroups since 03/04/85 02:00:00 follow
Kantor & Lapsley [Page 21]
RFC 977 February 1986
Network News Transfer Protocol
S: net.music.gdead
S: net.games.sources
S: .
C: GROUP net.music.gdead
S: 211 0 1 1 net.music.gdead Newsgroup selected
(there are no articles in that newsgroup, and
the first and last article numbers should be ignored)
C: QUIT
S: 205 Imaginary Institute news server ceasing service. Bye!
4.4. Example 4 - posting a news article
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 BANZAIVAX news server ready, posting allowed.
C: POST
S: 340 Continue posting; Period on a line by itself to end
C: (transmits news article in RFC850 format)
C: .
S: 240 Article posted successfully.
C: QUIT
S: 205 BANZAIVAX closing connection. Goodbye.
4.5. Example 5 - interruption due to operator request
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 genericvax news server ready, no posting allowed.
(assume normal conversation for some time, and
that a newsgroup has been selected)
C: NEXT
S: 223 1013 <57...@mcvax.UUCP> Article retrieved; text separate.
C: HEAD
C: 221 1013 <57...@mcvax.UUCP> Article retrieved; head follows.
S: (sends head of article, but halfway through is
interrupted by an operator request. The following
then occurs, without client intervention.)
Kantor & Lapsley [Page 22]
RFC 977 February 1986
Network News Transfer Protocol
S: (ends current line with a CR-LF pair)
S: .
S: 400 Connection closed by operator. Goodbye.
S: (closes connection)
4.6. Example 6 - Using the news server to distribute news between
systems.
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 Foobar NNTP server ready (no posting)
(client asks for new newsgroups since 2 am, May 15, 1985)
C: NEWGROUPS 850515 020000
S: 235 New newsgroups since 850515 follow
S: net.fluff
S: net.lint
S: .
(client asks for new news articles since 2 am, May 15, 1985)
C: NEWNEWS * 850515 020000
S: 230 New news since 850515 020000 follows
S: <17...@foo.UUCP>
S: <87...@baz.UUCP>
S: <17...@GOLD.CSNET>
S: .
(client asks for article <17...@foo.UUCP>)
C: ARTICLE <17...@foo.UUCP>
S: 220 <17...@foo.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <87...@baz.UUCP>
C: ARTICLE <87...@baz.UUCP>
S: 220 <87...@baz.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <17...@GOLD.CSNET>
C: ARTICLE <17...@GOLD.CSNET>
S: 220 <17...@GOLD.CSNET> All of article follows
S: (sends entire message)
S: .
Kantor & Lapsley [Page 23]
RFC 977 February 1986
Network News Transfer Protocol
(client offers an article it has received recently)
C: IHAVE <41...@ucbvax.ARPA>
S: 435 Already seen that one, where you been?
(client offers another article)
C: IHAVE <41...@ucbvax.ARPA>
S: 335 News to me! <CRLF.CRLF> to end.
C: (sends article)
C: .
S: 235 Article transferred successfully. Thanks.
(or)
S: 436 Transfer failed.
(client is all through with the session)
C: QUIT
S: 205 Foobar NNTP server bids you farewell.
4.7. Summary of commands and responses.
The following are the commands recognized and responses returned by
the NNTP server.
4.7.1. Commands
ARTICLE
BODY
GROUP
HEAD
HELP
IHAVE
LAST
LIST
NEWGROUPS
NEWNEWS
NEXT
POST
QUIT
SLAVE
STAT
4.7.2. Responses
100 help text follows
199 debug output
Kantor & Lapsley [Page 24]
RFC 977 February 1986
Network News Transfer Protocol
200 server ready - posting allowed
201 server ready - no posting allowed
202 slave status noted
205 closing connection - goodbye!
211 n f l s group selected
215 list of newsgroups follows
220 n <a> article retrieved - head and body follow 221 n <a> article
retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately 230 list of new
articles by message-id follows
231 list of new newsgroups follows
235 article transferred ok
240 article posted ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
340 send article to be posted. End with <CR-LF>.<CR-LF>
400 service discontinued
411 no such news group
412 no newsgroup has been selected
420 no current article has been selected
421 no next article in this group
422 no previous article in this group
423 no such article number in this group
430 no such article found
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again.
440 posting not allowed
441 posting failed
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
4.8. A Brief Word about the USENET News System
In the UNIX world, which traditionally has been linked by 1200 baud
dial-up telephone lines, the USENET News system has evolved to handle
central storage, indexing, retrieval, and distribution of news. With
the exception of its underlying transport mechanism (UUCP), USENET
News is an efficient means of providing news and bulletin service to
subscribers on UNIX and other hosts worldwide. The USENET News
Kantor & Lapsley [Page 25]
RFC 977 February 1986
Network News Transfer Protocol
system is discussed in detail in RFC 850. It runs on most versions
of UNIX and on many other operating systems, and is customarily
distributed without charge.
USENET uses a spooling area on the UNIX host to store news articles,
one per file. Each article consists of a series of heading text,
which contain the sender's identification and organizational
affiliation, timestamps, electronic mail reply paths, subject,
newsgroup (subject category), and the like. A complete news article
is reproduced in its entirety below. Please consult RFC 850 for more
details.
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
sdcsvax.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
!honman
From: honman@unitek.uucp (Man Wong)
Newsgroups: net.unix-wizards
Subject: foreground -> background ?
Message-ID: <16...@unitek.uucp>
Date: 25 Sep 85 23:51:52 GMT
Date-Received: 29 Sep 85 09:54:48 GMT
Reply-To: honman@unitek.UUCP (Hon-Man Wong)
Distribution: net.all
Organization: Unitek Technologies Corporation
Lines: 12
I have a process (C program) which generates a child and waits for
it to return. What I would like to do is to be able to run the
child process interactively for a while before kicking itself into
the background so I can return to the parent process (while the
child process is RUNNING in the background). Can it be done? And
if it can, how?
Please reply by E-mail. Thanks in advance.
Hon-Man Wong
Kantor & Lapsley [Page 26]
RFC 977 February 1986
Network News Transfer Protocol
5. References
[1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, Department of Electrical Engineering,
University of Delaware, August, 1982.
[2] Horton, M., "Standard for Interchange of USENET Messages",
RFC-850, USENET Project, June, 1983.
[3] Postel, J., "Transmission Control Protocol- DARPA Internet
Program Protocol Specification", RFC-793, USC/Information
Sciences Institute, September, 1981.
[4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August, 1982.
6. Acknowledgements
The authors wish to express their heartfelt thanks to those many
people who contributed to this specification, and especially to Erik
Fair and Chuq von Rospach, without whose inspiration this whole thing
would not have been necessary.
7. Notes
<1> UNIX is a trademark of Bell Laboratories.
Kantor & Lapsley [Page 27]
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org