rfc1869.txt

很多RFC的中文文档

    如果服务器SMTP识别了EHLO命令，但是不能执行，将返回“502”。

    如果服务器SMTP认为不再提供SMTP（例如，由于系统即将关闭），将返回“421”。

    在所有的出错响应中，客户端SMTP须发出HELO或QUIT命令。

4.6. 不支持扩展的服务器响应
   RFC 821规定：遵从RFC 821 但是不支持扩展的服务器SMTP不能识别EHLO,并将随之返
回“500”。服务器SMTP在返回“500”后还处于同一状态（见section 4.1.1 of RFC 821）。
客户端SMTP可发出HELO或QUIT命令。

4.7. 服务器未正确完成命令的响应
     某些SMTP服务器当接到EHLO命令是，就会断开传输通道。这个断开的操作马上发生，
或在发送一个响应后发生。这种操作是违反RFC 821 的section 4.1.1 的，那里明确的指出
断开的操作只能发生在QUIT命令发出之后。
     然而，为了得到最大的吞吐量，建议扩展SMTP客户端使用EHLO作为检测EHLO发出后
服务器连接是否关闭，无论得到响应前后都可以。如果这种情况发生，客户端必须决定这项
操作在不使用任何SMTP扩展的情况下是否可以成功的完成。如果可以完成，则可以开通一个
新的连接，并使用HELO命令。
     其他不正确执行的的服务器在EHLO命令发出和被拒绝后将不接受HELO命令。在某种情
况下，这个问题可以如下解决：在收到EHLO命令的失败响应后，发送一个RSET命令，然后
发送HELO命令。使用这种方法的客户端应明确：很多应用对RSET的响应是失败的响应（例
如：503，命令序列错误）。这个码可以被忽略。

5.  初始 IANA 注册
    SMTP服务扩展的IANA初始注册包括以下各项：

   服务扩展         EHLO       关键字参数   动词       增加的行为
   ------------- ------------ ---------- ---------- ------------------
   Send             SEND         none       SEND    defined in RFC 821
   Send or Mail     SOML         none       SOML    defined in RFC 821
   Send and Mail    SAML         none       SAML    defined in RFC 821
   Expand           EXPN         none       EXPN    defined in RFC 821
   Help             HELP         none       HELP    defined in RFC 821
   Turn             TURN         none       TURN    defined in RFC 821

   这些与[5]中定义的SMTP命令对应。（根据[5],原有的SMTP命令有HELO, MAIL, RCPT, 
DATA, RSET, VRFY, NOOP, 和 QUIT.）

6.  MAIL FROM 和 RCPT TO 参数
    一致公认：为SMTP设计的几个扩展将利用与MAIL FROM 和RCPT TO命令有关的附加参
数。这些命令的语法，跟[1]中的定义一样，使用[2]中的ABNF标识法：

     esmtp-cmd        ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
     esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
     esmtp-parameter  ::= esmtp-keyword ["=" esmtp-value]
     esmtp-keyword    ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

                          ; 语法和值依赖esmtp-keyword
     esmtp-value      ::= 1*< 除 "=", SP之外任何 CHAR, 所有控制字符 
(包括US ASCII 0-31)>

                          ; 下述命令扩展为可接收扩展参数
     inner-esmtp-cmd  ::= ("MAIL FROM:" reverse-path)   /
                          ("RCPT TO:" forward-path)

   所有esmtp-keyword 必须注册为IANA的一部分。这部分定义只提供未来扩展的框架；本
RFC没有定义扩展MAIL FROM 或 RCPT TO的参数。

6.1.  出错响应
    如果服务器SMTP没有识别或不能执行一个或多个与特定MAIL FROM 或 RCPT TO命令相
关的参数，将返回“555”。
   如果因为某种原因，服务器暂时不能解释个或多个与MAIL FROM 或 RCPT TO命令相关的
参数，并且，如果对这些参数的定义与其他码不统一，将返回“455”。
    特定参数和值的错误定义在RFC中的参数定义中。

7. 收到: 头部域注释
SMTP服务器要求在他们收到的所有消息的头部信息中增加一个恰当的“收到：”域。当
任一SMTP服务扩展被使用后，在这个域中增加一个“with ESMTP”从句。"ESMTP" 因此被添
加到在IANA中注册过的标准协议名称的列表中。

8. 应用举例
(1)   交互方式:

       S: <wait for connection on TCP port 25>
       C: <open connection to server>
       S: 220 dbc.mtview.ca.us SMTP service ready
       C: EHLO ymir.claremont.edu
       S: 250 dbc.mtview.ca.us says hello
        ...

       表明：服务器SMTP只执行在[5]中定义的SMTP命令。

 (2)   另一种交互方式:

       S: <wait for connection on TCP port 25>
       C: <open connection to server>
       S: 220 dbc.mtview.ca.us SMTP service ready
       C: EHLO ymir.claremont.edu
       S: 250-dbc.mtview.ca.us says hello
       S: 250-EXPN
       S: 250-HELP
       S: 250-8BITMIME
       S: 250-XONE
       S: 250 XVRB
        ...

       表明服务器SMTP也执行SMTP的EXPN和HELP命令，一个标准服务扩展（8BITMIME），
和两个非标准及未注册的服务扩展（XONE 和 XVRB）。

(3)	最后，不支持SMTP服务扩展的服务器表现如下：
 
       S: <wait for connection on TCP port 25>
       C: <open connection to server>
       S: 220 dbc.mtview.ca.us SMTP service ready
       C: EHLO ymir.claremont.edu
       S: 500 Command not recognized: EHLO
        ...

       响应“500”表示服务器SMTP未完成所发的命令。客户端可以发HELO命令，并象RFC821
里规定的一样进行。见section 4.7的附加讨论。

9. 安全考虑
本建议本身不构成安全问题，也不会影响现存的安全设置。采用这个算法的服务器保证
HBA 的内容能在网络上传送，这个消息能防止窜改。因为对 HBA 的篡改会导致一些或者
所有客户拒绝服务。
    RFC不讨论安全性问题，也不认为可以提高已有的电子邮件系统以及完全遵从RFC-821
系统的安全系数。它不提供通过响应EHLO命令而得到的服务器的邮件能力。但是，RFC定义
的服务扩展的任何初始状态的声明所提供的信息可由传输和递送邮件是所需要的动词的选择
性中容易的推出。其他RFC中描述的服务扩展的安全性的含义针对各自的RFC.
10. 鸣谢
本文综合了很多人的思想以及意见和建议。Randall Atkinson, Craig Everhart, Risto 
Kankkunen 和 Greg Vaudreuil 合作，向我们贡献了足够多的想法和文字材料。Harald 
Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per   
Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, 
John Myers, Dan Oscarsson, Julian Onions, Rayan Zachariassen 以及整个IETF SMTP
工作组向我们提供了重要的建议，文字材料或鼓励。当然，并没有人负责对这里提到的综合
想法作出回答。确实，在某种情况下，对一个特定批评的回答即为这个问题的特定性，而不
是从根本的包括一个完整的不同的解决方法。
11. 参考文献
   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
       Headers", RFC 1522, University of Tennessee, September 1993.

   [5] Braden, R., "Requirements for Internet Hosts - Application and
       Support", STD 3, RFC 1123, USC/Information Sciences Institute,
       October 1989.

12. 主席，编辑及作者地址
   John Klensin, WG Chair
   MCI
   2100 Reston Parkway
   Reston, VA 22091

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]

   Ned Freed, Editor
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Moutain V
RFC1869——SMTP Service Extensions                                 SMTP服务扩展



1
RFC文档中文翻译计划