Add files from ESR's dev directory that weren't under version control

svn path=/trunk/; revision=3881

1 files changed, 507 insertions, 0 deletions

diff --git a/RFC/rfc2645.txt b/RFC/rfc2645.txt
new file mode 100644
index 00000000..cb99fc84
--- /dev/null
+++ b/RFC/rfc2645.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gellens
+Request for Comments: 2645                                     Qualcomm
+Category: Standards Track                                   August 1999
+
+
+                      ON-DEMAND MAIL RELAY (ODMR)
+                    SMTP with Dynamic IP Addresses
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Table of Contents
+
+    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  1
+    2.  Conventions Used in this Document . . . . . . . . . . . . . . 2
+    3.  Comments . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+    4.  Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
+    5.  States . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+      5.1.  Initial State . . . . . . . . . . . . . . . . . . . . . . 4
+        5.1.1.  EHLO . . . . . . . . . . . . . . . . . . . . . . . .  4
+        5.1.2.  AUTH  . . . . . . . . . . . . . . . . . . . . . . . . 4
+        5.1.3.  QUIT . . . . . . . . . . . . . . . . . . . . . . . .  4
+      5.2.  Authenticated State . . . . . . . . . . . . . . . . . . . 4
+        5.2.1.  ATRN (Authenticated TURN)  . . . . . . . . . . . . .  4
+      5.3.  Reversed State  . . . . . . . . . . . . . . . . . . . . . 5
+      5.4.  Other Commands . . . . . . . . . . . . . . . . . . . . .  6
+    6.  Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6
+    7.  Response Codes . . . . . . . . . . . . . . . . . . . . . . .  6
+    8.  Security Considerations . . . . . . . . . . . . . . . . . . . 6
+    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  7
+   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   11.  Author's Address   . . . . . . . . . . . . . . . . . . . . .  8
+   12.  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 9
+
+1.  Abstract
+
+   With the spread of low-cost computer systems and Internet
+   connectivity, the demand for local mail servers has been rising.
+   Many people now want to operate a mail server on a system which has
+
+
+
+Gellens                     Standards Track                     [Page 1]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   only an intermittent connection to a service provider.  If the system
+   has a static IP address, the ESMTP ETRN command [ETRN] can be used.
+   However, systems with dynamic IP addresses (which are very common
+   with low-cost connections) have no widely-deployed solution.
+
+   This memo proposes a new service, On-Demand Mail Relay (ODMR), which
+   is a profile of SMTP [SMTP, ESMTP], providing for a secure,
+   extensible, easy to implement approach to the problem.
+
+2.  Conventions Used in this Document
+
+   Because the client and server roles reverse during the session, to
+   avoid confusion, the terms "customer" and "provider" will be used in
+   place of "client" and "server", although of course this protocol may
+   be useful in cases other than commercial service providers and
+   customers.
+
+   In examples, "P:" is used to indicate lines sent by the provider, and
+   "C:" indicates those sent by the customer.  Line breaks within a
+   command are for editorial purposes only.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in [KEYWORDS].
+
+   Examples use 'example.net' as the provider, and 'example.org' and '
+   example.com' as the customers.
+
+3.  Comments
+
+   Private comments should be sent to the author.  Public comments may
+   be sent to the IETF Disconnected SMTP mailing list,
+   <ietf-disconn-smtp@imc.org>.  To subscribe, send a message to
+   <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as
+   the body.
+
+4.  Description
+
+   On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP].
+   Port 366 is reserved for On-Demand Mail Relay.  The initial client
+   and server roles are short-lived, as the point is to allow the
+   intermittently-connected host to request mail held for it by a
+   service provider.
+
+   The customer initiates a connection to the provider, authenticates,
+   and requests its mail.  The roles of client and server then reverse,
+   and normal SMTP [SMTP, ESMTP] proceeds.
+
+
+
+
+
+Gellens                     Standards Track                     [Page 2]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   The provider has an On-Demand Mail Relay process listening for
+   connections on the ODMR port.  This process does not need to be a
+   full SMTP server.  It does need to be an SMTP client with access to
+   the outgoing mail queues, and as a server implement the EHLO, AUTH,
+   ATRN, and QUIT commands.
+
+   An MTA normally has a mail client component which processes the
+   outgoing mail queues, attempting to send mail for particular domains,
+   based on time or event (such as new mail being placed in the queue,
+   or receipt of an ETRN command by the SMTP server component).  The
+   On-Demand Mail Relay service processes the outgoing queue not on a
+   timer or new mail creation, but on request.
+
+   The provider side has normal SMTP server responsibilities [SMTP],
+   including generation of delivery failure notices, etc. as needed.
+
+5.  States
+
+   The On-Demand Mail Relay service has three states: an initial state,
+   an authenticated state, and a reversed state.  The state progression
+   is illustrated in the following diagram:
+
+   ---------------------------
+   !      initial state      !
+   ---------------------------
+     !             !
+   QUIT           AUTH
+     !             !
+     !             V
+     !      -----------------------
+     !      ! authenticated state !
+     !      -----------------------
+     !       !            !
+     !      QUIT         ATRN
+     !       !            !
+     !       !            V
+     !       !      ------------------
+     !       !      ! reversed state !
+     !       !      ------------------
+     !       !         !
+     !       !        QUIT
+     !       !         !
+     V       V         V
+     ---------------------
+     !    termination    !
+     ---------------------
+
+
+
+
+
+Gellens                     Standards Track                     [Page 3]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   (Note that in the reversed state, commands are sent by the provider,
+   not the customer.)
+
+5.1.  Initial State
+
+   In the initial state, the provider is the server and the customer is
+   the client.  Three commands are valid:  EHLO, AUTH, and QUIT.
+
+5.1.1.  EHLO
+
+   The EHLO command is the same as in [ESMTP].  The response MUST
+   include AUTH and ATRN.
+
+5.1.2.  AUTH
+
+   The AUTH command is specified in [AUTH].  The AUTH command uses a
+   [SASL] mechanism to authenticate the session.  The session is not
+   considered authenticated until a success response to AUTH has been
+   sent.
+
+   For interoperability, implementations MUST support the CRAM-MD5
+   mechanism [CRAM].  Other SASL mechanisms may be supported.  A site
+   MAY disable CRAM-MD5 support if it uses more secure methods.  The
+   EXTERNAL mechanism [SASL] might be useful in some cases, for example,
+   if the provider has already authenticated the client, such as during
+   a PPP connection.
+
+5.1.3.  QUIT
+
+   The QUIT command is the same as in [SMTP].
+
+5.2.  Authenticated State
+
+   The authenticated state is entered after a successful AUTH command.
+   Two commands are valid in the authenticated state:  ATRN and QUIT.
+
+5.2.1.  ATRN (Authenticated TURN)
+
+   Unlike the TURN command in [SMTP], the ATRN command optionally takes
+   one or more domains as a parameter.  The ATRN command MUST be
+   rejected if the session has not been authenticated.  Response code
+   530 [AUTH] is used for this.
+
+   The timeout for this command MUST be at least 10 minutes to allow the
+   provider time to process its mail queue.
+
+   An ATRN command sent with no domains is equivalent to an ATRN command
+   specifying all domains to which the customer has access.
+
+
+
+Gellens                     Standards Track                     [Page 4]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   If the authentication used by the customer does not provide access to
+   all of the domains specified in ATRN, the provider MUST NOT send mail
+   for any domains to the customer; the provider MUST reject the ATRN
+   command with a 450 code.
+
+   If the customer does have access to all of the specified domains, but
+   none of them have any queued mail, the provider normally rejects the
+   ATRN command with response code 453.  The provider MAY instead issue
+   a 250 success code, and after the roles are reversed, send a QUIT
+   following the EHLO.
+
+   The provider MAY also reject the ATRN command with a 450 response to
+   indicate refusal to accept multiple requests issued within a
+   particular time interval.
+
+   If the customer has access to all of the specified domains and mail
+   exists in at least one of them, the provider issues a 250 success
+   code.
+
+   If the server is unable to verify access to the requested domains
+   (for example, a mapping database is temporarily unavailable),
+   response code 451 is sent.
+
+      [ABNF] for ATRN:
+
+      atrn          = "ATRN" [SP domain *("," domain)]
+
+      domain        = sub-domain 1*("." sub-domain)
+
+      sub-domain    = (ALPHA / DIGIT) *(ldh-str)
+
+      ldh-str       = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
+
+5.3.  Reversed State
+
+   After the provider has sent a success reply to the ATRN command, the
+   roles reverse, and the customer becomes the server, and the provider
+   becomes the client.
+
+   After receiving the success response to ATRN, the customer sends a
+   standard SMTP initial greeting line.  At this point normal SMTP
+   [SMTP, ESMTP] commands are used.  Typically the provider sends EHLO
+   after seeing the customer's greeting, to be followed by MAIL FROM and
+   so on.
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 5]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+5.4.  Other Commands
+
+   The provider MAY reject all commands other than EHLO, AUTH, ATRN, and
+   QUIT with response code 502.
+
+6.  Example On-Demand Mail Relay Session
+
+      P:  220 EXAMPLE.NET on-demand mail relay server ready
+      C:  EHLO example.org
+      P:  250-EXAMPLE.NET
+      P:  250-AUTH CRAM-MD5 EXTERNAL
+      P:  250 ATRN
+      C:  AUTH CRAM-MD5
+      P:  334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo=
+      C:  Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo=
+      P:  235 now authenticated as example.org
+      C:  ATRN example.org,example.com
+      P:  250 OK now reversing the connection
+      C:  220 example.org ready to receive email
+      P:  EHLO EXAMPLE.NET
+      C:  250-example.org
+      C:  250 SIZE
+      P:  MAIL FROM: <Lester.Tester@dot.foo.bar>
+      C:  250 OK
+      P:  RCPT TO: <l.eva.msg@example.com>
+      C:  250 OK, recipient accepted
+      ...
+      P:  QUIT
+      C:  221 example.org closing connection
+
+7.  Response Codes
+
+   The response codes used in this document are:
+
+   250  Requested mail action okay, completed
+   450  ATRN request refused
+   451  Unable to process ATRN request now
+   453  You have no mail
+   502  Command not implemented
+   530  Authentication required [AUTH]
+
+8.  Security Considerations
+
+   Because access to the On-Demand Mail Relay server is only useful with
+   a prior arrangement between the parties (so the provider is the
+   target of MX records for the customer's domains and thus has mail to
+   relay), it may be useful for the provider to restrict access to the
+   On-Demand Mail Relay port.  For example, the ODMR server could be
+
+
+
+Gellens                     Standards Track                     [Page 6]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   configurable, or a TCP wrapper or firewall could be used, to block
+   access to port 366 except within the provider's network.  This might
+   be useful when the provider is the customer's ISP.  Use of such
+   mechanisms does not reduce the need for the AUTH command, however,
+   but can increase the security it provides.
+
+   Use of SASL in the AUTH command allows for substitution of more
+   secure authentication mechanisms in the future.
+
+   See sections 5.1.2 and 5.2.1 for additional security details.
+
+9.  Acknowledgments
+
+   This memo has been developed in part based on comments and
+   discussions which took place on and off the IETF-disconn-smtp mailing
+   list.  Special thanks to Chris Newman and Ned Freed for their
+   comments.
+
+10.  References
+
+   [ABNF]      Crocker, D. and P. Overell,  "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [AUTH]      Myers, J., "SMTP Service Extension for Authentication",
+               RFC 2554, March 1999.
+
+   [CRAM]      Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", RFC 1869, November
+               1995.
+
+   [ETRN]      De Winter, J., "SMTP Service Extension for Remote Message
+               Queue Starting", RFC 1985, August 1996.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP]      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 7]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+11.  Author's Address
+
+   Randall Gellens
+   QUALCOMM Incorporated
+   5775 Morehouse Dr.
+   San Diego, CA  92121-2779
+   U.S.A.
+
+   Phone: +1.619.651.5115
+   EMail: randy@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 8]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 9]
+