毕业论文论文范文课程设计实践报告法律论文英语论文教学论文医学论文农学论文艺术论文行政论文管理论文计算机安全
您现在的位置: 毕业论文 >> 论文 >> 正文

电子邮件客户端软件开题报告+论文+源代码+英文文献 第6页

更新时间:2009-3-29:  来源:毕业论文
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", RFC2234, 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", RFC1869, November 1995.
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC1891, January 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC2222, 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, RFC822, August 1982.
9. Security Considerations
Security issues are discussed throughout this memo.
If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating server, it needs to be configured to never send mail to that server when the connection is not mutually authenticated and encrypted. Otherwise, an attacker could steal the client's mail by hijacking the SMTP connection and either pretending the server does not support the Authentication extension or causing all AUTH commands to fail.
Before the SASL negotiation has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the SASL negotiation upon completion of a SASL negotiation which results in a security layer.
This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt to the submission port [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing an relayed message without an envelope authentication to pick up the authentication of the relay client.
A message submission client may require the user to authenticate whenever a suitable SASL mechanism is advertised. Therefore, it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when use of that mechanism grants the client no benefits over anonymous submission.
This extension is not intended to replace or be used instead of end- to-end message signature and encryption systems such as S/MIME or PGP. This extension addresses a different problem than end-to-end systems; it has the following key differences:
(1) it is generally useful only within a trusted enclave
(2) it protects the entire envelope of a message, not just the message's body.
(3) it authenticates the message submission, not authorship of the message content
(4) it can give the sender some assurance the message was delivered to the next hop in the case where the sender mutually authenticates with the next hop and negotiates an appropriate security layer.
Additional security considerations are mentioned in the SASL specification [SASL].

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >> 

电子邮件客户端软件开题报告+论文+源代码+英文文献 第6页下载如图片无法显示或论文不完整,请联系qq752018766
设为首页 | 联系站长 | 友情链接 | 网站地图 |

copyright©751com.cn 辣文论文网 严禁转载
如果本毕业论文网损害了您的利益或者侵犯了您的权利,请及时联系,我们一定会及时改正。