doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1985.txt b/doc/rfc/rfc1985.txt
new file mode 100644
index 0000000..f49afd7
--- /dev/null
+++ b/doc/rfc/rfc1985.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                       J. De Winter
+Request for Comments: 1985                     Wildbear Consulting, Inc.
+Category: Standards Track                                    August 1996
+
+
+                         SMTP Service Extension
+                   for Remote Message Queue Starting
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines an extension to the SMTP service whereby an SMTP
+   client and server may interact to give the server an opportunity to
+   start the processing of its queues for messages to go to a given
+   host.  This extension is meant to be used in startup conditions as
+   well as for mail nodes that have transient connections to their
+   service providers.
+
+1.  Introduction
+
+   The TURN command was a valid attempt to address the problem of having
+   to start the processing for the mail queue on a remote machine.
+   However, the TURN command presents a large security loophole.  As
+   there is no verification of the remote host name, the TURN command
+   could be used by a rogue system to download the mail for a site other
+   than itself.
+
+   Therefore, this memo introduces the ETRN command.  This command uses
+   the mechanism defined in [4] to define extensions to the SMTP service
+   whereby a client ("sender-SMTP") may request that the server
+   ("receiver-SMTP") start the processing of its mail queues for
+   messages that are waiting at the server for the client machine.  If
+   any messages are at the server for the client, then the server should
+   create a new SMTP session and send the messages at that time.
+
+
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 1]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+2.  Framework for the ETRN Extension
+
+   The following service extension is therefore defined:
+
+   (1) the name of the SMTP service extension is "Remote Queue
+   Processing Declaration";
+
+   (2) the EHLO keyword value associated with this extension is "ETRN",
+   with no associated parameters;
+
+   (3) one additional verb, ETRN, with a single parameter that
+   specifies the name of the client(s) to start processing for;
+
+   (4) no additional SMTP verbs are defined by this extension.
+
+   The remainder of this memo specifies how support for the extension
+   affects the behavior of an SMTP client and server.
+
+3.  The Remote Queue Processing Declaration service extension
+
+   To save money, many small companies want to only maintain transient
+   connections to their service providers.  In addition, there are some
+   situations where the client sites depend on their mail arriving
+   quickly, so forcing the queues on the server belonging to their
+   service provider may be more desirable than waiting for the retry
+   timeout to occur.
+
+   Both of these situations could currently be fixed using the TURN
+   command defined in [1], if it were not for a large security loophole
+   in the TURN command.  As it stands, the TURN command will reverse the
+   direction of the SMTP connection and assume that the remote host is
+   being honest about what its name is.  The security loophole is that
+   there is no documented stipulation for checking the authenticity of
+   the remote host name, as given in the HELO or EHLO command.  As such,
+   most SMTP and ESMTP implementations do not implement the TURN command
+   to avoid this security loophole.
+
+   This has been addressed in the design of the ETRN command.  This
+   extended turn command was written with the points in the first
+   paragraph in mind, yet paying attention to the problems that
+   currently exist with the TURN command.  The security loophole is
+   avoided by asking the server to start a new connection aimed at the
+   specified client.
+
+   In this manner, the server has a lot more certainty that it is
+   talking to the correct SMTP client.  This mechanism can just be seen
+   as a more immediate version of the retry queues that appear in most
+   SMTP implementations.  In addition, as this command will take a
+
+
+
+De Winter                   Standards Track                     [Page 2]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   single parameter, the name of the remote host(s) to start the queues
+   for, the server can decide whether it wishes to respect the request
+   or deny it for any local administrative reasons.
+
+4.  Definitions
+
+   Remote queue processing means that using an SMTP or ESMTP connection,
+   the client may request that the server start to process parts of its
+   messaging queue.  This processing is performed using the existing
+   SMTP infrastructure and will occur at some point after the processing
+   is initiated.
+
+      The server host is the node that is responding to the ETRN
+      command.
+
+      The client host is the node that is initiating the ETRN command.
+
+   The remote host name is defined to be a plain-text field that
+   specifies a name for the remote host(s).  This remote host name may
+   also include an alias for the specified remote host or special
+   commands to identify other types of queues.
+
+5.  The extended ETRN command
+
+   The extended ETRN command is issued by the client host when it wishes
+   to start the SMTP queue processing of a given server host.  The
+   syntax of this command is as follows:
+
+      ETRN [<option character>]<node name><CR><LF>
+
+   This command may be issued at any time once a session is established,
+   as long as there is not a transaction occuring.  Thus, this command
+   is illegal between a MAIL FROM: command and the end of the DATA
+   commands and responses.
+
+   The specified node name must be a fully qualified domain name for the
+   node, which may refer to a CNAME or MX pointer in the DNS.  If an
+   alias is used for the node, multiple ETRN commands may be needed to
+   start the processing for the node as it may be listed at the remote
+   site under multiple names.  This can also be addressed using the
+   options discussed in section 5.3.
+
+   The option character under normal circumstances is not used.
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 3]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+5.1  Server action on receipt of the extended ETRN command
+
+   When the server host receives the ETRN command, it should have a look
+   at the node name that is specified in the command and make a local
+   decision if it should honour the request.  If not, the appropriate
+   error codes should be returned to the client.
+
+   Otherwise, the server host should force its retry queues to start
+   sending messages to that remote site, using another SMTP connection.
+   At the moment, there is no requirement that a connection must occur,
+   or that the connection must occur within a given time frame.  This
+   should be noted in the case where there are no messages for the
+   client host at the server host and only the 250 response is used.
+
+   Since the processing of the queues may take an indeterminate amount
+   of time, this command should return immediately with a response to
+   the client host.  The valid return codes for this command are:
+
+   250 OK, queuing for node <x> started
+   251 OK, no messages waiting for node <x>
+   252 OK, pending messages for node <x> started
+   253 OK, <n> pending messages for node <x> started
+   458 Unable to queue messages for node <x>
+   459 Node <x> not allowed: <reason>
+   500 Syntax Error
+   501 Syntax Error in Parameters
+
+   The 250 response code does not indicate that messages will be sent to
+   the system in question, just that the queue has been started and some
+   action will occur.  If the server is capable of supporting it, the
+   251, 252 or 253 response codes should be used to give more
+   information to the client side.  In this case, if there are messages
+   waiting for the client side node, a check can be performed using
+   these responses codes as an indication of when there are no more
+   pending messages in the queue for that node.
+
+   The 458 and 459 result codes should be used to give more information
+   back to the client host as to why the action was not performed.  If
+   the syntax of the request is not correct, then the 500 and 501 result
+   codes should be used.
+
+5.2  Client action on receiving response to extended ETRN command
+
+   If one of the 500 level error codes (550 or 551) are sent, the client
+   should assume that the protocol is not supported in the remote host
+   or that the protocol has not been implemented correctly on either the
+   client or server host.  In this case, multiple ETRN commands (dealing
+   with the aliases for the system) should not be sent.
+
+
+
+De Winter                   Standards Track                     [Page 4]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   If the 250 response is received, then the client host can assume that
+   the server host found its request to be satisfactory and it will send
+   any queued messages.  This process may involve going through a very
+   large retry queue, and may take some time.
+
+   If the 400 level response is received, then the client can assume
+   that the server supports the command, but for some local reason does
+   not want to accept the ETRN command as is.  In most cases, it will
+   mean that there is a list of nodes that it will accept the command
+   from and the current client is not on that list.  The 459 response
+   code is presented to allow for a more in-depth reason as to why the
+   remote queuing cannot be started.
+
+5.3  Use Of ETRN to release mail for a subdomain or queue
+
+   If the requesting server wishes to release all of the mail for a
+   given subdomain, a variation on the ETRN command can be used.  To
+   perform this request, the option character '@' should be used in
+   front of the node name.  In this manner, any domain names that are
+   formed with a suffix of the specified node name are released.
+
+   For example, if the command ETRN @foo.com was issued, then any
+   accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
+   may be released.  It should be noted that the receiving side of the
+   ETRN command should make a decision based on the client in question
+   and only allow certain combinations for each of the nodes.  This is
+   more of a security issue than anything else.
+
+   In a similar vein, it might be necessary under some circumstances to
+   release a certain queue, where that queue does not correspond to a
+   given domain name.  To this end, the option character '#' can be used
+   to force the processing of a given queue.  In this case, the node
+   name would be used as a queue name instead, and its syntactical
+   structure would be dependant on the receiving server.  An example of
+   this would be using the command ETRN #uucp to force the flush of a
+   UUCP queue.  Note that the use of this option is entirely a local
+   matter and there is no way for a client to find a list of any such
+   queues that exist.
+
+6.  Minimal usage
+
+   A "minimal" client may use this extension with its host name to start
+   the queues on the server host.  This minimal usage will not handle
+   cases where mail for 'x.y' is sent to 's.x.y'.
+
+   A minimal server may use this extensions to start the processing of
+   the queues for all remote sites.  In this case, the 458 error
+   response will not be seen, and it should always return the 250
+
+
+
+De Winter                   Standards Track                     [Page 5]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   response as it will always try and start the processing for any
+   request.
+
+7. Example
+
+   The following example illustrates the use of remote queue processing
+   with some permanent and temporary failures.
+
+   S: <wait for connection on TCP port 25>
+   C: <open connection to server>
+   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+   C: EHLO ymir.claremont.edu
+   S: 250-sigurd.innosoft.com
+   S: 250-EXPN
+   S: 250-HELP
+   S: 250 ETRN
+   C: ETRN
+   S: 500 Syntax Error
+   C: ETRN localname
+   S: 501 Syntax Error in Parameters
+   C: ETRN uu.net
+   S: 458 Unable to queue messages for node uu.net
+   ...
+
+   C: ETRN sigurd.innosoft.com
+   S: 250 OK, queuing for node sigurd.innosoft.com started
+   C: ETRN innosoft.com
+   S: 250 OK, queuing for node innosoft.com started
+
+   OR
+
+   C: ETRN sigurd.innosoft.com
+   S: 251 OK, no messages waiting for node sigurd.innosoft.com
+   C: ETRN innosoft.com
+   S: 252 OK, pending messages for node innosoft.com started
+   C: ETRN mysoft.com
+   S: 253 OK, 14 pending messages for node mysoft.com started
+
+   ...
+   C: ETRN foo.bar
+   S: 459 Node foo.bar not allowed: Unable to resolve name.
+   ...
+   C: QUIT
+   S: 250 Goodbye
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 6]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+8. Security Considerations
+
+   This command does not compromise any security considerations of any
+   existing SMTP or ESMTP protocols as it merely shortens the time that
+   a client needs to wait before their messages are retried.
+
+   Precautions should be taken to make sure that any client server can
+   only use the @ and # option characters for systems that make sense.
+   Failure to implement some kind of sanity checking on the parameters
+   could lead to congestion.  This would be evident if a person asking
+   to release @com, which would release mail for any address that ended
+   with com.
+
+9.  Acknowledgements
+
+   This document was created with lots of support from the users of our
+   products, who have given some input to the functionality that they
+   would like to see in the software that they bought.
+
+10.  References
+
+   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, August 1982.
+
+   [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+       Nations University, Innosoft International, Inc., Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., The Branch
+       Office, February 1993.
+
+11.  Author's Address
+
+   Jack De Winter
+   Wildbear Consulting, Inc.
+   17 Brock Street
+   Kitchener, Ontario, Canada
+   N2M 1X2
+
+   Phone: +1 519 576 3873
+   EMail: jack@wildbear.on.ca
+
+
+
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 7]
+