User Tools

Site Tools


protocols:hmtp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

protocols:hmtp [2018/08/14 16:24] – created rootprotocols: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)+  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+  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)+ 
 +  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 "reverse" source route and indicates that the mail was relayed through of hosts is present is a "reverse" source route and indicates that the mail was relayed through
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, the HMTP server inserts it into the 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
 +"<CRLF>.<CRLF>" (see Section 4.5.2 on Transparency). This is the end of mail data
 +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" of a message it inserts at the beginning of
 +the mail data a return path line. The return path line preserves the information in the
 +<reverse-path> from the MAIL command. Here, final delivery means the message leaves 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's mailbox,
 +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
 +"undeliverable mail" notification message to the originator of the message. Either a single
 +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, but not undoing any
 +previously completed transaction), the client should act as if the command or transaction in
 +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 "TO" or "to" for the
 +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 "smith" is different from the user "Smith".
 +
 +The argument field consists of a variable length character string ending with the character
 +sequence <CRLF>. The receiver is to take no action until this sequence is received.
 +
 +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> <domain> <CRLF>
 +  
 +  MAIL MULTIPLE
 +  
 +  MAIL <SP> FROM:<reverse-path> <CRLF>
 +  
 +  RCPT <SP> TO:<destination> <CRLF>
 +  
 +  DATA <CRLF>
 +  
 +  RSET <CRLF>
 +  
 +  QUIT <CRLF>
 +
 +=== 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 <CRLF>. In general, replies in HMTP will be multiline replies.
 +
 +== 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 <domain> HMTP Service ready
 +  221 <domain> Service closing transmission channel
 +  421 <domain> 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
 +  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 <CRLF>.<CRLF>
 +  554 Transaction failed
 +
 +==== TRANSPARENCY ====
 +
 +Without some provision for data transparency the character sequence "<CRLF>.<CRLF>"
 +ends the mail text and cannot be sent by the user. In general, users are not aware of such
 +"forbidden" sequences. To allow all user composed text to be transmitted transparently the
 +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's mailbox including format effectors and other control characters.
 +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

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki