protocols:hmtp
Differences
This shows you the differences between two versions of the page.
| protocols:hmtp [2018/08/14 16:24] – created root | protocols:hmtp [2018/08/14 16:31] (current) – [HMTP COMMANDS] root | ||
|---|---|---|---|
| Line 88: | Line 88: | ||
| A mail transaction involves several data objects which are communicated as arguments to | A mail transaction involves several data objects which are communicated as arguments to | ||
| different commands. The reverse-path is the argument of the MAIL command, the forwardpath | different commands. The reverse-path is the argument of the MAIL command, the forwardpath | ||
| - | is the argument of the RCPT command, and the mail data is the argument of theDATA | + | is the argument of the RCPT command, and the mail data is the argument of the DATA |
| command. These arguments or data objects must be transmitted and held pending the | command. These arguments or data objects must be transmitted and held pending the | ||
| confirmation communicated by the end of mail data indication which finalizes the | confirmation communicated by the end of mail data indication which finalizes the | ||
| Line 96: | Line 96: | ||
| more buffers to be cleared. | more buffers to be cleared. | ||
| - | HELLO (HELO) | + | |
| This command is used to identify the HMTP client to the HMTP server. The argument field | This command is used to identify the HMTP client to the HMTP server. The argument field | ||
| Line 108: | Line 108: | ||
| buffers are cleared. | buffers are cleared. | ||
| - | MAIL MULTIPLE | + | |
| This command is used to advise the server that a sequence of more than one MAIL | This command is used to advise the server that a sequence of more than one MAIL | ||
| transaction will follow. The default, if this command is not sent, is a single MAIL | transaction will follow. The default, if this command is not sent, is a single MAIL | ||
| transaction. | transaction. | ||
| - | MAIL (MAIL) | + | |
| + | | ||
| This command is used to initiate a mail transaction in which the mail data is delivered to one | This command is used to initiate a mail transaction in which the mail data is delivered to one | ||
| or more mailboxes. The argument field contains a reverse-path. | or more mailboxes. The argument field contains a reverse-path. | ||
| + | |||
| The reverse-path consists of an optional list of hosts and the sender mailbox. When the list | The reverse-path consists of an optional list of hosts and the sender mailbox. When the list | ||
| of hosts is present is a " | of hosts is present is a " | ||
| Line 122: | Line 125: | ||
| beginning of the list, it must use its name as known in the IPCE to which it is relaying the | beginning of the list, it must use its name as known in the IPCE to which it is relaying the | ||
| mail rather than the IPCE from which the mail came (if they are different). In some types of | mail rather than the IPCE from which the mail came (if they are different). In some types of | ||
| + | error reporting messages (for example, undeliverable mail notifications) the reverse-path may | ||
| + | be null (see Example 7). | ||
| + | |||
| + | This command clears the reverse-path buffer, the forward-path buffer, and the mail data | ||
| + | buffer; and inserts the reverse-path information from this command into the reverse-path | ||
| + | buffer. | ||
| + | |||
| + | RECIPIENT (RCPT) | ||
| + | |||
| + | This command is used to identify an individual recipient of the mail data; multiple recipients | ||
| + | are specified by multiple use of this command. | ||
| + | |||
| + | The forward-path consists of a required destination mailbox. Source routing shall not be | ||
| + | used. | ||
| + | |||
| + | When mail is relayed, the relay host must put itself at the beginning of the reverse-path. | ||
| + | When mail reaches its ultimate destination, | ||
| + | mailbox in accordance with its host mail conventions. | ||
| + | |||
| + | DATA (DATA) | ||
| + | |||
| + | The server treats the lines following the command as mail data from the sender. This | ||
| + | command causes the mail data from this command to be appended to the mail data buffer. | ||
| + | The mail data may contain any of the 128 ASCII character codes. | ||
| + | |||
| + | The mail data is terminated by a line containing only a period, that is the character sequence | ||
| + | "< | ||
| + | indication. | ||
| + | |||
| + | The end of mail data indication requires that the server must now process the stored mail | ||
| + | transaction information. This processing consumes the information in the reverse-path buffer, | ||
| + | the forward-path buffer, and the mail data buffer, and on the completion of this command | ||
| + | these buffers are cleared. If the processing is successful the server must send an OK reply. If | ||
| + | the processing fails completely the server must send a failure reply. | ||
| + | |||
| + | When the HMTP server accepts a message either for relaying or for final delivery it inserts at | ||
| + | the beginning of the mail data a time stamp line. The time stamp line indicates the identity of | ||
| + | the host that sent the message, and the identity of the host that received the message (and is | ||
| + | inserting this time stamp), and the date and time the message was received. Relayed | ||
| + | messages will have multiple time stamp lines. | ||
| + | |||
| + | When the HMTP server makes the "final delivery" | ||
| + | the mail data a return path line. The return path line preserves the information in the | ||
| + | < | ||
| + | HMTP world. Normally, this would mean it has been delivered to the destination user, but in | ||
| + | some cases it may be further processed and transmitted by another mail system. | ||
| + | |||
| + | It is possible for the mailbox in the return path be different from the actual sender' | ||
| + | for example, if error responses are to be delivered a special error handling mailbox rather | ||
| + | than the message senders. | ||
| + | |||
| + | The preceding two paragraphs imply that the final mail data will begin with a return path | ||
| + | line, followed by one or more time stamp lines. These lines will be followed by the mail data | ||
| + | header and body [2]. See Example 8. | ||
| + | |||
| + | Special mention is needed of the response and further action required when the processing | ||
| + | following the end of mail data indication is partially successful. This could arise if after | ||
| + | accepting several recipients and the mail data, the HMTP server finds that the mail data can | ||
| + | be successfully delivered to some of the recipients, but it cannot be to others (for example, | ||
| + | due to mailbox space allocation problems). In such a situation, the response to the DATA | ||
| + | command must be an OK reply. But, the HMTP server must compose and send an | ||
| + | " | ||
| + | notification which lists all of the recipients that failed to get the message, or separate | ||
| + | notification messages must be sent for each failed recipient (see Example 7). All | ||
| + | undeliverable mail notification messages are sent using the MAIL command (even if they | ||
| + | result from processing a SEND, SOML, or SAML command). | ||
| + | |||
| + | RESET (RSET) | ||
| + | | ||
| + | This command specifies that the current mail transaction is to be aborted. Any stored sender, | ||
| + | recipients, and mail data must be discarded, and all buffers and state tables cleared. The | ||
| + | server must send an OK reply. | ||
| + | |||
| + | QUIT (QUIT) | ||
| + | | ||
| + | This command specifies that the server must send an OK reply, and then close the | ||
| + | transmission channel. | ||
| + | |||
| + | The server should not close the transmission channel until it receives and replies to a QUIT | ||
| + | command (even if there was an error). The client should not close the transmission channel | ||
| + | until it send a QUIT command and receives the reply (even if there was an error response to a | ||
| + | previous command). If the connection is closed prematurely the server should act as if a | ||
| + | RSET command had been received (canceling any pending transaction, | ||
| + | previously completed transaction), | ||
| + | progress had received a temporary error (4xx). | ||
| + | |||
| + | === COMMAND SYNTAX === | ||
| + | |||
| + | The commands consist of a command code followed by an argument field. Command codes | ||
| + | are four alphabetic characters. Upper and lower case alphabetic characters are to be treated | ||
| + | identically. Thus, any of the following may represent the mail command: | ||
| + | |||
| + | MAIL Mail mail MaIl mAIl | ||
| + | | ||
| + | This also applies to any symbols representing parameter values, such as " | ||
| + | forward-path. Command codes and the argument fields are separated by one or more spaces. | ||
| + | |||
| + | However, within the reverse-path and destination arguments case is important. In particular, | ||
| + | in some hosts the user " | ||
| + | |||
| + | The argument field consists of a variable length character string ending with the character | ||
| + | sequence < | ||
| + | |||
| + | Square brackets denote an optional argument field. If the option is not taken, the appropriate | ||
| + | default is implied. | ||
| + | |||
| + | The following are the HMTP commands: | ||
| + | |||
| + | HELO HMTP <SP> < | ||
| + | | ||
| + | MAIL MULTIPLE | ||
| + | | ||
| + | MAIL <SP> FROM:< | ||
| + | | ||
| + | RCPT <SP> TO:< | ||
| + | | ||
| + | DATA < | ||
| + | | ||
| + | RSET < | ||
| + | | ||
| + | QUIT < | ||
| + | |||
| + | === SMTP REPLIES === | ||
| + | |||
| + | Replies to HMTP commands are devised to ensure the synchronization of requests and | ||
| + | actions in the process of mail transfer, and to guarantee that the HMTP client always knows | ||
| + | the state of the HMTP server. Every command must generate exactly one reply. | ||
| + | |||
| + | An HMTP 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 HMTP client 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 server-dependent and context dependent, so there are likely to be varying texts for each | ||
| + | reply code. A discussion of the theory of reply codes can be found in Appendix E to RFC | ||
| + | 822. Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of | ||
| + | text, and < | ||
| + | |||
| + | == 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 | ||
| + | | ||
| + | 220 < | ||
| + | 221 < | ||
| + | 421 < | ||
| + | | ||
| + | 250 Requested mail action okay, completed | ||
| + | 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 | ||
| + | 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 < | ||
| + | 554 Transaction failed | ||
| + | |||
| + | ==== TRANSPARENCY ==== | ||
| + | |||
| + | Without some provision for data transparency the character sequence "< | ||
| + | ends the mail text and cannot be sent by the user. In general, users are not aware of such | ||
| + | " | ||
| + | following procedures are used. | ||
| + | |||
| + | 1. Before sending a line of mail text the sender-HMTP checks the first character of the line. | ||
| + | If it is a period, one additional period is inserted at the beginning of the line. | ||
| + | |||
| + | 2. When a line of mail text is received by the receiver-HMTP it checks the line. If the line is | ||
| + | composed of a single period it is the end of mail. If the first character is a period and there | ||
| + | are other characters on the line, the first character is deleted. | ||
| + | |||
| + | The mail data may contain any of the 128 ASCII characters. All characters are to be | ||
| + | delivered to the recipient' | ||
| + | If the transmission channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes | ||
| + | are transmitted right justified in the octets with the high order bits cleared to zero. | ||
| + | In some systems it may be necessary to transform the data as it is received and stored. This | ||
| + | may be necessary for hosts that use a different character set than ASCII as their local | ||
| + | character set, or that store data in records rather than strings. If such transforms are | ||
| + | necessary, they must be reversible -- especially if such transforms are applied to mail being | ||
| + | relayed. | ||
protocols/hmtp.1534256676.txt.gz · Last modified: 2018/08/14 16:24 by root