7,785
社区成员
发帖
与我相关
我的任务
分享关于263、sohu的smtp服务器身份认证问题，高手请进
这是SOHU SMTP服务器和客户端通话的开始到认证结束的过程，我想知道认证过程是怎样的，好象是加密的，我想知道编码方式，因为我想做个SMTP客户端，但不知道如何通过AUTH LOGIN命令进行身份认证，有哪位大侠知道这方面的资料，请告知，谢谢了。
用户说:
EHLO bbn
服务器回答:
250-smtp04.sohu.com Hello [202.110.171.234]
250-AUTH=LOGIN
250-AUTH MBS_BASIC LOGIN
250-AUTH=MBS_BASIC LOGIN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-8bitmime
250-TURN
250 ATRN
用户说:
AUTH LOGIN
服务器回答:
334 VXNlcm5hbWU6
用户说:
sW1jjjjpbmU=
服务器回答:
334 UGFzc3dvcmQ6
用户说:
cdcdc3N4
服务器回答:
235 Authentication successful 成功了，
用户说:
EHLO bbn
服务器回答:
250-smtp04.sohu.com Hello [202.110.171.234]
250-AUTH=LOGIN
250-AUTH MBS_BASIC LOGIN
250-AUTH=MBS_BASIC LOGIN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-8bitmime
250-TURN
250 ATRN
用户说:
AUTH LOGIN
服务器回答:
334 VXNlcm5hbWU6
用户说:
sW1jjjjpbmU=
服务器回答:
334 UGFzc3dvcmQ6
用户说:
cdcdc3N4
服务器回答:
235 Authentication successful 成功了，
...全文
请发表友善的回复…
发表回复
xzjxu 2001-02-16
- 打赏
- 举报
Network Working Group J. Myers
Request for Comments: 2554 Netscape Communications
Category: Standards Track March 1999
SMTP Service Extension
for Authentication
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.
1. Introduction
This document defines an SMTP service extension [ESMTP] whereby an
SMTP client may indicate an authentication mechanism to the server,
perform an authentication protocol exchange, and optionally negotiate
a security layer for subsequent protocol interactions. This
extension is a profile of the Simple Authentication and Security
Layer [SASL].
2. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
3. The Authentication service extension
(1) the name of the SMTP service extension is "Authentication"
(2) the EHLO keyword value associated with this extension is "AUTH"
Myers Standards Track [Page 1]
RFC 2554 SMTP Authentication March 1999
(3) The AUTH EHLO keyword contains as a parameter a space separated
list of the names of supported SASL mechanisms.
(4) a new SMTP verb "AUTH" is defined
(5) an optional parameter using the keyword "AUTH" is added to the
MAIL FROM command, and extends the maximum line length of the
MAIL FROM command by 500 characters.
(6) this extension is appropriate for the submission protocol
[SUBMIT].
4. The AUTH command
AUTH mechanism [initial-response]
Arguments:
a string identifying a SASL authentication mechanism.
an optional base64-encoded response
Restrictions:
After an AUTH command has successfully completed, no more AUTH
commands may be issued in the same session. After a successful
AUTH command completes, a server MUST reject any further AUTH
commands with a 503 reply.
The AUTH command is not permitted during a mail transaction.
Discussion:
The AUTH command indicates an authentication mechanism to the
server. If the server supports the requested authentication
mechanism, it performs an authentication protocol exchange to
authenticate and identify the user. Optionally, it also
negotiates a security layer for subsequent protocol
interactions. If the requested authentication mechanism is not
supported, the server rejects the AUTH command with a 504
reply.
The authentication protocol exchange consists of a series of
server challenges and client answers that are specific to the
authentication mechanism. A server challenge, otherwise known
as a ready response, is a 334 reply with the text part
containing a BASE64 encoded string. The client answer consists
of a line containing a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
with a single "*". If the server receives such an answer, it
MUST reject the AUTH command by sending a 501 reply.
Myers Standards Track [Page 2]
RFC 2554 SMTP Authentication March 1999
The optional initial-response argument to the AUTH command is
used to save a round trip when using authentication mechanisms
that are defined to send no data in the initial challenge.
When the initial-response argument is used with such a
mechanism, the initial empty challenge is not sent to the
client and the server uses the data in the initial-response
argument as if it were sent in response to the empty challenge.
Unlike a zero-length client answer to a 334 reply, a zero-
length initial response is sent as a single equals sign ("=").
If the client uses an initial-response argument to the AUTH
command with a mechanism that sends data in the initial
challenge, the server rejects the AUTH command with a 535
reply.
If the server cannot BASE64 decode the argument, it rejects the
AUTH command with a 501 reply. If the server rejects the
authentication data, it SHOULD reject the AUTH command with a
535 reply unless a more specific error code, such as one listed
in section 6, is appropriate. Should the client successfully
complete the authentication exchange, the SMTP server issues a
235 reply.
The service name specified by this protocol's profile of SASL
is "smtp".
If a security layer is negotiated through the SASL
authentication exchange, it takes effect immediately following
the CRLF that concludes the authentication exchange for the
client, and the CRLF of the success reply for the server. Upon
a security layer's taking effect, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a
220 service ready greeting). The server MUST discard any
knowledge obtained from the client, such as the argument to the
EHLO command, which was not obtained from the SASL negotiation
itself. The client MUST discard any knowledge obtained from
the server, such as the list of SMTP service extensions, which
was not obtained from the SASL negotiation itself (with the
exception that a client MAY compare the list of advertised SASL
mechanisms before and after authentication in order to detect
an active down-negotiation attack). The client SHOULD send an
EHLO command as the first command after a successful SASL
negotiation which results in the enabling of a security layer.
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any security layers. If an AUTH command
fails, the client may try another authentication mechanism by
issuing another AUTH command.
Myers Standards Track [Page 3]
RFC 2554 SMTP Authentication March 1999
If an AUTH command fails, the server MUST behave the same as if
the client had not issued the AUTH command.
The BASE64 string may in general be arbitrarily long. Clients
and servers MUST be able to support challenges and responses
that are as long as are generated by the authentication
mechanisms they support, independent of any line length
limitations the client or server may have in other parts of its
protocol implementation.
Examples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
5. The AUTH parameter to the MAIL FROM command
AUTH=addr-spec
Arguments:
An addr-spec containing the identity which submitted the message
to the delivery system, or the two character sequence "<>"
indicating such an identity is unknown or insufficiently
authenticated. To comply with the restrictions imposed on ESMTP
parameters, the addr-spec is encoded inside an xtext. The syntax
of an xtext is described in section 5 of [ESMTP-DSN].
Discussion:
The optional AUTH parameter to the MAIL FROM command allows
cooperating agents in a trusted environment to communicate the
authentication of individual messages.
If the server trusts the authenticated identity of the client to
assert that the message was originally submitted by the supplied
addr-spec, then the server SHOULD supply the same addr-spec in an
AUTH parameter when relaying the message to any server which
supports the AUTH extension.
Myers Standards Track [Page 4]
RFC 2554 SMTP Authentication March 1999
A MAIL FROM parameter of AUTH=<> indicates that the original
submitter of the message is not known. The server MUST NOT treat
the message as having been originally submitted by the client.
If the AUTH parameter to the MAIL FROM is not supplied, the
client has authenticated, and the server believes the message is
an original submission by the client, the server MAY supply the
client's identity in the addr-spec in an AUTH parameter when
relaying the message to any server which supports the AUTH
extension.
If the server does not sufficiently trust the authenticated
identity of the client, or if the client is not authenticated,
then the server MUST behave as if the AUTH=<> parameter was
supplied. The server MAY, however, write the value of the AUTH
parameter to a log file.
If an AUTH=<> parameter was supplied, either explicitly or due to
the requirement in the previous paragraph, then the server MUST
supply the AUTH=<> parameter when relaying the message to any
server which it has authenticated to using the AUTH extension.
A server MAY treat expansion of a mailing list as a new
submission, setting the AUTH parameter to the mailing list
address or mailing list administration address when relaying the
message to list subscribers.
It is conforming for an implementation to be hard-coded to treat
all clients as being insufficiently trusted. In that case, the
implementation does nothing more than parse and discard
syntactically valid AUTH parameters to the MAIL FROM command and
supply AUTH=<> parameters to any servers to which it
authenticates using the AUTH extension.
Examples:
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK
Myers Standards Track [Page 5]
RFC 2554 SMTP Authentication March 1999
6. Error Codes
The following error codes may be used to indicate various conditions
as described.
432 A password transition is needed
This response to the AUTH command indicates that the user needs to
transition to the selected authentication mechanism. This typically
done by authenticating once using the PLAIN authentication mechanism.
534 Authentication mechanism is too weak
This response to the AUTH command indicates that the selected
authentication mechanism is weaker than server policy permits for
that user.
538 Encryption required for requested authentication mechanism
This response to the AUTH command indicates that the selected
authentication mechanism may only be used when the underlying SMTP
connection is encrypted.
454 Temporary authentication failure
This response to the AUTH command indicates that the authentication
failed due to a temporary server failure.
530 Authentication required
This response may be returned by any command other than AUTH, EHLO,
HELO, NOOP, RSET, or QUIT. It indicates that server policy requires
authentication in order to perform the requested action.
Myers Standards Track [Page 6]
RFC 2554 SMTP Authentication March 1999
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
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
Myers Standards Track [Page 7]
RFC 2554 SMTP Authentication March 1999
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.
Myers Standards Track [Page 8]
RFC 2554 SMTP Authentication March 1999
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.
Myers Standards Track [Page 9]
RFC 2554 SMTP Authentication March 1999
Additional security considerations are mentioned in the SASL
specification [SASL].
10. Author's Address
John Gardiner Myers
Netscape Communications
501 East Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043
EMail: jgmyers@netscape.com
Myers Standards Track [Page 10]
RFC 2554 SMTP Authentication March 1999
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.
xzjxu 2001-02-16
- 打赏
- 举报
多用途Internet邮件扩展(MIME)规范说明：消息体的格式
1. 介绍
通常的邮件格式于1982年出现以来，它已经被广为使用，在使用的过程中，一些不足之处也开始暴露出来。通常的电子邮件是一种文本格式的消息，这样一来，一些非文本的信息，如多媒体信息就无法传送；就算在文本方面，这种文件格式在传送非ASCII码的文本时也有些不足。
原来邮件协议的一个重大的不足在于，它限制文本的内容是一行内容相应比较短的7位ASCII码。这带来了许多麻烦。这个不足在网关允许在通常的电子邮件主机和X.400主机之间通信后变得更加突出，X.400指定了一种发送非文本内容电子邮件的机制，将X.400发向通常的电子邮件主机时，要么把内容转换成IA5Text格式，或者抛弃，并同时通知接收者有信息在传送中被丢弃。
本文主要描述一些机制可以解决上述问题，特点地它描述了MIME版本头域，内容类型头域，内容传送编码头域和用于描述文件内容的两个头域。在阅读此文档时可能有些地方您会觉得非常怪，这是为了照顾到和不同的版本进行兼容而不得不这样。
2. 定义、惯例和基本BNF语法
本文中的所有参数和名称均是大小写敏感的。对于BNF语法不熟悉的请参阅其它资料。
2.1. CRLF
CRLF指回车和换行的组合，也就是十进制13加上10的组合。如果不熟悉ASCII码，请您自己查询有关资料。这里不再详细说明了。
2.2. 字符集
用在MIME中的字符集指的是将和一种字符序列转换为另一种字符序列的方法。请注意：这里指的是单向的转换，不需要将转换过的序列再无误地转换回来。这种定义允许不同的字符编码用作字符集，但是与MIME字符集名相关的定义必须完全指定所要进行的转换（映射）操作。
2.3. 消息
在没有特别说明的它指文件内容包括的内容。
2.4. 实体
实体指的是MIME定义的域和消息的内容或多部分实体的内容的一部分。这是MIME的精华之所在。实体的内容通常称为体。域的任何类型都可以在实体中出现，但是只有以"content-"开头的才有与MIME相关的意义，这并不说明它们没有意思。
2.5. 体部分
体部分指的是在多部分实体内的一个实体。
2.6. 体
这个名词指的是一个实体的体部分。请注意：上面四个定义是循环的，这是不可避免的，因为MIME消息本身就是循环定义的。
2.7. 7bit数据
7bit数据指的是两个CRLF之间的字符数少于998，而且每个字符不大于127。回车和换行只用作分隔之用。
2.8. 8bit数据
7bit数据指的是两个CRLF之间的字符数少于998，而且每个字符可以大于127。回车和换行只用作分隔之用。
2.9. 二进制数据
二进制数据指不限制数据的大小。
2.10. 行
所谓行就是两个CRLF之间的字符序列。
3. MIME头域
MIME定义了一些新的头域用来描述MIME体的内容。这些头域发生在以下两种情况下：
(1) 作为通常邮件内容的一部分；
(2) 在一个MIME体部分头中；
以下是这些头域的通常定义：
entity-headers := [ 内容 CRLF ] [ 编码 CRLF ] [ id CRLF ] [ 描述CRLF ] *( MIME扩展域CRLF )
MIME-message-headers := entity-headers fields
版本 CRLF //BNF表示中的顺序在这里不起作用；
MIME-part-headers := entity-headers [ fields ] //BNF表示中的顺序在这里不起作用；未以"content-"开头的域忽略
不同的特定的MIME头域在下面会加以说明。
4. MIME版本头域
因为通常的邮件格式一直是作为邮件唯一的格式被使用的，因此也没有什么标准可言，这里说明的规范与通常的邮件格式没有什么关系，因此也就定义了一个新的头域"MIME-Version"，它是用来声明使用的Internet消息体格式标准版本的。根据本文生成的文档必须包括这样的头域内容：
MIME-Version: 1.0
因为以后的标准可能会为本文所描述的标准有所扩展，所以版本域的格式如下定义：
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
如果接收到的版本号小于1.0，它所遵守的标准不是本文所描述的标准。这个头域必须包括在消息的头部，但是对于多部分体的每个体部分就不是非要不可了。本文不对未来的标准作出规定。MIME内可以包括不同格式的文件，这些格式可以有不同的版本，这些版本号和我们上面的版本号可不是一回事，这些版本号在媒介格式内指定，如果一定要指定媒介版本号，这些媒介格式可以用"version"参数指定。
实现者请注意：下面三种格式是等效的：
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
如果没有MIME版本域，接收方可以根据自己的方法解释消息体。但这样做可能导致文件内容显示时有问题，因为对方传送过来的可能是压缩文件，而直接压缩文件则是根本不可读的。
5. 内容类型头域
本域的目的就是使接收方能够正确识别内容作相应的操作把内容以合适的方式提交给用户。本域中的值称为媒介类型。
这个域指定实体内体的数据属性。它给出媒介类型和子类型标记，还提供一些辅助的参数信息，在媒介类型和子类型名后是一些参数，这些参数是以“属性=值”的形式给出，参数的顺序没有关系。
通常顶级媒介类型用于声明数据的通常类型，而子类型指出这种数据类型的特定格式。因此，如下格式的说明"image/xyz"足以向用户说明传送的数据是一幅图，既然用户根本不知道这个后面的XYZ是个什么东西也没有关系。这对于用户来说是很重要的，因为用户知道了类型以后可以根据类型采取相应的行动，不会把一幅图当文本显示出来。如果数据有多个类型，应该使用"multipart"或"application"声明。
参数并不影响类型的内容，是什么还是什么，因此参数集只有相对于某种特定的类型和子类型时才有意义。主类型和子类型都有自己的参数，有的参数是必须的，有的是可选的，MIME必须忽略不能识别的参数。例如："charset"参数用于所有"text"的子类型，而"boundary"对于"multipart"类型的子类型是必须的。在MIME中没有可以用于所有类型的参数。
MIME的类型和每个类型下的子类型请参阅其它资料，这里就不一一说明了。只要大家注意一下，有两种混合类型需要特别处理一下。
顶级媒介类型是安全的，如果需要添加新的文件，只需要在相应的顶级类型下添加新的子类型即可。当然，未来可能会添加新的顶级类型，但那也是对本文档的扩展。如果用户真需要自己的顶级类型，请以"X-"开始以说明这不是一个标准的顶级类型。
5.1. 内容类型头域语法
content := "Content-Type" ":" type "/" subtype *(";" parameter)
//类型与子类型对大小写敏感；
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <在IANA注册的扩展标记或由RFC定义的扩展标记>
x-token := <以"X-"或"x-"开始的字符串，请注意在"X-"或"x-"后面不能有空格>
subtype := extension-token / iana-token
iana-token := <标准定义的扩展标记>
parameter := attribute "=" value
attribute := token //对大小写敏感；
value := token / quoted-string
token := 1*<任何ASCII码，除了空格控制字符和tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="
"tspecials"的定义比标准邮件协议中多了"/"，"?"和"="，少了"."，另外，子类型不能为空，不存在默认的子类型。类型，子类型和参数对大小写不敏感。参数通常对大小写敏感。请注意：下面两个是完全等效的：
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
这个语法中没有体现出来的限制就是，子类型名不能冲突。自己定义的类型名必须以"X-"开始，而且接收方和发送方都必须理解这个类型的意义是什么，而且能够做出适当的处理。
5.2. 内容类型默认值
默认的标准电子邮件信息（内容只是ASCII码）不以MIME内容类型头开始，这可以说成是内容的默认值吧，如果非要用MIME进行说明，那么说明如下：
Content-type: text/plain; charset=us-ascii
如果内容的规定有冲突也使用默认值，只有MIME版本头域而没有任何内容类型头域时，接收方也认为它是普通的ASCII字符集信息。如果没有MIME版本时，也要使用默认值。
6. 内容传送编码头域
许多可以通常电子邮件传送的媒介类型可以以8bit字符或二进制数据传送。这样的数据可以在一些传输协议上进传送。我们应该注意，通常的电子邮件协议（SMTP）限制邮件内容为7位数据，而且每行不得多于1000个字符，每行必须以CRLF结束。
因为有必须定义一种机制用于将类似的数据编制为7位短行格式。正确标准未编码的信息为限制较少的格式（以供直接传送）也十分必要。本文说明“内容传送编码”头域达到这一功能。
6.1. 内容传送编码语法
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token
以上的数值不区别大小写。7位编码是默认值。
6.2. 内容传送编码语义
这个单独的内容传送编码实际上提供两种信息，它指出内容进行了什么编码，也指出了解码应该进行什么操作。请注意：对有效编码方式解码器没有什么限制。现在定义了三种传送方式：标记式编码，"quoted-printable"编码和"base64"编码。域有二进制，8位和7位三种。
内容传送编码值7位，8位和二进制都指使用标记式编码传送方式。因此，它们说明了体数据大概是什么样的东西，同时也提供了关于在给定传送系统中传送的所需要的编码类型。quoted-printable类型和base64类型传送的数据编码属于7位范围，这使得这两种编码方式能够在要求严格的传送协议上进行传送。
必须使用正确的内容传送编码标记。不能把包括8位数据的信息标记为7位，也不能标记为其它类型（二进制除外）。在编码的时候要注意传送效率和可读性的平衡。因为这个原因，需要两种编码方式：quoted-printable编码和base64编码方式。原来的邮件中不能包括二进制数据，但是随着包括MIME在内的其它邮件传送方式的广泛使用，二进制数据已经进入了邮件中。这也就是我们现在为什么能够使用电子邮件传送图画和其它二进制文件的原因了。
注意：内容传送编码域中的值不代表内容是什么东西，它只表示对内容的编码方式或传送系统要求的编码方式。
6.3. 新内容传送编码
如果用户需要实现自己规定的编码方式，必须在前面加上"X-"，表明这不是一个标准的编码方式，不要轻易使用自己规定的编码方式。
6.4. 解释与使用
如果内容传送头域作为消息头的一部分，那它对整个消息体起作用；如果它只在实体中的头中出现，它的作用域就只是这个实体。如果实体的是"multipart"类型，内容传送头域只能是"7bit"，"8bit"或"binary"三种。
应该注意大部分的媒介类型以字节定义而不是以位定义，所以这里定义的编码方式均是以面向字节的，而不是面向位的。如果需要通过这些机制编码位流，必须先转换为8位字节流，不足8位的要以填充位填充。本文中默认的编码方式是对ASCII码的，所以当您看到下面的叙述：
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
它指的是源文件是ISO-8895-1类型的，而编码方式为base64。内容传送编码和媒介类型有搭配关系，不要混用，特别是对于混合型文件不要便用除"7bit"，"8bit"或"binary"以外的编码方式。
不要让只需要7位编码的数据应用8位编码对传送系统造成不必要的负担，也不要把本应该以8位编码编码的数据应用了7位编码，这样就会造成数据错误。如果内容传送编码不可理解，一般它会被看作"application/octet-stream"。
6.5. 转换编码
quoted-printable和base64可以相互转换，转换时唯一应该考虑的问题就是在quoted-printable中的回车换行，quoted-printable中的回车换行必须转换为标准的base64回车换行；同样，base64中的回车换行必须转换为quoted-printable中的回车换行。
6.7. Quoted-Printable内容传送编码
Quoted-Printable编码的大部分和用于表示的数据一般和可打印的ASCII码数据差不多。这种编码方式可以使信件内容不会邮件传送机制更改。如果数据被编码后仍然大部分是ASCII码，那么人还能够认出大部分内容。
在这种编码方式中有以下规则：
(1) （通常8位表示）任何字节（除了回车符和换行符）都可以用"="加上字节的数值加以表示。应该使用十六进制数表示："0123456789ABCDEF"，请注意，一定要使用大定字母。除了以下两种情况，通常情况下都应用这个规则。
(2) （直接表示）如果字节的十进制数值在33至60，或在62至126之间，可以直接以数数值相等的ASCII码表示。
(3) （空格类）ASCII码9和32分别是制表符（TAB）和空格（SPACE），这些字符不能直接在编码行中出现。它们必须跟着一个可打印的字符。特别的，在编码行未尾的"="指示一个软回画，在其后可以跟一个或多个TAB或SPACE。其它情况下对空格类字符的编码请遵守规则（1）进行，这是因为有些MTA（消息传送代理）可能把句子未尾的空格和其它空格类字符给删除了。
(4) （回车类）文本中的硬回车符在Quoted-Printable编码中也有。因为除了文本以外其它的媒介一般不会用CRLF当回车符。
(5) （软回车类）Quoted-Printable编码要求编码行不的长度不得多于76个字符，如果编码行实在太长，必须使用软回车。看看下面的例子：
如果源数据为：Now's the time for all folk to come to the aid of their country.那么编码出的数据应该为：
Now's the time =
for all folk to come=
to the aid of their country.
76个字符中不包括尾部的CRLF，但是包括编码行中的等号。
因为连线符可以自已代表自己，而边界标记中也有这个东西，所以一定要小心，不要让用户方误以为体中的一个连线符"-"是边界标记。
请注意：quoted-printable编码方式是在可读性和可靠的传送之间取了一个平衡，它在大部的邮件网关上工作正常，但是有一些邮件网关却不行，如EBCDIC网关，为了能够与这些网关一起正常工作，最好把“!"#$@[\]^`{|}~”应用规则1进行编码。因为quoted-printable数据是面向行的，如果不同的邮件系统有不同的表示回车换行的标准的话，就要小心了，如果确实因为回车换行的问题破坏了数据，最好使用base64编码。
对于二进制数据应用quoted-printable编码，要特别注意CRLF和CR，LF的问题。还应该注意对方平台上对CRLF的解释规则。下面列出了quoted-printable数据的语法：
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding
qp-part := qp-section //最大长度76个字符；
qp-segment := qp-section *(SPACE / TAB) "=" //最大长度76个字符；
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char := <数值在33至60，62至126之间的字符>
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
transport-padding := *LWSP-char
不允许在元素之间加入LWSP。
6.8. Base64内容传送编码
Base64内容传送编码所应用的数据通常不是让人直接读的，而编码和解码的算法一般也比较简单，编码后的数据比编码前大33%。它使用了ASCII码的子体，用6位代表可打印字符，第65个字符"="用于指定特定的处理函数。请注意，这个子集有一个重要的特点，它在所有版本的ISO 646中都是一样的。有一些流行的编码方式如Macintosh的binhex 4.0和base85编码没有这个性质。
24位的输入组经编码后成为4个字符的输出。从左至右，24位的输入可以由3个8位的输入组合并而成。这24为被当作4个6位的组，每个组的数据根据base64字母对应表转换一个数。当位流通过base64编码后，位流变为最高位优先，也就是说，流中的第一个位成为8位字节中的最高位，而第8位则成为第一个8位字节的最低位。
表1：Base64字母对应表
0
A
17
R
34
i
51
z
1
B
18
S
35
j
52
0
2
C
19
T
36
k
53
1
3
D
20
U
37
l
54
2
4
E
21
V
38
m
55
3
5
F
22
W
39
n
56
4
6
G
23
X
40
o
57
5
7
H
24
Y
41
p
58
6
8
I
25
Z
42
q
59
7
9
J
26
a
43
r
60
8
10
K
27
b
44
s
61
9
11
L
28
c
45
t
62
+
12
M
29
d
46
u
63
/
13
N
30
e
47
v
14
O
31
f
48
w
(pad)
=
15
P
32
g
49
x
16
Q
33
h
50
y
编码输出流中行的长度不得大于76个字符。所有回车换行符或其它未在上表中定义的字符会被解码软件忽略。如果在编码中确实出现了不属于上表中的数据，这说明传送中有错误，要给出警告信息，或者（在某种情况下）拒绝接收。
当输入少于24位时，会有一个特殊的处理。0位被添加到最右端，以形成完整的6位组。使用“=”在尾部添加数据。因为所有的base64数据都是完整的8位，所以只会发生以下情况：（1）输入是24的倍数，则输出将是4个字符的倍数，这时不需要用“=”添加。（2）输入的最尾是8位，则输出的最尾是两个字符外加两个“=”添加符。（3）输入的最尾是16位，则输出的最尾是3个字符，外加一个“=”添加符。
因为“=”只用于添加数据，所以“=”的出现可以被看作到了数据的最末。但是也可能没有这种情况，如成熟传输的数据是3的倍数。
任何不属于上面表中字符的数据不被认为是base64编码数据。在文本没有被转换为标准格式前对它应用base64编码时要注意对回车换行的处理。文本中的回车换行符应该在进行编码前转换为CRLF。另外请注意：在base64编码中不必关心连字符，因为编码中根本不会出现连字符。
7. 内容ID头域
在建立高层用户代理时，可能希望体之间产生关联，因此体可以使用内容ID头域，它的语法如下：
id := "Content-ID" ":" msg-id
象消息ID值一样，它必须是全世界唯一的。内容ID值在代理服务器缓存体数据时特别有用，虽然它的应用是可选的，但是如果MIME媒介类型是"message/external-body"的话，它是必选的。应该特别注意的是内容ID值对multipart/alternative类型有特殊的语义。
8. 内容描述头域
使给定的体附加一些描述信息是很有好处的，于是有了这个可选的内容描述头域，它的语法如下：
description := "Content-Description" ":" *text
一般来说，描述内容只能是ASCII码，当然也可以是非ASCII内容（要当心有的系统不支持）。
9. 附加MIME头域
在将来可以会定义新的MIME头域，任何新的头域必须以"Content-"开始。
MIME-extension-field := <以"Content-"开始的任何头域>
1. 介绍
通常的邮件格式于1982年出现以来，它已经被广为使用，在使用的过程中，一些不足之处也开始暴露出来。通常的电子邮件是一种文本格式的消息，这样一来，一些非文本的信息，如多媒体信息就无法传送；就算在文本方面，这种文件格式在传送非ASCII码的文本时也有些不足。
原来邮件协议的一个重大的不足在于，它限制文本的内容是一行内容相应比较短的7位ASCII码。这带来了许多麻烦。这个不足在网关允许在通常的电子邮件主机和X.400主机之间通信后变得更加突出，X.400指定了一种发送非文本内容电子邮件的机制，将X.400发向通常的电子邮件主机时，要么把内容转换成IA5Text格式，或者抛弃，并同时通知接收者有信息在传送中被丢弃。
本文主要描述一些机制可以解决上述问题，特点地它描述了MIME版本头域，内容类型头域，内容传送编码头域和用于描述文件内容的两个头域。在阅读此文档时可能有些地方您会觉得非常怪，这是为了照顾到和不同的版本进行兼容而不得不这样。
2. 定义、惯例和基本BNF语法
本文中的所有参数和名称均是大小写敏感的。对于BNF语法不熟悉的请参阅其它资料。
2.1. CRLF
CRLF指回车和换行的组合，也就是十进制13加上10的组合。如果不熟悉ASCII码，请您自己查询有关资料。这里不再详细说明了。
2.2. 字符集
用在MIME中的字符集指的是将和一种字符序列转换为另一种字符序列的方法。请注意：这里指的是单向的转换，不需要将转换过的序列再无误地转换回来。这种定义允许不同的字符编码用作字符集，但是与MIME字符集名相关的定义必须完全指定所要进行的转换（映射）操作。
2.3. 消息
在没有特别说明的它指文件内容包括的内容。
2.4. 实体
实体指的是MIME定义的域和消息的内容或多部分实体的内容的一部分。这是MIME的精华之所在。实体的内容通常称为体。域的任何类型都可以在实体中出现，但是只有以"content-"开头的才有与MIME相关的意义，这并不说明它们没有意思。
2.5. 体部分
体部分指的是在多部分实体内的一个实体。
2.6. 体
这个名词指的是一个实体的体部分。请注意：上面四个定义是循环的，这是不可避免的，因为MIME消息本身就是循环定义的。
2.7. 7bit数据
7bit数据指的是两个CRLF之间的字符数少于998，而且每个字符不大于127。回车和换行只用作分隔之用。
2.8. 8bit数据
7bit数据指的是两个CRLF之间的字符数少于998，而且每个字符可以大于127。回车和换行只用作分隔之用。
2.9. 二进制数据
二进制数据指不限制数据的大小。
2.10. 行
所谓行就是两个CRLF之间的字符序列。
3. MIME头域
MIME定义了一些新的头域用来描述MIME体的内容。这些头域发生在以下两种情况下：
(1) 作为通常邮件内容的一部分；
(2) 在一个MIME体部分头中；
以下是这些头域的通常定义：
entity-headers := [ 内容 CRLF ] [ 编码 CRLF ] [ id CRLF ] [ 描述CRLF ] *( MIME扩展域CRLF )
MIME-message-headers := entity-headers fields
版本 CRLF //BNF表示中的顺序在这里不起作用；
MIME-part-headers := entity-headers [ fields ] //BNF表示中的顺序在这里不起作用；未以"content-"开头的域忽略
不同的特定的MIME头域在下面会加以说明。
4. MIME版本头域
因为通常的邮件格式一直是作为邮件唯一的格式被使用的，因此也没有什么标准可言，这里说明的规范与通常的邮件格式没有什么关系，因此也就定义了一个新的头域"MIME-Version"，它是用来声明使用的Internet消息体格式标准版本的。根据本文生成的文档必须包括这样的头域内容：
MIME-Version: 1.0
因为以后的标准可能会为本文所描述的标准有所扩展，所以版本域的格式如下定义：
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
如果接收到的版本号小于1.0，它所遵守的标准不是本文所描述的标准。这个头域必须包括在消息的头部，但是对于多部分体的每个体部分就不是非要不可了。本文不对未来的标准作出规定。MIME内可以包括不同格式的文件，这些格式可以有不同的版本，这些版本号和我们上面的版本号可不是一回事，这些版本号在媒介格式内指定，如果一定要指定媒介版本号，这些媒介格式可以用"version"参数指定。
实现者请注意：下面三种格式是等效的：
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
如果没有MIME版本域，接收方可以根据自己的方法解释消息体。但这样做可能导致文件内容显示时有问题，因为对方传送过来的可能是压缩文件，而直接压缩文件则是根本不可读的。
5. 内容类型头域
本域的目的就是使接收方能够正确识别内容作相应的操作把内容以合适的方式提交给用户。本域中的值称为媒介类型。
这个域指定实体内体的数据属性。它给出媒介类型和子类型标记，还提供一些辅助的参数信息，在媒介类型和子类型名后是一些参数，这些参数是以“属性=值”的形式给出，参数的顺序没有关系。
通常顶级媒介类型用于声明数据的通常类型，而子类型指出这种数据类型的特定格式。因此，如下格式的说明"image/xyz"足以向用户说明传送的数据是一幅图，既然用户根本不知道这个后面的XYZ是个什么东西也没有关系。这对于用户来说是很重要的，因为用户知道了类型以后可以根据类型采取相应的行动，不会把一幅图当文本显示出来。如果数据有多个类型，应该使用"multipart"或"application"声明。
参数并不影响类型的内容，是什么还是什么，因此参数集只有相对于某种特定的类型和子类型时才有意义。主类型和子类型都有自己的参数，有的参数是必须的，有的是可选的，MIME必须忽略不能识别的参数。例如："charset"参数用于所有"text"的子类型，而"boundary"对于"multipart"类型的子类型是必须的。在MIME中没有可以用于所有类型的参数。
MIME的类型和每个类型下的子类型请参阅其它资料，这里就不一一说明了。只要大家注意一下，有两种混合类型需要特别处理一下。
顶级媒介类型是安全的，如果需要添加新的文件，只需要在相应的顶级类型下添加新的子类型即可。当然，未来可能会添加新的顶级类型，但那也是对本文档的扩展。如果用户真需要自己的顶级类型，请以"X-"开始以说明这不是一个标准的顶级类型。
5.1. 内容类型头域语法
content := "Content-Type" ":" type "/" subtype *(";" parameter)
//类型与子类型对大小写敏感；
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <在IANA注册的扩展标记或由RFC定义的扩展标记>
x-token := <以"X-"或"x-"开始的字符串，请注意在"X-"或"x-"后面不能有空格>
subtype := extension-token / iana-token
iana-token := <标准定义的扩展标记>
parameter := attribute "=" value
attribute := token //对大小写敏感；
value := token / quoted-string
token := 1*<任何ASCII码，除了空格控制字符和tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="
"tspecials"的定义比标准邮件协议中多了"/"，"?"和"="，少了"."，另外，子类型不能为空，不存在默认的子类型。类型，子类型和参数对大小写不敏感。参数通常对大小写敏感。请注意：下面两个是完全等效的：
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
这个语法中没有体现出来的限制就是，子类型名不能冲突。自己定义的类型名必须以"X-"开始，而且接收方和发送方都必须理解这个类型的意义是什么，而且能够做出适当的处理。
5.2. 内容类型默认值
默认的标准电子邮件信息（内容只是ASCII码）不以MIME内容类型头开始，这可以说成是内容的默认值吧，如果非要用MIME进行说明，那么说明如下：
Content-type: text/plain; charset=us-ascii
如果内容的规定有冲突也使用默认值，只有MIME版本头域而没有任何内容类型头域时，接收方也认为它是普通的ASCII字符集信息。如果没有MIME版本时，也要使用默认值。
6. 内容传送编码头域
许多可以通常电子邮件传送的媒介类型可以以8bit字符或二进制数据传送。这样的数据可以在一些传输协议上进传送。我们应该注意，通常的电子邮件协议（SMTP）限制邮件内容为7位数据，而且每行不得多于1000个字符，每行必须以CRLF结束。
因为有必须定义一种机制用于将类似的数据编制为7位短行格式。正确标准未编码的信息为限制较少的格式（以供直接传送）也十分必要。本文说明“内容传送编码”头域达到这一功能。
6.1. 内容传送编码语法
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token
以上的数值不区别大小写。7位编码是默认值。
6.2. 内容传送编码语义
这个单独的内容传送编码实际上提供两种信息，它指出内容进行了什么编码，也指出了解码应该进行什么操作。请注意：对有效编码方式解码器没有什么限制。现在定义了三种传送方式：标记式编码，"quoted-printable"编码和"base64"编码。域有二进制，8位和7位三种。
内容传送编码值7位，8位和二进制都指使用标记式编码传送方式。因此，它们说明了体数据大概是什么样的东西，同时也提供了关于在给定传送系统中传送的所需要的编码类型。quoted-printable类型和base64类型传送的数据编码属于7位范围，这使得这两种编码方式能够在要求严格的传送协议上进行传送。
必须使用正确的内容传送编码标记。不能把包括8位数据的信息标记为7位，也不能标记为其它类型（二进制除外）。在编码的时候要注意传送效率和可读性的平衡。因为这个原因，需要两种编码方式：quoted-printable编码和base64编码方式。原来的邮件中不能包括二进制数据，但是随着包括MIME在内的其它邮件传送方式的广泛使用，二进制数据已经进入了邮件中。这也就是我们现在为什么能够使用电子邮件传送图画和其它二进制文件的原因了。
注意：内容传送编码域中的值不代表内容是什么东西，它只表示对内容的编码方式或传送系统要求的编码方式。
6.3. 新内容传送编码
如果用户需要实现自己规定的编码方式，必须在前面加上"X-"，表明这不是一个标准的编码方式，不要轻易使用自己规定的编码方式。
6.4. 解释与使用
如果内容传送头域作为消息头的一部分，那它对整个消息体起作用；如果它只在实体中的头中出现，它的作用域就只是这个实体。如果实体的是"multipart"类型，内容传送头域只能是"7bit"，"8bit"或"binary"三种。
应该注意大部分的媒介类型以字节定义而不是以位定义，所以这里定义的编码方式均是以面向字节的，而不是面向位的。如果需要通过这些机制编码位流，必须先转换为8位字节流，不足8位的要以填充位填充。本文中默认的编码方式是对ASCII码的，所以当您看到下面的叙述：
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
它指的是源文件是ISO-8895-1类型的，而编码方式为base64。内容传送编码和媒介类型有搭配关系，不要混用，特别是对于混合型文件不要便用除"7bit"，"8bit"或"binary"以外的编码方式。
不要让只需要7位编码的数据应用8位编码对传送系统造成不必要的负担，也不要把本应该以8位编码编码的数据应用了7位编码，这样就会造成数据错误。如果内容传送编码不可理解，一般它会被看作"application/octet-stream"。
6.5. 转换编码
quoted-printable和base64可以相互转换，转换时唯一应该考虑的问题就是在quoted-printable中的回车换行，quoted-printable中的回车换行必须转换为标准的base64回车换行；同样，base64中的回车换行必须转换为quoted-printable中的回车换行。
6.7. Quoted-Printable内容传送编码
Quoted-Printable编码的大部分和用于表示的数据一般和可打印的ASCII码数据差不多。这种编码方式可以使信件内容不会邮件传送机制更改。如果数据被编码后仍然大部分是ASCII码，那么人还能够认出大部分内容。
在这种编码方式中有以下规则：
(1) （通常8位表示）任何字节（除了回车符和换行符）都可以用"="加上字节的数值加以表示。应该使用十六进制数表示："0123456789ABCDEF"，请注意，一定要使用大定字母。除了以下两种情况，通常情况下都应用这个规则。
(2) （直接表示）如果字节的十进制数值在33至60，或在62至126之间，可以直接以数数值相等的ASCII码表示。
(3) （空格类）ASCII码9和32分别是制表符（TAB）和空格（SPACE），这些字符不能直接在编码行中出现。它们必须跟着一个可打印的字符。特别的，在编码行未尾的"="指示一个软回画，在其后可以跟一个或多个TAB或SPACE。其它情况下对空格类字符的编码请遵守规则（1）进行，这是因为有些MTA（消息传送代理）可能把句子未尾的空格和其它空格类字符给删除了。
(4) （回车类）文本中的硬回车符在Quoted-Printable编码中也有。因为除了文本以外其它的媒介一般不会用CRLF当回车符。
(5) （软回车类）Quoted-Printable编码要求编码行不的长度不得多于76个字符，如果编码行实在太长，必须使用软回车。看看下面的例子：
如果源数据为：Now's the time for all folk to come to the aid of their country.那么编码出的数据应该为：
Now's the time =
for all folk to come=
to the aid of their country.
76个字符中不包括尾部的CRLF，但是包括编码行中的等号。
因为连线符可以自已代表自己，而边界标记中也有这个东西，所以一定要小心，不要让用户方误以为体中的一个连线符"-"是边界标记。
请注意：quoted-printable编码方式是在可读性和可靠的传送之间取了一个平衡，它在大部的邮件网关上工作正常，但是有一些邮件网关却不行，如EBCDIC网关，为了能够与这些网关一起正常工作，最好把“!"#$@[\]^`{|}~”应用规则1进行编码。因为quoted-printable数据是面向行的，如果不同的邮件系统有不同的表示回车换行的标准的话，就要小心了，如果确实因为回车换行的问题破坏了数据，最好使用base64编码。
对于二进制数据应用quoted-printable编码，要特别注意CRLF和CR，LF的问题。还应该注意对方平台上对CRLF的解释规则。下面列出了quoted-printable数据的语法：
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding
qp-part := qp-section //最大长度76个字符；
qp-segment := qp-section *(SPACE / TAB) "=" //最大长度76个字符；
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char := <数值在33至60，62至126之间的字符>
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
transport-padding := *LWSP-char
不允许在元素之间加入LWSP。
6.8. Base64内容传送编码
Base64内容传送编码所应用的数据通常不是让人直接读的，而编码和解码的算法一般也比较简单，编码后的数据比编码前大33%。它使用了ASCII码的子体，用6位代表可打印字符，第65个字符"="用于指定特定的处理函数。请注意，这个子集有一个重要的特点，它在所有版本的ISO 646中都是一样的。有一些流行的编码方式如Macintosh的binhex 4.0和base85编码没有这个性质。
24位的输入组经编码后成为4个字符的输出。从左至右，24位的输入可以由3个8位的输入组合并而成。这24为被当作4个6位的组，每个组的数据根据base64字母对应表转换一个数。当位流通过base64编码后，位流变为最高位优先，也就是说，流中的第一个位成为8位字节中的最高位，而第8位则成为第一个8位字节的最低位。
表1：Base64字母对应表
0
A
17
R
34
i
51
z
1
B
18
S
35
j
52
0
2
C
19
T
36
k
53
1
3
D
20
U
37
l
54
2
4
E
21
V
38
m
55
3
5
F
22
W
39
n
56
4
6
G
23
X
40
o
57
5
7
H
24
Y
41
p
58
6
8
I
25
Z
42
q
59
7
9
J
26
a
43
r
60
8
10
K
27
b
44
s
61
9
11
L
28
c
45
t
62
+
12
M
29
d
46
u
63
/
13
N
30
e
47
v
14
O
31
f
48
w
(pad)
=
15
P
32
g
49
x
16
Q
33
h
50
y
编码输出流中行的长度不得大于76个字符。所有回车换行符或其它未在上表中定义的字符会被解码软件忽略。如果在编码中确实出现了不属于上表中的数据，这说明传送中有错误，要给出警告信息，或者（在某种情况下）拒绝接收。
当输入少于24位时，会有一个特殊的处理。0位被添加到最右端，以形成完整的6位组。使用“=”在尾部添加数据。因为所有的base64数据都是完整的8位，所以只会发生以下情况：（1）输入是24的倍数，则输出将是4个字符的倍数，这时不需要用“=”添加。（2）输入的最尾是8位，则输出的最尾是两个字符外加两个“=”添加符。（3）输入的最尾是16位，则输出的最尾是3个字符，外加一个“=”添加符。
因为“=”只用于添加数据，所以“=”的出现可以被看作到了数据的最末。但是也可能没有这种情况，如成熟传输的数据是3的倍数。
任何不属于上面表中字符的数据不被认为是base64编码数据。在文本没有被转换为标准格式前对它应用base64编码时要注意对回车换行的处理。文本中的回车换行符应该在进行编码前转换为CRLF。另外请注意：在base64编码中不必关心连字符，因为编码中根本不会出现连字符。
7. 内容ID头域
在建立高层用户代理时，可能希望体之间产生关联，因此体可以使用内容ID头域，它的语法如下：
id := "Content-ID" ":" msg-id
象消息ID值一样，它必须是全世界唯一的。内容ID值在代理服务器缓存体数据时特别有用，虽然它的应用是可选的，但是如果MIME媒介类型是"message/external-body"的话，它是必选的。应该特别注意的是内容ID值对multipart/alternative类型有特殊的语义。
8. 内容描述头域
使给定的体附加一些描述信息是很有好处的，于是有了这个可选的内容描述头域，它的语法如下：
description := "Content-Description" ":" *text
一般来说，描述内容只能是ASCII码，当然也可以是非ASCII内容（要当心有的系统不支持）。
9. 附加MIME头域
在将来可以会定义新的MIME头域，任何新的头域必须以"Content-"开始。
MIME-extension-field := <以"Content-"开始的任何头域>
xzjxu 2001-02-16
- 打赏
- 举报
to ndd,
334 是说继续交谈
235 是说成功
334 是说继续交谈
235 是说成功
ndd 2001-02-16
- 打赏
- 举报
MIME/BASE64 的算法，它将字符流顺序放入一个 24 位的缓冲区，缺
字符的地方补零。然后将缓冲区截断成为 4 个部分，高位在先，每个部分 6 位，
用下面的64个字符重新表示：“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop
qrstuvwxyz0123456789+/”。如果输入只有一个或两个字节，那么输出将用等号
“=”补足。这可以隔断附加的信息造成编码的混乱。这就是BASE64。
从客户端返回的用户名和BASE64编码方法看， 一定是通过 BASE64 编码过的（ 用户名后有一 = 号）
字符的地方补零。然后将缓冲区截断成为 4 个部分，高位在先，每个部分 6 位，
用下面的64个字符重新表示：“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop
qrstuvwxyz0123456789+/”。如果输入只有一个或两个字节，那么输出将用等号
“=”补足。这可以隔断附加的信息造成编码的混乱。这就是BASE64。
从客户端返回的用户名和BASE64编码方法看， 一定是通过 BASE64 编码过的（ 用户名后有一 = 号）
ndd 2001-02-16
- 打赏
- 举报
to xzjxu
那服务器返回的 334 ieojfkfjdk 是什么东西呢，不会一点用都没有吧，
那服务器返回的 334 ieojfkfjdk 是什么东西呢，不会一点用都没有吧，
ndd 2001-02-16
- 打赏
- 举报
这个问题只给了10分，真是太少了，对不起大家了^_*
ndd 2001-02-16
- 打赏
- 举报
下面是一次和带smtp认证的服务器通话的一个过程，有需要的朋友可以了解一下整个的发信过程
用户请求联接................
联接成功
服务器回答:
220-smtp03.sohu.com Microsoft SMTP MAIL ready at Fri, 16 Feb 2001 14:19:31 +0800 Version: 5.5.1877.197.19
220 ESMTP spoken here
客户说:
EHLO snake
服务器回答:
250-smtp03.sohu.com Hello [61.158.192.197]
250-AUTH=LOGIN
250-AUTH MBS_BASIC LOGIN
250-AUTH=MBS_BASIC LOGIN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-8bitmime
250-TURN
250-ATRN
250-STARTTLS
250 TLS
客户说:
AUTH LOGIN
服务器回答:
334 VXNlcm5hbWU6
客户说:
bW1vddddbmU= 'BASE64编码的用户名
服务器回答:
334 UGFzc3dvcmQ6 '这串乱字符是什么？？？
客户说:
dWFsssN4 'base64编码的密码
服务器回答:
235 Authentication successful
客户说:
MAIL FROM: <ddd@263.net>
服务器回答:
250 ddd.net....Sender OK
客户说:
RCPT TO: <ddd@263.net>
服务器回答:
250 ddd@263.net
客户说:
DATA
服务器回答:
354 Start mail input; end with <CRLF>.<CRLF>
客户说:
Message-ID: <000a01c08f3b$c974eea0$c5c09e3d@snake>
From: "jack" <ddd@263.net>
To: "jack" <ddd@263.net>
Subject: 好
Date: Mon, 5 Feb 2001 14:18:19 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
dfdsfdddddddf
. '结束
服务器回答:
250 048983219061021SMTP03 Queued mail for delivery
客户说:
QUIT
服务器回答:
221 smtp03.sohu.com Service closing transmission channel
用户请求联接................
联接成功
服务器回答:
220-smtp03.sohu.com Microsoft SMTP MAIL ready at Fri, 16 Feb 2001 14:19:31 +0800 Version: 5.5.1877.197.19
220 ESMTP spoken here
客户说:
EHLO snake
服务器回答:
250-smtp03.sohu.com Hello [61.158.192.197]
250-AUTH=LOGIN
250-AUTH MBS_BASIC LOGIN
250-AUTH=MBS_BASIC LOGIN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-8bitmime
250-TURN
250-ATRN
250-STARTTLS
250 TLS
客户说:
AUTH LOGIN
服务器回答:
334 VXNlcm5hbWU6
客户说:
bW1vddddbmU= 'BASE64编码的用户名
服务器回答:
334 UGFzc3dvcmQ6 '这串乱字符是什么？？？
客户说:
dWFsssN4 'base64编码的密码
服务器回答:
235 Authentication successful
客户说:
MAIL FROM: <ddd@263.net>
服务器回答:
250 ddd.net....Sender OK
客户说:
RCPT TO: <ddd@263.net>
服务器回答:
250 ddd@263.net
客户说:
DATA
服务器回答:
354 Start mail input; end with <CRLF>.<CRLF>
客户说:
Message-ID: <000a01c08f3b$c974eea0$c5c09e3d@snake>
From: "jack" <ddd@263.net>
To: "jack" <ddd@263.net>
Subject: 好
Date: Mon, 5 Feb 2001 14:18:19 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
dfdsfdddddddf
. '结束
服务器回答:
250 048983219061021SMTP03 Queued mail for delivery
客户说:
QUIT
服务器回答:
221 smtp03.sohu.com Service closing transmission channel
ndd 2001-02-16
- 打赏
- 举报
谢谢xyjxu,谢谢各位，的确没有什么附加的加密方法，只是用了BASE64把用户名和口令编码了而已，（服务器返回的 334 和一串乱字符，再加上我的BASE64实现方法有些问题，让我一直认为服务器返回的是密钥）现在好了。谢谢大家帮忙.
ndd 2001-02-15
- 打赏
- 举报
那服务器返回的密钥呢，是用它加密后才传给服务器的吧，用的什么算法呢？是不是先加密再用BASE64进行编码呢?
bucher 2001-02-15
- 打赏
- 举报
在news.webking.com 有base64和uuencode的算法.
xzjxu 2001-02-15
- 打赏
- 举报
主要是去弄清楚什么是base64算法
mudfans 2001-02-15
- 打赏
- 举报
可否告知smtp认证的详细过程，最好带上相应的源代码！！！
xzjxu 2001-02-15
- 打赏
- 举报
没有密钥，就是base64加密算法
xzjxu 2001-02-14
- 打赏
- 举报
应该是base64
