1 files changed, 171 insertions, 0 deletions
diff --git a/doc/rfc/rfc630.txt b/doc/rfc/rfc630.txt
new file mode 100644
index 0000000..875622a
--- /dev/null
+++ b/doc/rfc/rfc630.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                     Julie Sussman
+RFC # 630                                                 BBN
+NIC # 30237                                               April 10, 1974
+
+
+          FTP Error Code Usage for More Reliable Mail Service
+
+
+                                PURPOSE
+
+    A major hindrance to providing reliable mail service is the lack of
+well-defined FTP error replies that would enable a mailing process to
+decide how to handle a failure.  New FTP error codes are currently in
+the design stage, and a proposal will be announced soon.  In the
+interim, we can get some improvement by simply defining how we intend to
+use the current FTP codes.  The purpose of this RFC is to inform all
+sites of how TENEX sites will use and interpret the codes starting in
+the near future.
+
+
+                        CURRENT CODE DEFINITIONS
+
+    The FTP error codes defined for failure to perform a file action
+(including mail) are:
+
+450 File not found
+451 File access denied to you
+452 Data connection closed
+453 Insufficient storage
+454 Cannot connect to your data socket
+
+450, 451, and 453 are applicable to both the MAIL and MLFL commands,
+while 452 and 454 are only meaningful for MLFL.
+
+
+                   SHORTCOMING OF CURRENT DEFINITIONS
+
+    There are more possible causes of failure to deliver mail than the
+ones defined above.  Implementors of FTP servers thus had to make
+arbitrary assignments of error conditions to defined codes.  As a
+result, although the text of the reply might distinguish these
+conditions for the benefit of human users, the code doesn't distinguish
+them for the benefit of processes.
+
+    The minimum distinction needed by the TENEX mail-sending processes
+is between permanent and non-permanent failures.  In the latter case,
+the process will repeatedly try to deliver the mail for several days.
+
+
+
+
+Sussman                                                         [Page 1]
+
+RFC 630          FTP Error Code Usage for Mail Service        April 1974
+
+
+                     NEW DEFINITIONS FOR TENEX USE
+
+    The following changes will be installed at TENEX sites over the next
+couple of months.
+
+FTP SERVER
+
+    The TENEX FTP server will continue to use 452 and 454 as specified
+for the MLFL command.
+
+    For MAIL and MLFL, it will send the other codes as follows:
+
+450 Permanent failures due to the user addressed in the Mail or MLFL
+    command.
+
+    Examples:  No such user; No mailbox for that user; Can't access file
+    (because net users can't write in that mailbox).
+
+451 Permanent failures due to the message itself.
+
+    Example:  Line sent over TELNET connection is too long (MAIL command
+    only).
+
+453 Temporary failures
+
+    Examples:  TELNET connection unexpectedly closed;  Mailbox busy;
+    Unexpected local errors (such as failure to create scratch file).
+
+MAILING PROCESSES
+
+    TENEX mailing processes currently interpret all the codes 450-454 as
+meaning permanent failure.  They will be changed to interpret 452, 453,
+and 454 as temporary while leaving 450 and 451 permanent.
+
+
+                   COMPATIBILITY WITH NON-TENEX SITES
+
+    These interpretations should not adversely affect the interaction of
+TENEX and non-TENEX mail processes, since we are simply changing from
+one arbitrary set of interpretations to another.  Moreover:
+
+--Our interpretation of 450-451 as permanent and 452-454 as temporary is
+consistent with their original meanings.
+
+--Our new choice of what codes to use for what failure is no farther
+from the original meanings than our old choice was, and conveys more
+information.
+
+
+
+
+Sussman                                                         [Page 2]
+
+RFC 630          FTP Error Code Usage for Mail Service        April 1974
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Alex McKenzie with    ]
+       [ support from GTE, formerly BBN Corp.            10/99 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sussman                                                         [Page 3]
+