rfc2645.txt

中、英文RFC文档大全打包下载完全版 .

      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: <[e-mail]>
      C:  250 OK
      P:  RCPT TO: <[e-mail]>
      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: [phone]
   EMail: [e-mail]









































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]