📄 rfc788.txt
字号:
<d> ::= any one of the ten digits 0 through 9 <s> ::= any one of <specials> <specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@', '"', and the control characters (ASCII codes 0 through 37 octal inclusive and 177 octal) Note that the backslash, '\', is a quote character, which is used to indicate that the next character is to be used literally (instead of its normal interpretation). For example, "Joe\,Smith" could be used to indicate a single nine character user field with comma being the fourth character of the field.Postel [Page 25] November 1981 RFC 788Simple Mail Transfer Protocol Hosts are generally known by names which are translated to addresses in each host. Sometimes a host is not known to the translation function and communication is blocked. To bypass this barrier two numeric forms are also allowed for host "names". One form is a decimal integer prefixed by a pound sign, "#", which indicates the number is the address of the host. Another form is four small decimal integers separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet Address in four 8-bit fields. The time stamp line and the return path line are formally defined as follows: <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> <time-stamp-line> ::= "Mail-From:" <SP> <stamp> <CRLF> <stamp> ::= [<ptcl>] <from-host> <this-host> <daytime> <ptcl> ::= <protocol> <SP> "host" <SP> <from-host> ::= <host> <SP> <this-host> ::= "received by" <SP> <host> <SP> <protocol> ::= "TCP" | "NCP" | "NITS" | "X25" | "INTERNET" | "ARPANET" Note: INTERNET = TCP, ARPANET = NCP, and if the <ptcl> is not present INTERNET is assumed. <daytime> ::= "at" <SP> <date> <SP> <time> <date> ::= <dd> "-" <mon> "-" <yy> <time> ::= <hh> ":" <mm> ":" <ss> "-" <zone> <dd> ::= the one or two decimal integer day of the month in the range 1 to 31. <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" <yy> ::= the two decimal integer year of the century in the range 01 to 99.[Page 26] Postel RFC 788 November 1981 Simple Mail Transfer Protocol <hh> ::= the two decimal integer hour of the day in the range 00 to 24. <mm> ::= the two decimal integer minute of the hour in the range 00 to 59. <ss> ::= the two decimal integer second of the minute in the range 00 to 59. <zone> ::= a time zone designator (as in [2]) or "UT" for Universal Time (the default). Return Path Example: Return-Path: <@CHARLIE,@BAKER,JOE@ABLE> Mail From Example: Mail-From: ABC received by XYZ at 22-OCT-81 09:23:59-PDT Postel [Page 27] November 1981 RFC 788Simple Mail Transfer Protocol 4.2. SMTP REPLIES Replies to SMTP commands are devised to ensure the synchronization of requests and actions in the process of mail transfer, and to guarantee that the sender-SMTP always knows the state of the receiver-SMTP. Every command must generate exactly one reply. The details of the command-reply sequence are made explicit in Section 5.3 on Sequencing and Section 5.4 State Diagrams. An SMTP reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The number is intended for use by automata to determine what state to enter next; the text is meant for the human user. It is intended that the three digits contain enough encoded information that the sender-SMTP need not examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be receiver-dependent, so there are likely to be varying texts for each reply code. A discussion of the theory of reply codes is given in the Appendix E. Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in Appendix E). Only the EXPN and HELP command are expected to result in multiline replies in normal circumstances, however multiline replies are allowed for any command.[Page 28] Postel RFC 788 November 1981 Simple Mail Transfer Protocol 4.2.1. REPLY CODES BY FUNCTION GROUPS 500 Syntax error, command unrecognized [This may include errors such as command line too long] 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 211 System status, or system help reply 214 Help message [Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user] 220 <host> Service ready 221 <host> Service closing transmission channel 421 <host> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down] 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 451 Requested action aborted: error in processing 551 User not local; please try <forward-path> 452 Requested action not taken: insufficient system storage 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 354 Start mail input; end with <CRLF>.<CRLF> 554 Transaction failed Postel [Page 29] November 1981 RFC 788Simple Mail Transfer Protocol 4.2.2. NUMERIC ORDER LIST OF REPLY CODES 211 System status, or system help reply 214 Help message [Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user] 220 <host> Service ready 221 <host> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 354 Start mail input; end with <CRLF>.<CRLF> 421 <host> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down] 450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage 500 Syntax error, command unrecognized [This may include errors such as command line too long] 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 551 User not local; please try <forward-path> 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction failed [Page 30] Postel RFC 788 November 1981 Simple Mail Transfer Protocol 4.3. SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. The sender must wait for this response before sending further commands. One important reply is the connection greeting. Normally, a receiver will send a 220 "Awaiting input" reply when the connection is completed. The sender should wait for this greeting message before sending any commands. Note: all the greeting type replies have the official name of the server host as the first word following the reply code. For example, 220 <SP> USC-ISIF <SP> Service ready <CRLF> The table below lists alternative success and failure replies for each command. These must be strictly adhered to; a receiver may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. COMMAND-REPLY SEQUENCES Each command is listed with its possible replies. The prefixes used before the possible replies are "P" for preliminary (not used in SMTP), "I" for intermediate, "S" for success, "F" for failure, and "E" for error. The 421 reply (service not available, closing transmission channel) may be given to any command if the SMTP-receiver knows it must shut down. This listing forms the basis for the State Diagrams in Section 4.4. CONNECTION ESTABLISHMENT S: 220 F: 421 HELO S: 250 E: 500, 501, 504, 421 MAIL S: 250 F: 552, 451, 452 E: 500, 501, 421Postel [Page 31] November 1981 RFC 788Simple Mail Transfer Protocol RCPT S: 250, 251 F: 550, 551, 552, 553, 450, 451, 452 E: 500, 501, 421 DATA I: 354 -> data -> S: 250 F: 552, 554, 451, 452 F: 451, 554 E:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -