doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1204.txt b/doc/rfc/rfc1204.txt
new file mode 100644
index 0000000..0e1a7a7
--- /dev/null
+++ b/doc/rfc/rfc1204.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                             S. Yeh
+Request for Comments: 1204                                        D. Lee
+                                              Netix Communications, Inc.
+                                                           February 1991
+
+
+                     Message Posting Protocol (MPP)
+
+Status of this Memo
+
+   This memo describes a protocol for posting messages from workstations
+   (e.g., PCs) to a mail service host.  This RFC specifies an
+   Experimental Protocol for the Internet community.  Discussion and
+   suggestions for improvement are requested.  Please refer to the
+   current edition of the "IAB Official Protocol Standards" for the
+   standardization state and status of this protocol.  Distribution of
+   this memo is unlimited.
+
+1. INTRODUCTION
+
+   Operating systems for personal computers do not provide a mechanism
+   for user authentication.  However, such a mechanism is crucial for
+   electronic mail system since authenticating message sender's identity
+   is important in preventing mail forgery.  Hence, adding personal
+   computers to an electronic mail network requires an agent (message
+   posting server) to authenticate sender's identity and then submit
+   mail to the message delivery system (e.g., Sendmail, MMDF) on behalf
+   of the sender at a PC.  The Netix Message Posting Protocol is
+   developed to be the interface between the message posting server and
+   the PC (client).  The protocol is designed to use TCP and is based on
+   the command and reply structures defined for Simple Mail Transfer
+   Protocol (RFC 821) and File Transfer Protocol (RFC 959).
+
+2. SPECIFICATIONS
+
+2.1.  Command List
+
+      USER <SP> <username> <CRLF>
+      PASS <SP> <password> <CRLF>
+      DATA <CRLF>
+      NOOP <CRLF>
+      QUIT <CRLF>
+
+2.2.  Reply List
+
+      220 Message Posting Service Ready.
+      221 Closing Connection.
+      250 Command OK.
+
+
+
+Yeh & Lee                                                       [Page 1]
+
+RFC 1204                          MPP                      February 1991
+
+
+      354 Enter mail, end with <CRLF>.<CRLF>
+      451 Local error encountered.
+      500 Command unrecognized.
+      501 Argument syntax error.
+      503 Illegal command sequence.
+      530 Authentication Failure.
+      550 Error.
+
+2.3.  Command and Reply Descriptions
+
+      USER <SP> <username> <CRLF>
+
+         The USER command informs the message posting server about the
+         username of the user trying to submit mail to the network.  The
+         required argument for the USER command is a string specifying
+         the message sender's username.
+
+         The USER command can only be used under three conditions:
+
+         - when the session with the message posting server has just
+           started;
+
+         - right after a message text (terminated by the "<CRLF>.<CRLF>"
+           sequence) has been successfully submitted to the message
+           posting server;
+
+         - right after a USER command that gets the reply code 501.
+
+         List of possible reply codes for the USER command:
+
+         - 250   The username of the message sender has been accepted.
+
+         - 451   Internal error has occurred in the message posting
+                 server.
+
+         - 501   Syntax error detected in the username argument.
+
+         - 503   The USER command has been used under an inappropriate
+                 condition (i.e., one that is not specified above).
+
+         It is recommended that the message posting server should return
+         250 even if the username is not recognized by the message
+         posting server, as long as the username is syntactically
+         correct.  This is an attempt to prevent the message posting
+         server from releasing too much information about the user
+         database.  Client should not be able to test the existence of a
+         certain username.
+
+
+
+
+Yeh & Lee                                                       [Page 2]
+
+RFC 1204                          MPP                      February 1991
+
+
+      PASS <SP> <password> <CRLF>
+
+         The PASS command is used to inform the message posting server
+         about the password associated with the username previously
+         specified.  The required argument for the PASS command is a
+         string specifying the message sender's password.
+
+         The PASS command can only be used under two conditions:
+
+         - right after a USER command that gets the reply code 250;
+
+         - right after a PASS command that gets the reply code 501.
+
+         List of possible reply codes for the PASS command:
+
+         - 250   The password has been accepted and verified to be
+                 correctly associated with the username previously
+                 specified.
+
+         - 451   Internal error has occurred in the message posting
+                 server.
+
+         - 501   Syntax error detected in the password argument.
+
+         - 503   The PASS command has been used under an inappropriate
+                 condition (i.e., one that is not specified above).
+
+         - 530   The password provided is not the one associated with the
+                 username previously specified.
+
+      DATA <CRLF>
+
+         The DATA command is used to inform the message posting server
+         to get ready to accept a mail message text.  No argument is
+         expected.  (This command has the same meaning as the DATA
+         command defined in RFC 821.)
+
+         The DATA command can only be used under two conditions:
+
+         - right after a PASS command that gets the reply code 250;
+
+         - right after a mail message text has been successfully
+           accepted from the client.
+
+         List of possible reply codes for the DATA command:
+
+         - 354   The message posting server is ready to accept the mail
+                 message text.
+
+
+
+Yeh & Lee                                                       [Page 3]
+
+RFC 1204                          MPP                      February 1991
+
+
+         - 451   Internal error has occurred in the message posting
+                 server.
+
+         - 503   The DATA command has been used under an inappropriate
+                 condition (i.e., one that is not specified above).
+
+         Upon receiving the reply code 354 for the DATA command, the
+         client should submit the mail message text to message posting
+         server and terminate the text by the sequence "<CRLF>.<CRLF>"
+         as defined in RFC 821.  If the message text includes the
+         "<CRLF>.<CRLF>" sequence, then the sequence is replaced by the
+         "<CRLF>..<CRLF>" sequence as defined in RFC 821.  The extra "."
+         token will not be included in the final copy of the submitted
+         message.
+
+         Upon receiving the mail message text terminated by the
+         "<CRLF>.<CRLF>" sequence, list of possible reply codes is:
+
+         - 250   The mail message text has been successfully queued for
+                 delivery.
+
+         - 451   Internal error has occurred in the message posting
+                 server and the mail message text has not been queued.
+
+      NOOP <CRLF>
+
+         The NOOP command does not cause any action to be performed by
+         the message posting server.  Instead, it tests the status of
+         the message posting server.  No argument is expected.
+
+         The NOOP command cannot be used under one condition:
+
+         - right after a DATA command that gets the reply code 354
+           (i.e., when the message posting server is expecting the client
+           to submit the mail message text).
+
+         List of possible reply codes for the NOOP command:
+
+         - 250   The message posting server has not encountered any
+                 internal error.
+
+         - 451   Internal error has occurred in the message posting
+                 server during the current session.
+
+      QUIT <CRLF>
+
+         The QUIT command is used to terminate the session with the
+         message posting server.  No argument is expected.
+
+
+
+Yeh & Lee                                                       [Page 4]
+
+RFC 1204                          MPP                      February 1991
+
+
+         The QUIT command can be used under any condition.  The message
+         posting server should always return the reply code 221 for the
+         QUIT command.
+
+3. IMPLEMENTATION OF THE MESSAGE POSTING SERVER
+
+   There are several issues to be considered when implementing the
+   message posting server:
+
+   - secured environment
+   - port number assignment
+   - handling of idle client
+   - local/remote password database
+   - message queuing
+   - handling of message delivery failure
+
+3.1  Secured Environment
+
+   The message posting server is responsible for authenticating message
+   senders and submitting mail to the message delivery system.  Hence,
+   it should be running in a secured environment, such as running on a
+   system (UNIX, VMS, MS-DOS) with well restricted physical and network
+   access.
+
+3.2  Port Number Assignment
+
+   Port 218 is assigned for the Netix Message Posting Protocol.
+
+3.3  Handling of Idle Client
+
+   The message posting server should terminate a session if the client
+   has been idle for too long, to release the resource allocated for the
+   session.
+
+3.4  Local/Remote Password Database
+
+   To take advantage of existing password databases, such as the passwd
+   file in UNIX, the message posting server can use FTP and POP3 to
+   perform the username and password checking with the appropriate
+   server.
+
+   For network that does not have any password database, the message
+   posting server should let the system administrator specify a local
+   password file on the host that the message posting server is running.
+
+
+
+
+
+
+
+Yeh & Lee                                                       [Page 5]
+
+RFC 1204                          MPP                      February 1991
+
+
+3.5  Message Queuing
+
+   The message posting server should attempt to submit accepted messages
+   to the message delivery system as soon as possible.
+
+3.6  Handling of Message Delivery Failure
+
+   Failure in delivering messages should be handled by the message
+   delivery system and the message posting server should not interfere.
+
+4. REFERENCES
+
+   [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+       USC/Information Sciences Institute, August 1982.
+
+   [2] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
+       USC/Information Sciences Institute, October 1985.
+
+Security Considerations
+
+   Security issues are discussed in section 3.1.
+
+Authors' Addresses
+
+   Shannon Yeh
+   Netix Communications, Inc.
+   15375 Barranca Parkway, Suite A-215
+   Irvine, CA 92718
+
+   Phone: (714) 727-9335
+
+   Email: yeh@netix.com
+
+
+   David Lee
+   Netix Communications, Inc.
+   15375 Barranca Parkway, Suite A-215
+   Irvine, CA 92718
+
+   Phone: (714) 727-9335
+
+   EMail: dlee@netix.com
+
+
+
+
+
+
+
+
+
+Yeh & Lee                                                       [Page 6]
+
\ No newline at end of file