rfcrfc2554.txt

本程序为在linux下实现FTP传输文件的实现

   530 需要认证
   
   这个响应可以被任何命令返回（除了 AUTH, EHLO,   HELO, NOOP, RSET, 或 QUIT）。
它表明服务器安全策略要求认证以执行客户端的请求动作。
7. 正式的语法
   下面的语法定义使用了扩展的Backus-Naur Form (BNF)符号，它的详细说明在[abfn]。  
   除了有名的另外的方式，所有的字母表字符都是大小写不敏感的。这里使用大写或小   
写字符来定义关键字符串只是为了编辑上的清晰。具体实现必须把这些字符串做为大小   
写不敏感的方式来接受。
   
   UPALPHA         = %x41-5A            ;; Uppercase: A-Z

   LOALPHA         = %x61-7A            ;; Lowercase: a-z

   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive

   DIGIT           = %x30-39            ;; Digits 0-9

   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)

   hexchar         = "+" HEXDIGIT HEXDIGIT

   xchar           = %x21-2A / %x2C-3C / %x3E-7E
                     ;; US-ASCII except for "+", "=", SPACE and CTL

   xtext           = *(xchar / hexchar)

   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"

   AUTH_type       = 1*20AUTH_CHAR

   AUTH_command    = "AUTH" SPACE AUTH_type [SPACE (base64 / "=")]
                     *(CRLF [base64]) CRLF

   AUTH_param      = "AUTH=" xtext
                       ;; The decoded FORM of the xtext MUST be either
                       ;; an addr-spec or the two characters "<>"

   base64          = base64_terminal /
                     ( 1*(4base64_CHAR) [base64_terminal] )

   base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
                     ;; Case-sensitive

   base64_terminal = (2base64_char "==") / (3base64_char "=")

   continue_req    = "334" SPACE [base64] CRLF


   CR              = %x0C           ;; ASCII CR, carriage return

   CRLF            = CR LF

   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL

   LF              = %x0A           ;; ASCII LF, line feed

   SPACE           = %x20           ;; ASCII SP, space




8. References

   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

   [CRAM-MD5]  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.

   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
               Notifications", RFC 1891, January 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.

   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
               2476, December 1998.

   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
               821, August 1982.

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



9. 安全上的考虑

   这里探讨有关安全的主题。

   如果客户端使用这种扩展来得到一个通过一个不安全的网络到达与之合作的服务器   
的加密信道，同时连接没有被交互认证和加密，它需要被配置为从没有向这个服务器发送邮
件。否则一个攻击者可以通过截获SMTP连接并假装服务器不能支持认证扩展或让所有
AUTH命令失败的方式偷走用户的邮件。
   
   在SASL协商发生之前，任何协议交互数据都是明文而且可以被一个主动攻击者更改，
因此，客户端和服务器端都应该抛弃在SASL协商开始前的获得的信息。
   
   这种机制不保护tcp端口，所以主动进攻者可以把一个转发连接重定向到委托端口。
AUTH=<>参数防止这种导致转发没有认证消息以恢复转发客户端的认证的攻击。
   
   一个消息托付客户端可以要求用户不管是否被告之一个适当的SASL机制都必须认证。
因此，对一个委托服务器来说，去建议一个SASL机制使不合适的，使用这种机制通过匿名   
委托给客户端不会带来任何的益处。
   
   这种扩展不是为了取代类似s/mime 或 pgp的端到端的消息签名和加密系统。它和端到
端系统要解决的问题不同。有以下主要的区别：
   
      (1) 它一般只在被信任的环境中有效。

      (2) 它保护整个消息的报头部分，而不是邮件消息的主体部分。

      (3) 它对消息委托进行认证，而不是对消息内容的作者的认证。

      (4) 它可以给发送者一定的保证：在发送者交互认证并协商了一个合适的安全层的情          
况下，这个消息确信被传递到了下一跳。

   其他有关安全问题的事项在SASL规范中有论述。


10  作者地址

   John Gardiner Myers
   Netscape Communications
   501 East Middlefield Road
   Mail Stop MV-029
   Mountain View, CA 94043

   EMail: [e-mail]


11.  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.
























Myers                       Standards Track                    [Page 11]



RFC 2554 SMTP Service Extension for Authentication        SMTP服务认证扩展


1
RFC文档中文翻译计划