S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...等等
S: <CRLF>.<CRLF>
R: 250 OK
此信被前两个人接收,而第三个人在此主机上没有邮箱。写错了。
3.2. 转发
下面是一些<forward-path>中目的地址不正确的,但接收者知道正确的目的地址的例子。在这些例子中,下列应答之一应该允许发送方与获得正确地址。
转发的例子
S: RCPT TO:<Postel@USC-ISI.ARPA>
R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
或者
S: RCPT TO:<Paul@USC-ISIB.ARPA>
R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
3.3. 确认和扩展
SMTP提供了另外的确认用户名和扩展邮件列表的功能。这些功能由VREF和EXPN命令完成,它们都以字符串为参数。对于VREF命令,字符串参数指的是用户名,对此命令的响应要包括用户的命名和用户的邮箱。对于EXPN命令,字符串参数指的是邮件列表,对此命令的响应多于一个,它们要包括所有列表中用户的命名和他们的邮箱。
“用户名”是一个多余的项目,它是故意被加上的。如果主机采用VREF命令和EXPN命令,最后本地邮箱必须提供用户名使它被主机确认。如果主机选择由另外的字符串作为用户名,也是允许的。
在一些主机中,邮箱列表和一个邮箱的代名有一点不清楚,因为一般的数据结构可能包括两种类型的入口。如果要发出对邮件列表的确认,应该给出确定响应。在接收到这个消息后,主机将把邮件传送到列表上所有的地址上去,如果没有接收到确定响应,就会报告错误。例如,"550 That is a mail list, not a user name"。如果请求用于扩展一个用户名,可能通过返回包括一个名字的列表来形成确定响应,如果没有接收到确定响应,就会报告错误。(例如, "550 That is a user name, not a mailing list")。
在多个响应的情况下(通常是对于EXPN而言的),每个应答指定一个邮箱。在模糊请求的情况下,例如"VRFY Smith",这里两个Smith的响应必须是"553 User ambiguous"。
确认用户名的情况如下例所示:例3:
确认用户名
S: VRFY Smith
R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
或者
S: VRFY Smith
R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
或者
S: VRFY Jones
R: 550 String does not match anything.
或者
S: VRFY Jones
R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
或者
S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.
下例中显示了不可传送的邮件信息。此信息是对从HOSTW上的JOE发出的邮件经过在HOSTX需要经过HOSTZ到达HOSTY时出错的回应。我们看到的例子是在HOSTX和HOSTY之间发生的。作者: Kathy 时间: 2005-11-15 10:23 AM 标题: RFC821(2)
不可传送邮件信息的例子
S: MAIL FROM:<>
R: 250 ok
S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
R: 250 ok
S: DATA
R: 354 send the mail data, end with .
S: Date: 23 Oct 81 11:22:33
S: From: SMTP@HOSTY.ARPA
S: To: JOE@HOSTW.ARPA
S: Subject: Mail System Problem
S:
S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
S: HOSTZ.ARPA said this:
S: "550 No Such User"
S: .
R: 250 ok
3.7. 域
域是最近被引入ARPA Internet邮件系统的。使用域可以使地址空间从一个平面的普通字符串主机名变成全局地址的一个层次结构。主机由一个域名取代,起始主机是由一系列元串组成,它们由逗号按最特殊到一般的顺序排列。
例如,"USC-ISIF.ARPA","Fred.Cambridge.UK"和"PC7.LCS.MIT.ARPA"可能是主机-域标识符。
无论域名在SMTP中如何使用,只有正式的名称才可以被使用,不可以使用假名或昵称。
3.8. 改变角色
TURN命令可以用来改变在传输信道上通信的程序的角色。如果程序A现在是发送SMTP,它发送TURN命令并接到OK应答(250)后,它就变为接收SMTP了。同理,程序B也可以从接收SMTP变为发送SMTP。若要拒绝改变角色,接收方可以发送502作为应答。
注意:此命令是可选的。在使用TCP的传输信道时,一般不使用此命令。然而,当建立传输信道的代价比较大时,此命令很有用。例如,此命令可以支持一般公共交换电话系统作为传输信道。
4. SMTP说明
4.1. SMTP命令
4.1.1. 命令语法
SMTP命令定义了邮件传输或由用户定义的系统功能。它的命令是由<CRLF>结束的字符串。而在带有参数的情况下,命令本身由<SP>和参数分开,如果未带参数可以直接和<CRLF>连接。邮箱的语法格式必须和接收站点的格式一致。下面讨论SMTP命令和应答。
发送邮件操作涉及到不同的数据对象,它们由不同的参数相互连接。回复路径就是MAIL命令的参数,而转发路径则是RCPT命令的参数,邮件日期是DATA命令的参数。这些参数或者数据对象必须跟在命令后。这种模式也就要求有不同的缓冲区来存储这些对象,也就是说,有一个回复路径缓冲区,一个转发路径缓冲区,一个邮件内容缓冲区。特定的命令产生自己的缓冲区,或使一个或多个缓冲的内容被清除。
HELLO (HELO)
此命令用于向接收SMTP确认发送SMTP。参数域包括发送SMTP的主机名。接收SMTP通过连接确认命令来向发送SMTP确认接收SMTP。引命令和OK响应确认发送和接收SMTP进入了初始状态,也就是说,没有操作正在执行,所有状态表和缓冲区已经被子清除。
MAIL (MAIL)
此命令用于开始将邮件发送到一个多个邮箱中。参数域包括回复路径。返回路径中包括了可选的主机和发送者邮箱列表。当有主机列表时,它是一个回复路径源,它说明此邮箱是由在表中的主机一一传递发送(第一个主机是最后一个接收到此邮件的主机)过来的。此表也有作向发送者返回非传递信号的源路径。因为每个传递主机地址都被加在此表起始处,它就必须使用发送IPCE而不是接收IPCE(如果它们不是一个IPCE的话)清楚的名称。一些出错信息的回复路径可能就是空的。
此命令清除回复路径缓冲区,转发路径缓冲区和邮件内容缓冲区,并且将此命令的回复路径信息插入到回复路径缓冲区中。
RECIPIENT (RCPT)
此命令用于确定邮件内容的唯一接收者;多个接收者将由多个此命令指定。转发路径中包括一个可选的主机和一个必须的目的邮箱。当出现主机列表时,这就是一个源路径,它指明邮件必须向列表中的上一个主机发送。如果接收SMTP未实现邮件的传递发送,就会返回如未知本地用户(550)的信息给用户。
当邮件被传递发送时,传递主机必须将自己的名称由转发路径的开始处移至回复路径的结束处。当邮件最终到达目的地时,接收SMTP将以它的主机邮件格式自己的名称插入目标邮件中。例如,由传递主机A接收的带有如下参数的邮件时,
FROM:<USERX@HOSTY.ARPA>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
将会变成如下形式:
FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
此命令导致它的转发路径参数加入转发路径缓冲区中。
DATA (DATA)
接收者将跟在命令后的行作为邮件内容。此命令导致此命令后的邮件内容加入邮件内容缓冲区。邮件内容可以包括所有128个ASCII码字符。邮件内容由只包括一个句号的行结束,也就是如下的字符序列:"<CRLF>.<CRLF>",它指示了邮件的结束。
邮件内容的结束指示要求接收者现在就处理保存的邮件内容。此过程将回复路径缓冲区,转发路径缓冲区和邮件内容缓冲区的内容全部清空。如果操作成功,接收者必须返回OK应答;如果失败也必须返回失败应答。
当接收SMTP收到一条信息时,无论是用作转发还是此邮件已经到达目的地,它都必须在邮件内容的开始处加上时间戳这一行,这一行指示了接收到邮件主机和发出此邮件主机的标识,以及接收到邮件内容的时间和日期。转发的信件将有多行这样的时间戳。当接收SMTP作最后一站的传送时,它将返回路径信息行插入邮件中。此行包括了发送命令中的<reverse-path>的信息。在这里,最后一站的传送的意思是邮件将被送到目的用户手中,但在一些情况下,邮件可能需要更进一步的加工并由另外的邮件系统传送。
可能在返回路径中的邮箱与实际发送的邮件不一致,这个情况可能发生在需要传送一个特定的错误处理信箱而不是信件发送者那里。上面所述说明了,最后的邮件内容由一个返回路径行,和在其后的一个或多个时间戳行构成。这些行后面是邮件内容的头和体信息。
当处理后面的邮件数据指示部分成功时就需要特定的说明。这种情况可能发生在发送SMTP发现当邮件需要传送给多个用户时,只能够成功地向其中的一部分发送信息这种情况下。在这种情况下,必须对DATA命令发送OK应答,而接收SMTP组织并发送一个"不可传递邮件"信息到信息的发送者。在此信息中或者发送一个不成功接收者的列表,或者每次发送一个不成接收者,而发送多次。所有不可传递邮件信息由MAIL命令发送。
返回路径和接收时间戳例子
Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From: JOE@ABC.ARPA
Subject: Improved Mailing System Installed
To: SAM@JKL.ARPA
This is to inform you that ...
SEND (SEND)
此命令用于开始一个发送命令,将邮件发送到一个或多个终端上。参数域包括了一个回复路径,此命令如果成功就将邮件发送到终端上了。
回复路径包括一个可选的主机列表和发送者邮箱。当出现主机列表时,表示这是一个传送路径,邮件就是经过这个路径上的每个主机发送到这里的(列表上第一个主机是最后经手的主机)。此表用于返回非传递信号到发送者。因为每个传递主机地址都被加在此表起始处,它就必须使用发送IPCE而不是接收IPCE(如果它们不是一个IPCE的话)清楚的名称。一些出错信息的回复路径可能就是空的。
此命令清除回复路径缓冲区,转发路径缓冲区和邮件内容缓冲区,并且将此命令的回复路径信息插入到回复路径缓冲区中。
SEND OR MAIL (SOML)
此命令用于开始一个邮件操作将邮件内容传送到一个或多个终端上,或者传送到邮箱中。对于每个接收者,如果接收者终端打开,邮件内容将被传送到接收者的终端上,否则就送到接收者的邮箱中。参数域包括回复路径,如果成功地将信息送到终端或邮箱中此命令成功。
回复路径包括一个可选的主机列表和发送者邮箱。当出现主机列表时,表示这是一个传送路径,邮件就是经过这个路径上的每个主机发送到这里的(列表上第一个主机是最后经手的主机)。此表用于返回非传递信号到发送者。因为每个传递主机地址都被加在此表起始处,它就必须使用发送IPCE而不是接收IPCE(如果它们不是一个IPCE的话)清楚的名称。一些出错信息的回复路径可能就是空的。
此命令清除回复路径缓冲区,转发路径缓冲区和邮件内容缓冲区,并且将此命令的回复路径信息插入到回复路径缓冲区中。
SEND AND MAIL (SAML)
此命令用于开始一个邮件操作将邮件内容传送到一个或多个终端上,并传送到邮箱中。如果接收者终端打开,邮件内容将被传送到接收者的终端上和接收者的邮箱中。参数域包括回复路径,如果成功地将信息送到邮箱中此命令成功。
回复路径包括一个可选的主机列表和发送者邮箱。当出现主机列表时,表示这是一个传送路径,邮件就是经过这个路径上的每个主机发送到这里的(列表上第一个主机是最后经手的主机)。此表用于返回非传递信号到发送者。因为每个传递主机地址都被加在此表起始处,它就必须使用发送IPCE而不是接收IPCE(如果它们不是一个IPCE的话)清楚的名称。一些出错信息的回复路径可能就是空的。
此命令清除回复路径缓冲区,转发路径缓冲区和邮件内容缓冲区,并且将此命令的回复路径信息插入到回复路径缓冲区中。
ASCII, "USA Code for Information Interchange", United States of
America Standards Institute, X3.4, 1968. Also in: Feinler, E.
and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
the Defense Communications Agency by SRI International, Menlo
Park, California, Revised January 1978.
[2] RFC 822
Crocker, D., "Standard for the Format of ARPA Internet Text
Messages," RFC 822, Department of Electrical Engineering,
University of Delaware, August 1982.
[3] TCP
Postel, J., ed., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, USC/Information Sciences
Institute, NTIS AD Number A111091, September 1981. Also in:
Feinler, E. and J. Postel, eds., "Internet Protocol Transition
Workbook", SRI International, Menlo Park, California, March 1982.
[4] NCP
McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.
[5] Initial Connection Protocol
Postel, J., "Official Initial Connection Protocol", NIC 7101,
11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.
[6] NITS
PSS/SG3, "A Network Independent Transport Service", Study Group 3,
The Post Office PSS Users Group, February 1980. Available from
the DCPU, National Physical Laboratory, Teddington, UK.
August 1982 RFC 821
Simple Mail Transfer Protocol
[7] X.25
CCITT, "Recommendation X.25 - Interface Between Data Terminal
Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
Terminals Operating in the Packet Mode on Public Data Networks,"
CCITT Orange Book, Vol. VIII.2, International Telephone and
Telegraph Consultative Committee, Geneva, 1976.