diff options
| author | Shulhan <ms@kilabit.info> | 2019-01-29 22:04:42 +0700 |
|---|---|---|
| committer | Shulhan <ms@kilabit.info> | 2019-01-29 22:04:42 +0700 |
| commit | 312df97e0efea93fe00ab1a16160822525de7330 (patch) | |
| tree | 313f824892911690cbca95b45bf8729a95efbb50 | |
| parent | 967188b4e5de6baa73bd2d9f134c6fd21ff28e53 (diff) | |
| download | pakakeh.go-312df97e0efea93fe00ab1a16160822525de7330.tar.xz | |
all: include generated HTMLs
The generated README on github page have some links that point to
generated HTML files but the files is not found (404).
Lets see if by including into repository, the links may works.
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | CHANGELOG.html | 58 | ||||
| -rw-r--r-- | doc/ESMTP_AUTH.html | 380 | ||||
| -rw-r--r-- | doc/ESMTP_DSN.html | 944 | ||||
| -rw-r--r-- | doc/ESMTP_TLS.html | 195 | ||||
| -rw-r--r-- | doc/IMF.html | 666 | ||||
| -rw-r--r-- | doc/SASL.html | 419 | ||||
| -rw-r--r-- | doc/SASL_PLAIN.html | 105 | ||||
| -rw-r--r-- | doc/SMTP.html | 1022 |
9 files changed, 3789 insertions, 1 deletions
@@ -1,4 +1,3 @@ -*.html *.prof *.save *.test diff --git a/CHANGELOG.html b/CHANGELOG.html new file mode 100644 index 00000000..16408140 --- /dev/null +++ b/CHANGELOG.html @@ -0,0 +1,58 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<title>CHANGELOG</title> +<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"> +<link rel="stylesheet" href="./asciidoctor.css"> +</head> +<body class="article"> +<div id="header"> +<h1>CHANGELOG</h1> +<div id="toc" class="toc"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_share_v0_1_0">share v0.1.0</a></li> +</ul> +</div> +</div> +<div id="content"> +<div class="sect1"> +<h2 id="_share_v0_1_0">share v0.1.0</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The first release of <code>share</code> package contains one command line interface (CLI) +and several libraries.</p> +</div> +<div class="paragraph"> +<p>The CLI is <code>gofmtcomment</code> to convert comment from <code>/**/</code> to <code>//</code>.</p> +</div> +<div class="paragraph"> +<p>The libraries are <code>bytes</code>, <code>contact</code>, <code>dns</code>, <code>dsv</code>, <code>ini</code>, <code>io</code>, <code>memfs</code>, +<code>mining</code>, <code>net</code>, <code>numbers</code>, <code>runes</code>, <code>strings</code>, <code>tabula</code>, <code>test</code>, <code>text</code>, +<code>time</code>, and <code>websocket</code>.</p> +</div> +<div class="paragraph"> +<p>Documentation for each package can be viewed at,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>https://godoc.org/github.com/shuLhan/share</pre> +</div> +</div> +<div class="paragraph"> +<p>I hope it will be stay alive!</p> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2018-12-08 16:24:48 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/ESMTP_AUTH.html b/doc/ESMTP_AUTH.html new file mode 100644 index 00000000..d4694192 --- /dev/null +++ b/doc/ESMTP_AUTH.html @@ -0,0 +1,380 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>SMTP Service Extension for Authentication</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article toc2 toc-left"> +<div id="header"> +<h1>SMTP Service Extension for Authentication</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc2"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_ehlo_extension">1. EHLO Extension</a> +<ul class="sectlevel2"> +<li><a href="#_common_response">1.1. Common Response</a></li> +</ul> +</li> +<li><a href="#_auth_command">2. AUTH Command</a> +<ul class="sectlevel2"> +<li><a href="#_direct_handshake">2.1. Direct Handshake</a></li> +<li><a href="#_indirect_handshake">2.2. Indirect Handshake</a></li> +<li><a href="#_response">2.3. Response</a> +<ul class="sectlevel3"> +<li><a href="#_success_response">2.3.1. Success Response</a></li> +<li><a href="#_error_response">2.3.2. Error Response</a></li> +</ul> +</li> +<li><a href="#_canceling_auth">2.4. Canceling AUTH</a></li> +</ul> +</li> +<li><a href="#_auth_parameter_for_mail_from_command">3. AUTH Parameter for MAIL FROM Command</a></li> +<li><a href="#_additional_requirements_on_servers">4. Additional Requirements on Servers</a></li> +<li><a href="#_security_considerations">5. Security Considerations</a></li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This document provide note and summary of RFC 4954, SMTP Service Extension for +Authentication.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_ehlo_extension">1. EHLO Extension</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The EHLO keyword associated with this extension is "AUTH".</p> +</div> +<div class="paragraph"> +<p>This extension provide one command "AUTH".</p> +</div> +<div class="paragraph"> +<p>This extension add one optional parameter to MAIL FROM command: "AUTH"</p> +</div> +<div class="paragraph"> +<p>This extension extends the maximum line length of the MAIL FROM command to 500 +characters.</p> +</div> +<div class="sect2"> +<h3 id="_common_response">1.1. Common Response</h3> +<div class="ulist"> +<ul> +<li> +<p>530 5.7.0 Authentication required</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response SHOULD be returned by command MAIL, RCPT, DATA, VRFY, EXPN, and +HELP, when server policy requires authentication in order to perform the +requested action.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_auth_command">2. AUTH Command</h2> +<div class="sectionbody"> +<div class="literalblock"> +<div class="content"> +<pre>"AUTH" mechanism ( initial-response / "=" ) CRLF + +mechanism = A string identifying a [SASL] authentication mechanism. + +initial-response = base64</pre> +</div> +</div> +<div class="paragraph"> +<p>Initial-response MUST be encoded in base64 and may or may not empty, depends +on mechanism.</p> +</div> +<div class="paragraph"> +<p>Initial-response "=" is response with zero length, to indicate that the +response is present.</p> +</div> +<div class="paragraph"> +<p>After a successful AUTH command completes, a server MUST reject any further +AUTH commands with a 503 reply.</p> +</div> +<div class="paragraph"> +<p>An AUTH command issued during a mail transaction MUST be rejected with a 503 +reply.</p> +</div> +<div class="paragraph"> +<p>There are two modes of AUTH handshakes: directly with initial-response and +non-directly with initial-response in the second response.</p> +</div> +<div class="sect2"> +<h3 id="_direct_handshake">2.1. Direct Handshake</h3> +<div class="paragraph"> +<p>In this mode, the $INITIAL_RESPONSE contains non empty text other than "=". +This mode SHOULD be used when length of command line less than maximum (512 +octets), to minimize round-trip to server.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>; TLS handshake +; EHLO handshake +C: AUTH $MECHANISM $INITIAL_RESPONSE +S: 235 2.7.0 Authentication successful</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_indirect_handshake">2.2. Indirect Handshake</h3> +<div class="paragraph"> +<p>In this mode, the $INITIAL_RESPONSE is empty, which cost client additional +step. +This mode MUST be used when AUTH line is exceeding maximum command line (512 +octets, see RFC 5321, section 4.5.3).</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>; TLS handshake +; EHLO handshake +C: AUTH $MECHANISM +S: "334" SP [ $SERVER_CHALLENGE ] CRLF +C: $INITIAL_RESPONSE +S: 235 2.7.0 Authentication successful</pre> +</div> +</div> +<div class="paragraph"> +<p>$SERVER_CHALLENGE is encoded in base64 and may or may not present depends on +$MECHANISM.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_response">2.3. Response</h3> +<div class="sect3"> +<h4 id="_success_response">2.3.1. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>"235" SP "2.7.0 Authentication successful" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>The client SHOULD send an EHLO command as the first command after a successful +SASL negotiation that results in the enabling of a security layer.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_error_response">2.3.2. Error Response</h4> +<div class="ulist"> +<ul> +<li> +<p>432 4.7.12 A password transition is needed</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that the user needs to transition to the selected +authentication mechanism. +This is typically done by authenticating once using the [PLAIN] authentication +mechanism. +The selected mechanism SHOULD then work for authentications in subsequent +sessions.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>454 4.7.0 Temporary authentication failure</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that the authentication failed due to a temporary +server failure. +The client SHOULD NOT prompt the user for another password in this case, and +should instead notify the user of server failure.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>500 5.5.6 Authentication Exchange line is too long</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that the authentication failed due to the client +sending a [BASE64] response that is longer than the maximum buffer size +available for the currently selected SASL mechanism.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>501 Syntax error in parameters or arguments</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that client canceling authentication or server failed +to decode base64 from handshake.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>504 5.5.4 Command parameter not implemented</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>If the requested authentication mechanism is invalid (e.g., is not supported +or requires an encryption layer).</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>534 5.7.9 Authentication mechanism is too weak</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that the selected authentication mechanism is weaker +than server policy permits for that user. +The client SHOULD retry with a new authentication mechanism.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>535 5.7.8 Authentication credentials invalid</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>This response indicates that the authentication failed due to invalid or +insufficient authentication credentials. +The client SHOULD ask the user to supply new credentials (such as by +presenting a password dialog box).</p> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_canceling_auth">2.4. Canceling AUTH</h3> +<div class="paragraph"> +<p>Client can cancel authentication, for example when client can’t decode base64 +from server, by sending,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"*" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>and server MUST reject the AUTH by response with 501 status code.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_auth_parameter_for_mail_from_command">3. AUTH Parameter for MAIL FROM Command</h2> +<div class="sectionbody"> +<div class="literalblock"> +<div class="content"> +<pre>"AUTH=" (mailbox / "<>")</pre> +</div> +</div> +<div class="paragraph"> +<p>If the server trusts the authenticated identity of the client to assert that +the message was originally submitted by the supplied <mailbox>, then the +server SHOULD supply the same <mailbox> in an AUTH parameter when relaying the +message to any other server which supports the AUTH extension. +For this reason, servers that advertise support for this extension MUST +support the AUTH parameter to the MAIL FROM command even when the client has +not authenticated itself to the server.</p> +</div> +<div class="paragraph"> +<p>A 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 authenticated identity that resulted from the AUTH command.</p> +</div> +<div class="paragraph"> +<p>If the AUTH parameter is not supplied and the client has authenticated, and +the server believes the message is an original submission, +the server MAY generate a <mailbox> from the user’s authenticated identity for +use in an AUTH parameter when relaying the message to any server which +supports the AUTH extension. +The generated <mailbox> is implementation specific, but it MUST conform to the +syntax of [SMTP]. +If the implementation cannot generate a valid <mailbox>, it MUST transmit +AUTH=<> when relaying this message.</p> +</div> +<div class="paragraph"> +<p>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 any supplied AUTH parameter to a +log file.</p> +</div> +<div class="paragraph"> +<p>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.</p> +</div> +<div class="paragraph"> +<p>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.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_additional_requirements_on_servers">4. Additional Requirements on Servers</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Upon successful authentication, a server SHOULD use the "ESMTPA" or the +"ESMTPSA" [SMTP-TT] (when appropriate) keyword in the "with" clause of the +Received header field.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_security_considerations">5. Security Considerations</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Clients and servers MUST discard any knowledge obtained prior to the start of +the SASL negotiation upon the establishment of a security layer.</p> +</div> +<div class="paragraph"> +<p>Servers MAY implement a policy whereby the connection is dropped after a +number of failed authentication attempts. +If they do so, they SHOULD NOT drop the connection until at least 3 attempts +to authenticate have failed.</p> +</div> +<div class="paragraph"> +<p>The implementation MUST support at least one configuration where these SASL +mechanisms are not advertised or used without the presence of an external +security layer such as [TLS].</p> +</div> +<div class="paragraph"> +<p>If an SMTP client is willing to use SASL PLAIN over TLS to authenticate to the +SMTP server, the client verifies the server certificate according to the rules +of [X509]. +If the server has not provided any certificate, or if the certificate +verification fails, the client MUST NOT attempt to authenticate using the SASL +PLAIN mechanism.</p> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2019-01-14 16:25:48 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/ESMTP_DSN.html b/doc/ESMTP_DSN.html new file mode 100644 index 00000000..0e6b6828 --- /dev/null +++ b/doc/ESMTP_DSN.html @@ -0,0 +1,944 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>Delivery Status Notification (DSN)</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article toc2 toc-left"> +<div id="header"> +<h1>Delivery Status Notification (DSN)</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc2"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#SMTP-extension-DSN">1. Extension for DSN (RFC 3461)</a> +<ul class="sectlevel2"> +<li><a href="#_relaying_to_other_confirming_smtp_server">1.1. Relaying to other confirming SMTP server</a></li> +<li><a href="#_relaying_to_non_conforming_smtp_server">1.2. Relaying to non-conforming SMTP server</a></li> +<li><a href="#_local_delivery">1.3. Local Delivery</a></li> +<li><a href="#_delays_in_delivery">1.4. Delays in delivery</a></li> +<li><a href="#_failure_on_delivery">1.5. Failure on delivery</a></li> +<li><a href="#_mailing_list">1.6. Mailing List</a></li> +<li><a href="#_mail_ret_parameter">1.7. MAIL RET Parameter</a></li> +<li><a href="#_mail_envid_parameter">1.8. MAIL ENVID Parameter</a></li> +<li><a href="#_rcpt_notify_parameter">1.9. RCPT NOTIFY Parameter</a></li> +<li><a href="#_rcpt_orcpt_parameter">1.10. RCPT ORCPT Parameter</a></li> +<li><a href="#_format_of_delivery_notifications">1.11. Format of delivery notifications</a></li> +</ul> +</li> +<li><a href="#_multipart_report_content_type_rfc_3462">2. Multipart-Report Content Type (RFC 3462)</a> +<ul class="sectlevel2"> +<li><a href="#_the_textrfc822_headers_content_type">2.1. The text/rfc822-headers content-type</a></li> +</ul> +</li> +<li><a href="#status-codes">3. Enhanced Mail System Status Codes (RFC 3463)</a> +<ul class="sectlevel2"> +<li><a href="#_class">3.1. Class</a></li> +<li><a href="#_subject">3.2. Subject</a></li> +</ul> +</li> +<li><a href="#_message_format_for_dsn_rfc_3464">4. Message Format for DSN (RFC 3464)</a> +<ul class="sectlevel2"> +<li><a href="#_human_readable_explanation_of_the_dsn">4.1. Human readable explanation of the DSN</a></li> +<li><a href="#_machine_readable_explanation_of_dsn">4.2. Machine readable explanation of DSN</a> +<ul class="sectlevel3"> +<li><a href="#_format_for_message_fields">4.2.1. Format for message-fields</a></li> +<li><a href="#_format_for_recipient_fields">4.2.2. Format for recipient-fields</a> +<ul class="sectlevel4"> +<li><a href="#_original_recipient_and_final_recipient">Original-Recipient and Final-Recipient</a></li> +<li><a href="#_action">Action</a></li> +<li><a href="#_status">Status</a></li> +<li><a href="#_remote_mta">Remote-MTA</a></li> +<li><a href="#_diagnostic_code">Diagnostic-Code</a></li> +<li><a href="#_last_attempt_date">Last-Attempt-Date</a></li> +<li><a href="#_final_log_id">Final-Log-ID</a></li> +<li><a href="#_will_retry_until">Will-Retry-Until</a></li> +</ul> +</li> +</ul> +</li> +<li><a href="#_original_message">4.3. Original message</a></li> +</ul> +</li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>The DSN specifications contains four document set describing the delivery +status report service: Simple Mail Transfer Protocol (SMTP) extensions +to request delivery status reports +<a href="https://tools.ietf.org/html/rfc3461">(RFC 3461)</a>, +a MIME content for the reporting of delivery reports +<a href="https://tools.ietf.org/html/rfc3462">(RFC 3462)</a>, +an enumeration of extended status codes +<a href="https://tools.ietf.org/html/rfc3463">(RFC 3463)</a>, +and a multipart container for the delivery report +<a href="https://tools.ietf.org/html/rfc3464">(RFC 3464)</a>.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="SMTP-extension-DSN">1. Extension for DSN (RFC 3461)</h2> +<div class="sectionbody"> +<div class="literalblock"> +<div class="content"> +<pre>xtext = *( xchar / hexchar ) + +xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + +hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits</pre> +</div> +</div> +<div class="paragraph"> +<p>The EHLO extension name is <code>DSN</code>.</p> +</div> +<div class="paragraph"> +<p>This extension add two optional parameters to MAIL commands: <code>RET</code> and +<code>ENVID</code>.</p> +</div> +<div class="paragraph"> +<p>This extension add two optional parameters to RCTP commands: <code>NOTIFY</code> and +<code>ORCPT</code>.</p> +</div> +<div class="paragraph"> +<p>SMTP server MUST return the same reply-code as it would to the same MAIL/RCPT +command without parameters.</p> +</div> +<div class="paragraph"> +<p>SMTP server MUST NOT refuse a MAIL/RCPT command based on the absence or +presence of valid parameters.</p> +</div> +<div class="paragraph"> +<p>If the value is invalid or more than one ENVID or RET in MAIL command, +the server MUST issue the reply-code "501 syntax error in parameter".</p> +</div> +<div class="paragraph"> +<p>A DSN MUST NOT be returned to the sender if SMTP MAIL command was NULL ("<>"), +even if the sender’s address is available from other sources (e.g., the +message header). +Instead, it SHOULD inform the local postmaster of delivery failures.</p> +</div> +<div class="sect2"> +<h3 id="_relaying_to_other_confirming_smtp_server">1.1. Relaying to other confirming SMTP server</h3> +<div class="paragraph"> +<p>Any DSN extension parameter that is received MUST also appear on MAIL and/or +RCPT command which the message is relayed.</p> +</div> +<div class="paragraph"> +<p>An ORCPT parameter MAY be added to the RCPT command when the message is +relayed using address from RCPT command.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_relaying_to_non_conforming_smtp_server">1.2. Relaying to non-conforming SMTP server</h3> +<div class="paragraph"> +<p>If NOTIFY paramater contains SUCCESS and SMTP server return a success +(2xx) to RCPT command, client MUST issue a "relayed" DSN for that recipient.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY parameter contains "FAILURE" and SMTP server return a permanent +failure (5xx) to RCPT command, client MUST issue a "failed" DSN for that +recipient.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY parameter contains NEVER and SMTP server return a success or +permanent failure (5xx) to RCPT command, client MUST NOT issue a DSN that +recipient. +Client MAY inform the local postmaster of the delivery failure.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY parameter contains NEVER, client MAY use "<>" on +separate MAIL command.</p> +</div> +<div class="paragraph"> +<p>If no NOTIFY parameter, and server return a success, client MUST NOT issue any +DSN for that recipient.</p> +</div> +<div class="paragraph"> +<p>If no NOTIFY parameter, and server return 5xx, client MUST issue a "failed" +DSN for that recipient.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_local_delivery">1.3. Local Delivery</h3> +<div class="paragraph"> +<p>If NOTIFY contains SUCCESS, MTA MUST issue "delivered" DSN for that +recipient.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY contains SUCCESS or no NOTIFY parameter, MTA MUST NOT issue a DSN +for that recipient.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_delays_in_delivery">1.4. Delays in delivery</h3> +<div class="paragraph"> +<p>If NOTIFY contains DELAY or no NOTIFY parameter, MTA MAY issue "delayed" DSN +for that recipient.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY parameter is issued without DELAY keyword, MTA MUST NOT issue +"delayed" DSN for that recipient.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_failure_on_delivery">1.5. Failure on delivery</h3> +<div class="paragraph"> +<p>If NOTIFY parameter contains FAILURE or no NOTIFY parameter, a "failed" +DSN MUST be issued.</p> +</div> +<div class="paragraph"> +<p>If NOTIFY parameter does not contains FAILURE, DSN MUST NOT be issued, but +it MAY inform the local postmaster via mechanism that does not using DSN.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_mailing_list">1.6. Mailing List</h3> +<div class="paragraph"> +<p>If NOTIFY parameter contains SUCCESS, and the message is placed on list’s +mailbox or accepted by list’s server, a "delivered" DSN must be issued.</p> +</div> +<div class="paragraph"> +<p>When redistributed to members of mailing list,</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>The envelope return address is rewritten to point to the list maintainer.</p> +</li> +<li> +<p>The ENVID, NOTIFY, RET, and ORCPT parameters MUST NOT be derived from the +original message.</p> +</li> +<li> +<p>The NOTIFY and RET parameters MAY be specified by the list administrator.</p> +</li> +<li> +<p>ORCPT parameter SHOULD contain the address of member.</p> +</li> +</ul> +</div> +</div> +<div class="sect2"> +<h3 id="_mail_ret_parameter">1.7. MAIL RET Parameter</h3> +<div class="literalblock"> +<div class="content"> +<pre>"RET=" "FULL" / "HDRS"</pre> +</div> +</div> +<div class="paragraph"> +<p><code>FULL</code> requests that the entire message be returned in any "failed" DSN issued +for this recipient.</p> +</div> +<div class="paragraph"> +<p><code>HDRS</code> only the headers of the message be returned.</p> +</div> +<div class="paragraph"> +<p>It MAY be up to 8 characters.</p> +</div> +<div class="paragraph"> +<p>The parameter value is case insensitive.</p> +</div> +<div class="paragraph"> +<p>If no RET parameter is defined or their value is emtpy, MTA MAY return headers +only or full message.</p> +</div> +<div class="paragraph"> +<p>If a DSN contains no indications of delivery failure, only the headers of the +message SHOULD be returned.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_mail_envid_parameter">1.8. MAIL ENVID Parameter</h3> +<div class="literalblock"> +<div class="content"> +<pre>"ENVID=" *xtext</pre> +</div> +</div> +<div class="paragraph"> +<p>ENVID, or enveloper identifier, purpose is to allow the sender of a message to +identify the transaction for which the DSN was issued.</p> +</div> +<div class="paragraph"> +<p>It MAY be up to 100 characters.</p> +</div> +<div class="paragraph"> +<p>The ENVID MUST consist of printable (graphic and white space) characters from +the US-ASCII.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_rcpt_notify_parameter">1.9. RCPT NOTIFY Parameter</h3> +<div class="literalblock"> +<div class="content"> +<pre>"NOTIFY=" "NEVER" / ("SUCCESS" [ "," "FAILURE"] [ "," "DELAY" ])</pre> +</div> +</div> +<div class="paragraph"> +<p>The NEVER keyword MUST appear by itself.</p> +</div> +<div class="paragraph"> +<p>"NEVER" requests that a DSN not be returned to the sender under any +conditions.</p> +</div> +<div class="paragraph"> +<p>"SUCCESS" or "FAILURE" value indicated that a DSN be issued on successful +delivery or delivery failure, respectively.</p> +</div> +<div class="paragraph"> +<p>"DELAY" indicates the sender’s willingness to receive "delayed" DSNs.</p> +</div> +<div class="paragraph"> +<p>It MAY be up to 28 characters.</p> +</div> +<div class="paragraph"> +<p>The absence of a NOTIFY parameter MAY be interpreted as either +<code>NOTIFY=FAILURE</code> or <code>NOTIFY=FAILURE,DELAY</code>.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_rcpt_orcpt_parameter">1.10. RCPT ORCPT Parameter</h3> +<div class="literalblock"> +<div class="content"> +<pre>"ORCPT=" addr-type ";" xtext</pre> +</div> +</div> +<div class="paragraph"> +<p>ORCPT parameter is used to specify an "original" recipient address that +corresponds to the actual recipient.</p> +</div> +<div class="paragraph"> +<p>It MUST have an associated value.</p> +</div> +<div class="paragraph"> +<p>It MAY be up to 500 characters.</p> +</div> +<div class="paragraph"> +<p>When used on personal message, it MUST contain the same address as the RCPT TO +address.</p> +</div> +<div class="paragraph"> +<p>When used on mailing-list, the ORCPT parameter MUST match the new RCPT TO +address of each recipient, not the address specified by the original sender of +the message.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_format_of_delivery_notifications">1.11. Format of delivery notifications</h3> +<div class="paragraph"> +<p>MAIL command argument MUST be a null ("<>").</p> +</div> +<div class="paragraph"> +<p>RCPT command argument is copied from the original message MAIL command.</p> +</div> +<div class="paragraph"> +<p>The RET parameter MUST NOT be used. +The NOTIFY parameter MAY be used, with value MUST be NEVER. +The ENVID and/or ORCPT parameter MAY be used.</p> +</div> +<div class="paragraph"> +<p>The MIME message is "multipart/report" with "report-type" is +"delivery-status".</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_multipart_report_content_type_rfc_3462">2. Multipart-Report Content Type (RFC 3462)</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>This section provide summary and notes on implementation of "multipart/report" +MIME type on SMTP protocol as defined in <a href="https://tools.ietf.org/html/rfc3462">RFC 3462</a>.</p> +</div> +<div class="paragraph"> +<p>The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type +is a general "family" or "container" type for electronic mail reports of any +kind.</p> +</div> +<div class="paragraph"> +<p>Format of content-type,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"Content-Type:" SP "multipart/report;" + FWS "report-type=" report-type ";" + FWS "boundary=" boundary</pre> +</div> +</div> +<div class="paragraph"> +<p>When used to send a report, it MUST be the top-level MIME content type.</p> +</div> +<div class="paragraph"> +<p>The Multipart/Report content-type contains either two or three sub- +parts, in the following order:</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>(Required) The first body part contains human readable message.</p> +</li> +<li> +<p>(Required) A machine parse-able body part containing an account of +the reported message handling event. The purpose of this body part is +to provide a machine-readable description of the conditions that +caused the report to be generated, along with details not present in +the first body part that may be useful to human experts. An initial +body part, "message/delivery-status" is defined in RFC 3464 (see below).</p> +</li> +<li> +<p>(Optional) A body part containing the returned message or a portion +thereof.</p> +</li> +</ol> +</div> +<div class="sect2"> +<h3 id="_the_textrfc822_headers_content_type">2.1. The text/rfc822-headers content-type</h3> +<div class="paragraph"> +<p>Format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"Content-Type:" SP "text/rfc822-headers"</pre> +</div> +</div> +<div class="paragraph"> +<p>The text/rfc822-headers body part should contain all the RFC822 header lines +from the message which caused the report.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="status-codes">3. Enhanced Mail System Status Codes (RFC 3463)</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Syntax,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>status-code = class "." subject "." detail +class = "2"/"4"/"5" +subject = 1*3digit +detail = 1*3digit</pre> +</div> +</div> +<div class="paragraph"> +<p>White-space characters and comments are NOT allowed within a status-code.</p> +</div> +<div class="paragraph"> +<p>Each numeric sub-code within the status-code MUST be expressed without leading +zero digits.</p> +</div> +<div class="sect2"> +<h3 id="_class">3.1. Class</h3> +<div class="ulist"> +<ul> +<li> +<p>2.XXX.XXX Success</p> +</li> +<li> +<p>4.XXX.XXX Persistent Transient Failure</p> +</li> +<li> +<p>5.XXX.XXX Permanent Failure</p> +</li> +</ul> +</div> +</div> +<div class="sect2"> +<h3 id="_subject">3.2. Subject</h3> +<div class="ulist"> +<ul> +<li> +<p>X.0.XXX Other or Undefined Status</p> +</li> +<li> +<p>X.1.XXX Addressing Status. Problem on sender’s recipient address.</p> +<div class="ulist"> +<ul> +<li> +<p>X.1.0 Other address status</p> +</li> +<li> +<p>X.1.1 Bad destination mailbox address</p> +</li> +<li> +<p>X.1.2 Bad destination system address</p> +</li> +<li> +<p>X.1.3 Bad destination mailbox address syntax</p> +</li> +<li> +<p>X.1.4 Destination mailbox address ambiguous</p> +</li> +<li> +<p>X.1.5 Destination mailbox address valid</p> +</li> +<li> +<p>X.1.6 Mailbox has moved</p> +</li> +<li> +<p>X.1.7 Bad sender’s mailbox address syntax</p> +</li> +<li> +<p>X.1.8 Bad sender’s system address</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.2.XXX Mailbox Status. Problem on receiver.</p> +<div class="ulist"> +<ul> +<li> +<p>X.2.0 Other or undefined mailbox status</p> +</li> +<li> +<p>X.2.1 Mailbox disabled, not accepting messages</p> +</li> +<li> +<p>X.2.2 Mailbox full</p> +</li> +<li> +<p>X.2.3 Message length exceeds administrative limit.</p> +</li> +<li> +<p>X.2.4 Mailing list expansion problem</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.3.XXX Mail System Status. Problem on receiver (destination MTA).</p> +<div class="ulist"> +<ul> +<li> +<p>X.3.0 Other or undefined mail system status</p> +</li> +<li> +<p>X.3.1 Mail system full</p> +</li> +<li> +<p>X.3.2 System not accepting network messages</p> +</li> +<li> +<p>X.3.3 System not capable of selected features</p> +</li> +<li> +<p>X.3.4 Message too big for system</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.4.XXX Network and Routing Status. Problem receiver (destination MTA).</p> +<div class="ulist"> +<ul> +<li> +<p>X.4.0 Other or undefined network or routing status</p> +</li> +<li> +<p>X.4.1 No answer from host</p> +</li> +<li> +<p>X.4.2 Bad connection</p> +</li> +<li> +<p>X.4.3 Routing server failure</p> +</li> +<li> +<p>X.4.4 Unable to route</p> +</li> +<li> +<p>X.4.5 Network congestion</p> +</li> +<li> +<p>X.4.6 Routing loop detected</p> +</li> +<li> +<p>X.4.7 Delivery time expired</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.5.XXX Mail Delivery Protocol Status</p> +<div class="ulist"> +<ul> +<li> +<p>X.5.0 Other or undefined protocol status</p> +</li> +<li> +<p>X.5.1 Invalid command</p> +</li> +<li> +<p>X.5.2 Syntax error</p> +</li> +<li> +<p>X.5.3 Too many recipients</p> +</li> +<li> +<p>X.5.4 Invalid command arguments</p> +</li> +<li> +<p>X.5.5 Wrong protocol version</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.6.XXX Message Content or Media Status.</p> +<div class="ulist"> +<ul> +<li> +<p>X.6.0 Other or undefined media error</p> +</li> +<li> +<p>X.6.1 Media not supported</p> +</li> +<li> +<p>X.6.2 Conversion required and prohibited</p> +</li> +<li> +<p>X.6.3 Conversion required but not supported</p> +</li> +<li> +<p>X.6.4 Conversion with loss performed</p> +</li> +<li> +<p>X.6.5 Conversion failed</p> +</li> +</ul> +</div> +</li> +<li> +<p>X.7.XXX Security or Policy Status.</p> +<div class="ulist"> +<ul> +<li> +<p>X.7.0 Other or undefined security status</p> +</li> +<li> +<p>X.7.1 Delivery not authorized, message refused</p> +</li> +<li> +<p>X.7.2 Mailing list expansion prohibited</p> +</li> +<li> +<p>X.7.3 Security conversion required but not possible</p> +</li> +<li> +<p>X.7.4 Security features not supported</p> +</li> +<li> +<p>X.7.5 Cryptographic failure</p> +</li> +<li> +<p>X.7.6 Cryptographic algorithm not supported</p> +</li> +<li> +<p>X.7.7 Message integrity failure</p> +</li> +</ul> +</div> +</li> +</ul> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_message_format_for_dsn_rfc_3464">4. Message Format for DSN (RFC 3464)</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>This section provide summary and notes on implementation of DSN on SMTP +protocol as defined in <a href="https://tools.ietf.org/html/rfc3464">RFC 3464</a>.</p> +</div> +<div class="paragraph"> +<p>A DSN is a "multipart/report" MIME message with three components,</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>Human readable explanation of the DSN</p> +</li> +<li> +<p>Machine readable delivery-status</p> +</li> +<li> +<p>Original message</p> +</li> +</ol> +</div> +<div class="sect2"> +<h3 id="_human_readable_explanation_of_the_dsn">4.1. Human readable explanation of the DSN</h3> +<div class="paragraph"> +<p>Format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>Date: {timestamp-with-zone} +From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> +To: <owner-info-mime@cs.utk.edu> +MIME-Version: 1.0 +Content-Type: message/report; + report-type=delivery-status; + boundary="{boundary}" +Subject: Returned mail: Cannot send message for 5 days + +--{boundary} + + (Explain the notification in human readable format)</pre> +</div> +</div> +<div class="paragraph"> +<p>The "From" field of message header of DSN SHOULD contain the address of human +who responsible at Reporting-MTA and SHOULD be chosen so that DSN will not +generate mail loops.</p> +</div> +<div class="paragraph"> +<p>The "To" field of message header and "RCPT TO:" parameter is return-path from +"MAIL FROM:" command.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_machine_readable_explanation_of_dsn">4.2. Machine readable explanation of DSN</h3> +<div class="paragraph"> +<p>Header format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>CRLF +"--" boundary CRLF +"Content-Type: message/delivery-status" CRLF +CRLF +message-fields +CRLF +1*(recipient-fields)</pre> +</div> +</div> +<div class="paragraph"> +<p>The body of this sub-part contain message-fields and one or more +recipient-fields.</p> +</div> +<div class="paragraph"> +<p>Any header that start with "X-" are extension fields; such names are reserved +for experimental use.</p> +</div> +<div class="paragraph"> +<p>Each sender-specified recipient address SHOULD result in at most one +"delivered" or "failed" DSN for that recipient</p> +</div> +<div class="sect3"> +<h4 id="_format_for_message_fields">4.2.1. Format for message-fields</h4> +<div class="literalblock"> +<div class="content"> +<pre>[ "Original-Envelope-Id:" SP envelope-id CRLF ] +"Reporting-MTA:" SP mta-type ";" MTA-name CRLF +[ "DSN-Gateway:" SP "dns;" MTA-name CRLF ] +[ "Received-From-MTA:" SP "dns;" MTA-name CRLF ] +[ "Arrival-Date" ":" date-time CRLF ]</pre> +</div> +</div> +<div class="paragraph"> +<p>The "Original-Envelope-ID" MUST be supplied if original message MAIL command +contains ENVID, except when a DSN is issued by the sender’s MTA itself (Sender +MTA = Reporting MTA)</p> +</div> +<div class="paragraph"> +<p>If no ENVID parameter, the "Original-Envelope-ID" field MUST NOT be supplied.</p> +</div> +<div class="paragraph"> +<p>The "envelope-id" is CASE-SENSITIVE. +The DSN MUST preserve the original case and spelling of the envelope-id.</p> +</div> +<div class="paragraph"> +<p>MTA-type MUST be "dns" if MTA is connected to internet, otherwise it SHOULD be +"x-local-hostname".</p> +</div> +<div class="paragraph"> +<p>MTA-name are case sensitive. +MTA-name SHOULD be valid Internet domain names. +If such domain names are not available, a domain-literal containing the +internet protocol address is acceptable.</p> +</div> +<div class="paragraph"> +<p>DSN-Gateway field MUST appear in any DSN that was translated by a gateway from +a foreign system into DSN format, and MUST NOT appear otherwise.</p> +</div> +<div class="paragraph"> +<p>Received-From-MTA field indicates the name of the Reporting MTA.</p> +</div> +<div class="paragraph"> +<p>Arrival-Date field indicates the date and time at which the message arrived at +the Reporting MTA.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_format_for_recipient_fields">4.2.2. Format for recipient-fields</h4> +<div class="literalblock"> +<div class="content"> +<pre>[ "Original-Recipient:" SP address-type ";" generic-address CRLF ] +"Final-Recipient:" SP address-type ";" generic-address CRLF +"Action:" SP action-value CRLF +"Status:" SP status-code CRLF +[ "Remote-MTA: dns;" mta-name CRLF ] +[ "Diagnostic-Code:" SP diagnostic-type ";" *text CRLF ] +[ "Last-Attempt-Date:" date-time CRLF ] +[ "Final-Log-ID:" *text CRLF ] +[ "Will-Retry-Until" ":" date-time CRLF ]</pre> +</div> +</div> +<div class="sect4"> +<h5 id="_original_recipient_and_final_recipient">Original-Recipient and Final-Recipient</h5> +<div class="paragraph"> +<p>address-type field is "rfc822".</p> +</div> +<div class="paragraph"> +<p>address-type field is "unknown" if the Reporting MTA cannot determine the type +of the original recipient address from the message envelope.</p> +</div> +<div class="paragraph"> +<p>The generic-address sub-field of Original-Recipient field is recipient address +in the message envelope.</p> +</div> +<div class="paragraph"> +<p>The generic-address sub-field of the Final-Recipient field MUST contain the +mailbox address of the recipient (from the transport envelope), as it was when +the Reporting MTA accepted the message for delivery.</p> +</div> +<div class="paragraph"> +<p>The case of alphabetic characters in the address MUST be preserved.</p> +</div> +<div class="paragraph"> +<p>If sender supplied ORCPT parameter, the Original-Recipient MUST be supplied, +otherwise this field MUST NOT appear.</p> +</div> +</div> +<div class="sect4"> +<h5 id="_action">Action</h5> +<div class="paragraph"> +<p>action-value is case insensitive, with one of the following values,</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>"failed" indicates that the message could not be delivered to the recipient.</p> +</li> +<li> +<p>"delayed" indicates that the Reporting MTA has so far been unable +to deliver or relay the message, but it will continue to attempt to do so.</p> +</li> +<li> +<p>"delivered" indicates that the message was successfully delivered to +the recipient address specified by the sender. +It does not indicate that the message has been read. +This is a terminal state and no further DSN for this recipient should be +expected.</p> +</li> +<li> +<p>"relayed" indicates that the message has been relayed or gateway-ed +into an environment that does not accept responsibility for generating DSNs +upon successful delivery. +This action-value SHOULD NOT be used unless the sender has requested +notification of successful delivery for this recipient.</p> +</li> +<li> +<p>"expanded" indicates that the message has been successfully delivered to the +recipient address as specified by the sender, and forwarded by the +Reporting-MTA beyond that destination to multiple additional recipient +addresses. +An action-value of "expanded" differs from "delivered" in that "expanded" is +not a terminal state. +Further "failed" and/or "delayed" notifications may be provided. +This value SHOULD NOT be used with a DSN issued on delivery of a message to a +"mailing list".</p> +</li> +</ul> +</div> +</div> +<div class="sect4"> +<h5 id="_status">Status</h5> +<div class="paragraph"> +<p>Each numeric sub-field within the status-code MUST be expressed without +leading zero digits.</p> +</div> +<div class="paragraph"> +<p>See section <a href="#status-codes">Enhanced Mail System Status Codes (RFC 3463)</a> for its value.</p> +</div> +</div> +<div class="sect4"> +<h5 id="_remote_mta">Remote-MTA</h5> +<div class="paragraph"> +<p>For DSNs resulting from attempts to relay a message to one or more recipients +via SMTP, the Remote-MTA field MUST be supplied for each of those recipients.</p> +</div> +</div> +<div class="sect4"> +<h5 id="_diagnostic_code">Diagnostic-Code</h5> +<div class="paragraph"> +<p>For DSNs resulting from attempts to relay a message to one or more recipients +via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients, +with diagnostic-type is set to "smtp".</p> +</div> +</div> +<div class="sect4"> +<h5 id="_last_attempt_date">Last-Attempt-Date</h5> +<div class="paragraph"> +<p>The Last-Attempt-Date field gives the date and time of the last attempt to +relay, gateway, or deliver the message (whether successful or unsuccessful) by +the Reporting MTA.</p> +</div> +<div class="paragraph"> +<p>It MUST NOT be included if the actual date and time of the last delivery +attempt are not available.</p> +</div> +</div> +<div class="sect4"> +<h5 id="_final_log_id">Final-Log-ID</h5> +<div class="paragraph"> +<p>This can be useful as an index to the final-mta’s log entry for that delivery +attempt.</p> +</div> +</div> +<div class="sect4"> +<h5 id="_will_retry_until">Will-Retry-Until</h5> +<div class="paragraph"> +<p>This header is for "delayed" status, which inform the final MTA the data and +time when the message will be abandoned if delivery is keep failing.</p> +</div> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_original_message">4.3. Original message</h3> +<div class="paragraph"> +<p>This sub-part contains the original message headers and/or message data, +depends on the value of RET parameter on RCPT command.</p> +</div> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2018-12-31 20:35:09 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/ESMTP_TLS.html b/doc/ESMTP_TLS.html new file mode 100644 index 00000000..8b79435c --- /dev/null +++ b/doc/ESMTP_TLS.html @@ -0,0 +1,195 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>SMTP Service Extension for Secure SMTP over Transport Layer Security</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article toc2 toc-left"> +<div id="header"> +<h1>SMTP Service Extension for Secure SMTP over Transport Layer Security</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc2"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_service_extension">1. Service Extension</a></li> +<li><a href="#_starttls_command">2. STARTTLS command</a> +<ul class="sectlevel2"> +<li><a href="#_request">2.1. Request</a> +<ul class="sectlevel3"> +<li><a href="#_success_response">2.1.1. Success Response</a></li> +<li><a href="#_error_response">2.1.2. Error Response</a></li> +</ul> +</li> +</ul> +</li> +<li><a href="#_post_tls_handshake">3. Post TLS Handshake</a> +<ul class="sectlevel2"> +<li><a href="#_client">3.1. Client</a></li> +<li><a href="#_server">3.2. Server</a></li> +</ul> +</li> +<li><a href="#_security_considerations">4. Security Considerations</a></li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This documentation provide summary and notes on implementation of SMTP +service extension for secure SMTP over Transport Layer Security (TLS) as +defined in <a href="https://tools.ietf.org/html/rfc3207">RFC3207</a>.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_service_extension">1. Service Extension</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The EHLO keyword value associated with the extension is "STARTTLS" with no +parameter.</p> +</div> +<div class="paragraph"> +<p>A new SMTP command "STARTTLS" is defined.</p> +</div> +<div class="paragraph"> +<p>A publicly-referenced SMTP server (on port 25) MUST NOT require use of the +STARTTLS extension in order to deliver mail locally.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_starttls_command">2. STARTTLS command</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_request">2.1. Request</h3> +<div class="literalblock"> +<div class="content"> +<pre>"STARTTLS" CRLF</pre> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response">2.1.1. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>"220" SP *text CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>After receiving a 220 response to a STARTTLS command, the client MUST start +the TLS negotiation before giving any other SMTP commands. +If, after having issued the STARTTLS command, the client finds out that some +failure prevents it from actually starting a TLS handshake, then it SHOULD +abort the connection.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_error_response">2.1.2. Error Response</h4> +<div class="ulist"> +<ul> +<li> +<p>454 TLS not available due to temporary reason</p> +</li> +<li> +<p>501 Syntax error (no parameters allowed)</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>If the client receives the 454 response, the client must decide whether or not +to continue the SMTP session.</p> +</div> +<div class="paragraph"> +<p>A SMTP server that is not publicly referenced may choose to require that the +client perform a TLS negotiation before accepting any commands. +In this case, the server SHOULD return the reply code:</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"530 Must issue a STARTTLS command first" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>to every command other than NOOP, EHLO, STARTTLS, or QUIT. +If the client and server are using the ENHANCEDSTATUSCODES ESMTP extension +[RFC2034], the status code to be returned SHOULD be 5.7.0.</p> +</div> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_post_tls_handshake">3. Post TLS Handshake</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_client">3.1. Client</h3> +<div class="paragraph"> +<p>The client MUST discard any knowledge obtained from the server, such as the +list of SMTP service extensions, which was not obtained from the TLS +negotiation itself. +The client SHOULD send an EHLO command as the first command after a successful +TLS negotiation.</p> +</div> +<div class="paragraph"> +<p>The list of SMTP service extensions returned in response to an EHLO command +received after the TLS handshake MAY be different than the list returned +before the TLS handshake.</p> +</div> +<div class="paragraph"> +<p>A client MUST NOT attempt to start a TLS session if a TLS session is already +active.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_server">3.2. Server</h3> +<div class="paragraph"> +<p>The server MUST discard any knowledge obtained from the client, such as the +argument to the EHLO command, which was not obtained from the TLS negotiation +itself.</p> +</div> +<div class="paragraph"> +<p>A server MUST NOT return the STARTTLS extension in response to an EHLO command +received after a TLS handshake has completed.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_security_considerations">4. Security Considerations</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>If the SMTP client decides that the level of authentication or privacy is not +high enough for it to continue, it SHOULD issue an SMTP QUIT command +immediately after the TLS negotiation is complete.</p> +</div> +<div class="paragraph"> +<p>If the SMTP server decides that the level of authentication or privacy is not +high enough for it to continue, it SHOULD reply to every SMTP command from the +client (other than a QUIT command) with,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"554 Command refused due to lack of security" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>the server may choose to not accept any more SMTP commands.</p> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2019-01-07 10:52:23 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/IMF.html b/doc/IMF.html new file mode 100644 index 00000000..909bead3 --- /dev/null +++ b/doc/IMF.html @@ -0,0 +1,666 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>Internet Message Format (IMF)</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article toc2 toc-left"> +<div id="header"> +<h1>Internet Message Format (IMF)</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc2"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_syntax">1. Syntax</a> +<ul class="sectlevel2"> +<li><a href="#_date_and_time_specification">1.1. Date and Time Specification</a></li> +<li><a href="#_address_specification">1.2. Address Specification</a></li> +</ul> +</li> +<li><a href="#_header">2. Header</a> +<ul class="sectlevel2"> +<li><a href="#_date_field">2.1. Date Field</a></li> +<li><a href="#_originator_fields">2.2. Originator Fields</a></li> +<li><a href="#_destination_fields">2.3. Destination Fields</a></li> +<li><a href="#_identification_field">2.4. Identification Field</a></li> +<li><a href="#_informational_fields">2.5. Informational Fields</a></li> +<li><a href="#_resent_fields">2.6. Resent Fields</a></li> +<li><a href="#_trace_fields">2.7. Trace Fields</a></li> +<li><a href="#_optional_fields">2.8. Optional Fields</a></li> +</ul> +</li> +<li><a href="#_obsolete_specification">3. Obsolete Specification</a> +<ul class="sectlevel2"> +<li><a href="#_obsolete_date_and_time">3.1. Obsolete Date and Time</a></li> +<li><a href="#_obsolete_addressing">3.2. Obsolete Addressing</a></li> +<li><a href="#_obsolete_header_fields">3.3. Obsolete Header Fields</a></li> +</ul> +</li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This documentation provide summary and notes on implementation of Internet +Message Format as defined in <a href="https://tools.ietf.org/html/rfc5322">RFC 5322</a>.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_syntax">1. Syntax</h2> +<div class="sectionbody"> +<div class="literalblock"> +<div class="content"> +<pre>message = (fields / obs-fields) + [CRLF body] + +fields = *(header-key ":" header-value CRLF) + +body = (*(*998text CRLF) *998text) / obs-body + +text = %d1-9 / ; Characters excluding CR + %d11 / ; and LF + %d12 / + %d14-127</pre> +</div> +</div> +<div class="paragraph"> +<p>Each line MUST be no more than 998 characters, and SHOULD be no more than 78 +characters, excluding the CRLF.</p> +</div> +<div class="paragraph"> +<p>CR and LF MUST only occur together as CRLF; they MUST NOT appear +independently in the body.</p> +</div> +<div class="paragraph"> +<p><code>header-key</code> MUST be composed of printable US-ASCII characters, except colon. +<code>header-value</code> MUST NOT include CR and LF except when used in "folding" and +"unfolding".</p> +</div> +<div class="paragraph"> +<p><em>Folding</em> is a function to split a line into multiline with CRLF and WSP. For +example, the following line,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"Subject: This is a test" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>can be folded into,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"Subject: This is" CRLF +WSP "a test" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p><em>Unfolding</em> is the process that convert the multiline representation into a +single line.</p> +</div> +<div class="sect2"> +<h3 id="_date_and_time_specification">1.1. Date and Time Specification</h3> +<div class="paragraph"> +<p>Syntax,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> date-time = [ day-of-week "," ] date time [CFWS] + + day-of-week = ([FWS] day-name) / obs-day-of-week + + day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" + + date = day month year + + day = ([FWS] 1*2DIGIT FWS) / obs-day + + month = "Jan" / "Feb" / "Mar" / "Apr" / + "May" / "Jun" / "Jul" / "Aug" / + "Sep" / "Oct" / "Nov" / "Dec" + + year = (FWS 4*DIGIT FWS) / obs-year + + time = time-of-day zone + + time-of-day = hour ":" minute [ ":" second ] + + hour = 2DIGIT / obs-hour + + minute = 2DIGIT / obs-minute + + second = 2DIGIT / obs-second + + zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone</pre> +</div> +</div> +<div class="paragraph"> +<p>The date and time-of-day SHOULD express local time.</p> +</div> +<div class="paragraph"> +<p>The form "+0000" on zone SHOULD be used to indicate a time zone at Universal +Time.</p> +</div> +<div class="paragraph"> +<p>The form "-0000" on zone indicate that the time was generated on a system that +may be in a local time zone other than Universal Time and that the date-time +contains no information about the local time zone.</p> +</div> +<div class="paragraph"> +<p>A date-time specification MUST be semantically valid. +The day-of-week MUST be the day implied by the date. +The numeric day-of-month MUST be between 1 and the number of days allowed +for the specified month (in the specified year), +The time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of +seconds allowing for a leap second. +The last two digits of the zone MUST be within the range 00 through 59.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_address_specification">1.2. Address Specification</h3> +<div class="paragraph"> +<p>An address may either be an individual mailbox, or a group of mailboxes.</p> +</div> +<div class="paragraph"> +<p>Format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> group-list = mailbox-list / CFWS / obs-group-list + + mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list + + address-list = (address *("," address)) / obs-addr-list + + address = mailbox / group + + mailbox = name-addr / addr-spec + + name-addr = [display-name] angle-addr + + angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / + obs-angle-addr + + group = display-name ":" [group-list] ";" [CFWS] + + display-name = phrase + + addr-spec = local-part "@" domain + + local-part = dot-atom / quoted-string / obs-local-part + + domain = dot-atom / domain-literal / obs-domain + + domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] + + dtext = %d33-90 / ; Printable US-ASCII + %d94-126 / ; characters not including + obs-dtext ; "[", "]", or "\"</pre> +</div> +</div> +<div class="paragraph"> +<p>dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used. +Comments and folding white space SHOULD NOT be used around the "@" in the +addr-spec.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_header">2. Header</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> fields = *(trace + *optional-field / + *(resent-date / + resent-from / + resent-sender / + resent-to / + resent-cc / + resent-bcc / + resent-msg-id)) + *(orig-date / + from / + sender / + reply-to / + to / + cc / + bcc / + message-id / + in-reply-to / + references / + subject / + comments / + keywords / + optional-field) + + +----------------+--------+------------+----------------------------+ + | Field | Min | Max number | Notes | + | | number | | | + +----------------+--------+------------+----------------------------+ + | trace | 0 | unlimited | Block prepended - see | + | | | | 3.6.7 | + | resent-date | 0* | unlimited* | One per block, required if | + | | | | other resent fields are | + | | | | present - see 3.6.6 | + | resent-from | 0 | unlimited* | One per block - see 3.6.6 | + | resent-sender | 0* | unlimited* | One per block, MUST occur | + | | | | with multi-address | + | | | | resent-from - see 3.6.6 | + | resent-to | 0 | unlimited* | One per block - see 3.6.6 | + | resent-cc | 0 | unlimited* | One per block - see 3.6.6 | + | resent-bcc | 0 | unlimited* | One per block - see 3.6.6 | + | resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 | + | orig-date | 1 | 1 | | + | from | 1 | 1 | See sender and 3.6.2 | + | sender | 0* | 1 | MUST occur with | + | | | | multi-address from - see | + | | | | 3.6.2 | + | reply-to | 0 | 1 | | + | to | 0 | 1 | | + | cc | 0 | 1 | | + | bcc | 0 | 1 | | + | message-id | 0* | 1 | SHOULD be present - see | + | | | | 3.6.4 | + | in-reply-to | 0* | 1 | SHOULD occur in some | + | | | | replies - see 3.6.4 | + | references | 0* | 1 | SHOULD occur in some | + | | | | replies - see 3.6.4 | + | subject | 0 | 1 | | + | comments | 0 | unlimited | | + | keywords | 0 | unlimited | | + | optional-field | 0 | unlimited | | + +----------------+--------+------------+----------------------------+</pre> +</div> +</div> +<div class="paragraph"> +<p>Header fields SHOULD NOT be reordered when a message is transported or +transformed. +More importantly, the trace header fields and resent header fields MUST NOT be +reordered, and SHOULD be kept in blocks prepended to the message.</p> +</div> +<div class="paragraph"> +<p>The only required header fields are the "Date" field and the originator +address field(s) (which is "From", "Sender", and "Reply-To").</p> +</div> +<div class="sect2"> +<h3 id="_date_field">2.1. Date Field</h3> +<div class="paragraph"> +<p>The origination date specifies the date and time at which the creator of the +message indicated that the message was complete and ready to enter the mail +delivery system.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>orig-date = "Date:" date-time CRLF</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_originator_fields">2.2. Originator Fields</h3> +<div class="literalblock"> +<div class="content"> +<pre> from = "From:" mailbox-list CRLF + + sender = "Sender:" mailbox CRLF + + reply-to = "Reply-To:" address-list CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>If the from field contains more than one mailbox, then the sender field MUST +appear in the message.</p> +</div> +<div class="paragraph"> +<p>If the originator of the message can be indicated by a single mailbox and the +author and transmitter are identical, the "Sender:" field SHOULD NOT be used. +Otherwise, both fields SHOULD appear.</p> +</div> +<div class="paragraph"> +<p>When the "Reply-To:" field is present, it indicates the address(es) to which +the author of the message suggests that replies be sent. +In the absence of the "Reply-To:" field, replies SHOULD by default be sent to +the mailbox(es) specified in the "From:" field unless otherwise specified by +the person composing the reply.</p> +</div> +<div class="paragraph"> +<p>In all cases, the "From:" field SHOULD NOT contain any mailbox that does not +belong to the author(s) of the message.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_destination_fields">2.3. Destination Fields</h3> +<div class="literalblock"> +<div class="content"> +<pre> to = "To:" address-list CRLF + + cc = "Cc:" address-list CRLF + + bcc = "Bcc:" [address-list / CFWS] CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>The "To:" field contains the address(es) of the primary recipient(s) of the +message.</p> +</div> +<div class="paragraph"> +<p>The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a +copy on a typewriter using carbon paper) contains the addresses of others who +are to receive the message, though the content of the message may not be +directed at them.</p> +</div> +<div class="paragraph"> +<p>The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains +addresses of recipients of the message whose addresses are not to be +revealed to other recipients of the message.</p> +</div> +<div class="paragraph"> +<p>There are three ways in which the "Bcc:" field is used,</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>The "Bcc:" line is removed even though all of the recipients (including +those specified in the "Bcc:" field) are sent a copy of the message.</p> +</li> +<li> +<p>Recipients specified in the "To:" and "Cc:" lines each are sent +a copy of the message with the "Bcc:" line removed as above, but the +recipients on the "Bcc:" line get a separate copy of the message +containing a "Bcc:" line. (When there are multiple recipient +addresses in the "Bcc:" field, some implementations actually send a +separate copy of the message to each recipient with a "Bcc:" +containing only the address of that particular recipient.)</p> +</li> +<li> +<p>Since a "Bcc:" field may contain no addresses, a "Bcc:" field can be +sent without any addresses indicating to the recipients that blind +copies were sent to someone.</p> +</li> +</ol> +</div> +<div class="paragraph"> +<p>Which method to use with "Bcc:" fields is implementation dependent, but refer +to the "Security Considerations" section of this document for a discussion of +each.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_identification_field">2.4. Identification Field</h3> +<div class="paragraph"> +<p>Every message SHOULD have a "Message-ID:" field.</p> +</div> +<div class="paragraph"> +<p>Reply messages SHOULD have "In-Reply-To:" and "References:" fields.</p> +</div> +<div class="paragraph"> +<p>Format,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> message-id = "Message-ID:" msg-id CRLF + + in-reply-to = "In-Reply-To:" 1*msg-id CRLF + + references = "References:" 1*msg-id CRLF + + msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] + + id-left = dot-atom-text / obs-id-left + + id-right = dot-atom-text / no-fold-literal / obs-id-right + + no-fold-literal = "[" *dtext "]"</pre> +</div> +</div> +<div class="paragraph"> +<p>msg-id is intended to be machine readable and not necessarily meaningful to +humans.</p> +</div> +<div class="paragraph"> +<p>A liberal syntax is given for the id-right; however, the use of a domain is +RECOMMENDED.</p> +</div> +<div class="paragraph"> +<p>The "In-Reply-To:" and "References:" fields are used when creating a +reply to a message. +"In-Reply-To:" field may be used to identify the message (or messages) to +which the new message is a reply (one or more parent), while the "References:" +field may be used to identify a "thread" of conversation.</p> +</div> +<div class="paragraph"> +<p>Trying to form a "References:" field for a reply that has multiple parents is +discouraged.</p> +</div> +<div class="paragraph"> +<p>The message identifier (msg-id) itself MUST be a globally unique identifier +for a message.</p> +</div> +<div class="paragraph"> +<p>Semantically, the angle bracket characters are not part of the msg-id; the +msg-id is what is contained between the two angle bracket characters.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_informational_fields">2.5. Informational Fields</h3> +<div class="literalblock"> +<div class="content"> +<pre> subject = "Subject:" unstructured CRLF + + comments = "Comments:" unstructured CRLF + + keywords = "Keywords:" phrase *("," phrase) CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>When used in a reply, the "Subject" body MAY start with the string "Re: " (an +abbreviation of the Latin "in re", meaning "in the matter of") +followed by the contents of the "Subject:" field body of the original message. +If this is done, only one instance of the literal string "Re: " ought to be +used since use of other strings or more than one instance can lead to +undesirable consequences.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_resent_fields">2.6. Resent Fields</h3> +<div class="paragraph"> +<p>Resent fields SHOULD be added to any message that is reintroduced by +a user into the transport system. +A separate set of resent fields SHOULD be added each time this is done. +All of the resent fields corresponding to a particular resending of the +message SHOULD be grouped together. +Each new set of resent fields is prepended to the message; that is, the most +recent set of resent fields appears earlier in the message. +No other fields in the message are changed when resent fields are added.</p> +</div> +<div class="paragraph"> +<p>Each of the resent fields corresponds to a particular field elsewhere in the +syntax.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> resent-date = "Resent-Date:" date-time CRLF + + resent-from = "Resent-From:" mailbox-list CRLF + + resent-sender = "Resent-Sender:" mailbox CRLF + + resent-to = "Resent-To:" address-list CRLF + + resent-cc = "Resent-Cc:" address-list CRLF + + resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF + + resent-msg-id = "Resent-Message-ID:" msg-id CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>When resent fields are used, the "Resent-From:" and "Resent-Date:" +fields MUST be sent. +The "Resent-Message-ID:" field SHOULD be sent. +"Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be identical to +"Resent-From:".</p> +</div> +<div class="paragraph"> +<p>The "Resent-Message-ID:" field provides a unique identifier for the resent +message.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_trace_fields">2.7. Trace Fields</h3> +<div class="literalblock"> +<div class="content"> +<pre> trace = [return] + 1*received + + return = "Return-Path:" path CRLF + + path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) + + received = "Received:" *received-token ";" date-time CRLF + + received-token = word / angle-addr / addr-spec / domain</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_optional_fields">2.8. Optional Fields</h3> +<div class="paragraph"> +<p>The field names of any optional field MUST NOT be identical to any field name +specified elsewhere in this document.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> optional-field = field-name ":" unstructured CRLF + + field-name = 1*ftext + + ftext = %d33-57 / ; Printable US-ASCII + %d59-126 ; characters not including + ; ":".</pre> +</div> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_obsolete_specification">3. Obsolete Specification</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_obsolete_date_and_time">3.1. Obsolete Date and Time</h3> +<div class="paragraph"> +<p>The syntax for the obsolete date format allows</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>a 2 digit year in the date field, and</p> +</li> +<li> +<p>alphabetic time zone specifiers</p> +</li> +</ol> +</div> +<div class="paragraph"> +<p>Where a two or three digit year occurs in a date, the year is to be +interpreted as follows:</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>If a two digit year is encountered whose value is between 00 and 49, the +year is interpreted by adding 2000, ending up with a value between 2000 and +2049.</p> +</li> +<li> +<p>If a two digit year is encountered with a value between 50 and 99, or any +three digit year is encountered, the year is interpreted by adding 1900.</p> +</li> +</ol> +</div> +<div class="paragraph"> +<p>Obsolete zones,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>EDT is semantically equivalent to -0400 +EST is semantically equivalent to -0500 +CDT is semantically equivalent to -0500 +CST is semantically equivalent to -0600 +MDT is semantically equivalent to -0600 +MST is semantically equivalent to -0700 +PDT is semantically equivalent to -0700 +PST is semantically equivalent to -0800</pre> +</div> +</div> +<div class="paragraph"> +<p>However, because of the error in [RFC0822], any time zones SHOULD all be +considered equivalent to "-0000" unless there is out-of-band information +confirming their meaning.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_obsolete_addressing">3.2. Obsolete Addressing</h3> +<div class="paragraph"> +<p>There are four primary differences in addressing.</p> +</div> +<div class="olist arabic"> +<ol class="arabic"> +<li> +<p>mailbox addresses were allowed to have a route portion before the +addr-spec when enclosed in "<" and ">". +The route is simply a comma-separated list of domain names, each preceded by +"@", and the list terminated by a colon.</p> +</li> +<li> +<p>CFWS were allowed between the period-separated elements of local-part and +domain (i.e., dot-atom was not used). +In addition, local-part is allowed to contain quoted-string in addition to +just atom.</p> +</li> +<li> +<p>mailbox-list and address-list were allowed to have "null" members. +That is, there could be two or more commas in such a list with nothing in +between them, or commas at the beginning or end of the list.</p> +</li> +<li> +<p>US-ASCII control characters and quoted-pairs were allowed in domain literals and are added here.</p> +</li> +</ol> +</div> +</div> +<div class="sect2"> +<h3 id="_obsolete_header_fields">3.3. Obsolete Header Fields</h3> +<div class="paragraph"> +<p>Syntactically, the primary difference in the obsolete field syntax is +that it allows multiple occurrences of any of the fields and they may +occur in any order. +Also, any amount of white space is allowed before the ":" at the end of the +field name.</p> +</div> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2018-12-31 20:35:09 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/SASL.html b/doc/SASL.html new file mode 100644 index 00000000..4b563fec --- /dev/null +++ b/doc/SASL.html @@ -0,0 +1,419 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>Simple Authentication and Security Layer (SASL)</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article"> +<div id="header"> +<h1>Simple Authentication and Security Layer (SASL)</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_introduction">1. Introduction</a></li> +<li><a href="#_identity_concepts">2. Identity Concepts</a></li> +<li><a href="#_the_authentication_exchange">3. The Authentication Exchange</a> +<ul class="sectlevel2"> +<li><a href="#_mechanism_naming">3.1. Mechanism Naming</a></li> +<li><a href="#_security_layers">3.2. Security Layers</a></li> +</ul> +</li> +<li><a href="#_protocol_requirements">4. Protocol Requirements</a></li> +<li><a href="#_mechanism_specifications">5. Mechanism Specifications</a></li> +<li><a href="#_security_considerations">6. Security Considerations</a> +<ul class="sectlevel2"> +<li><a href="#_active_attacks">6.1. Active Attacks</a></li> +<li><a href="#_passive_attacks">6.2. Passive Attacks</a></li> +<li><a href="#_re_keying">6.3. Re-keying</a></li> +</ul> +</li> +<li><a href="#_mechanism_registry">7. Mechanism Registry</a></li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This document provide note and summary of RFC 4422, Simple Authentication and +Security Layer (SASL).</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_introduction">1. Introduction</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>SASL is conceptually a framework that provides an abstraction layer between +protocols and mechanisms as illustrated in the following diagram.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> SMTP LDAP XMPP Other protocols ... + \ | | / + \ | | / + SASL abstraction layer + / | | \ + / | | \ + EXTERNAL GSSAPI PLAIN Other mechanisms ...</pre> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_identity_concepts">2. Identity Concepts</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Authentication identity is an identity that is used on credential form that +will be passed to SASL server to get the authorization identity.</p> +</div> +<div class="paragraph"> +<p>Authorization identity is the actual identity in system.</p> +</div> +<div class="paragraph"> +<p>For example, the username and password to login to system is called +authentication identity, and when the username exist and the password is +correct, the system may use unique number (identification or ID) as +authorization identity to replace the username.</p> +</div> +<div class="paragraph"> +<p>The SASL describe the syntax and semantics on how the username, password, +and authorization identity to be transferred by mechanism.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_the_authentication_exchange">3. The Authentication Exchange</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The following illustration provides a high-level overview of an +authentication exchange.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>C: Request available mechanism on server +S: List of available mechanism +<Client select the best and suitable mechanism> +C: Request authentication exchange +<Mechanism name + [ additional data ]> +S: Initial challenge +C: Initial response +<additional challenge/response messages> +S: Outcome of authentication exchange</pre> +</div> +</div> +<div class="paragraph"> +<p>Some mechanism may simplified this exchange into,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>C: Request authentication exchange + Initial response +S: Outcome of authentication exchange</pre> +</div> +</div> +<div class="paragraph"> +<p>The initial response may contains the authentication identity, depends on +mechanism specification.</p> +</div> +<div class="paragraph"> +<p>The authentication exchange involves one or more pairs of server-challenges +and client-responses, the particulars of which are mechanism specific.</p> +</div> +<div class="paragraph"> +<p>Server may return the authorization identity to client when on the successful +outcome of authentication exchange.</p> +</div> +<div class="paragraph"> +<p>Server MUST provide an outcome message that can be distinguished between +errors from input by client or errors from server (for example, invalid +credential, timeout, internal server error).</p> +</div> +<div class="paragraph"> +<p>Client or server may abort the authentication exchange any time.</p> +</div> +<div class="sect2"> +<h3 id="_mechanism_naming">3.1. Mechanism Naming</h3> +<div class="literalblock"> +<div class="content"> +<pre>sasl-mech = 1*20mech-char +mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE +; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ +; from ASCII character set. + +UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) +DIGIT = %x30-39 ; 0-9 +HYPHEN = %x2D ; hyphen (-) +UNDERSCORE = %x5F ; underscore (_)</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_security_layers">3.2. Security Layers</h3> +<div class="paragraph"> +<p>If use of a security layer is negotiated in the authentication protocol +exchange, the layer is installed by the server after indicating the outcome of +the authentication exchange and installed by the client upon receipt of the +success outcome indication. +The security layer is in effect until underlying transport connection is +closed.</p> +</div> +<div class="paragraph"> +<p>The underlying transport connection MUST be closed when the security layer +unable or unwilling to encode or decode buffers that protect protocol data.</p> +</div> +<div class="paragraph"> +<p>The length of the protected data buffer MUST be no larger than the maximum +size that the other side expects. +The maximum size is fixed by mechanism, either through negotiation or by +specification. +Upon the receipt of a length field whose value is greater than the maximum +size, the receiver SHOULD close the connection, as this might be a sign of an +attack.</p> +</div> +<div class="paragraph"> +<p>If a security layer is in effect and a subsequent SASL negotiation selects a +second security layer, then the second security layer replaces the first.</p> +</div> +<div class="paragraph"> +<p>If a security layer is in effect and a subsequent SASL negotiation selects no +security layer, the original security layer remains in effect.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_protocol_requirements">4. Protocol Requirements</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>In order for a protocol to offer SASL services, its specification +MUST supply the following information:</p> +</div> +<div class="paragraph"> +<p>1) A service name, to be selected from registry of "service" elements for +the Generic Security Service Application Program Interface (GSSAPI) host-based +service name form.</p> +</div> +<div class="paragraph"> +<p>2) A function through which the client may discover the names of the SASL +mechanisms that the server makes available to the client.</p> +</div> +<div class="paragraph"> +<p>3) Definition of the messages necessary for authentication exchange, +including the following:</p> +</div> +<div class="paragraph"> +<p>3.a) A message to initiate the authentication exchange. +The message MUST contain a field for mechanism name and SHOULD contain an +optional field for carrying an initial response. +The message MUST be able to distinguished between an empty initial response +and no initial response.</p> +</div> +<div class="paragraph"> +<p>3.b) Messages to transfer server challenges and client responses.</p> +</div> +<div class="paragraph"> +<p>3.c) A message to indicate the outcome of the authentication. +This message SHOULD contain an optional field for carrying additional data +with a successful outcome.</p> +</div> +<div class="paragraph"> +<p>4) Prescribe the syntax and semantics of non-empty authorization identity +strings exchange. +The protocol specification MUST detail precisely how and where (client or +server) non-empty authorization identity strings are prepared, +including all normalizations, for comparison and other applicable +functions to ensure proper function.</p> +</div> +<div class="paragraph"> +<p>5) Detail any facility the protocol provides that allows the client and/or +server to abort authentication exchange.</p> +</div> +<div class="paragraph"> +<p>6) Identify precisely where newly negotiated security layers start to take +effect, in both directions.</p> +</div> +<div class="paragraph"> +<p>7) If the protocol supports other layered security services, such as Transport +Layer Security (TLS), the specification MUST prescribe the order in +which security layers are applied to protocol data.</p> +</div> +<div class="paragraph"> +<p>8) Indicate whether the protocol supports multiple authentications. +If so, the protocol MUST detail the effect a failed SASL authentication +exchange will have upon a previously established authentication and +authorization state.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_mechanism_specifications">5. Mechanism Specifications</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>SASL mechanism specifications MUST supply the following information:</p> +</div> +<div class="paragraph"> +<p>1) The name of the mechanism.</p> +</div> +<div class="paragraph"> +<p>2) A definition of the server-challenges and client-responses of the +authentication exchange, as well as the following:</p> +</div> +<div class="paragraph"> +<p>2.a) An indication of whether the mechanism is client-first. +If a SASL mechanism is defined as client-first and the client does not send an +initial response in the authentication request, then the first server +challenge MUST be empty. +If a SASL mechanism is defined as server-first, then the client MUST NOT send +an initial client response in the authentication request.</p> +</div> +<div class="paragraph"> +<p>2.b) An indication of whether the server is expected to provide additional +data when indicating a successful outcome.</p> +</div> +<div class="paragraph"> +<p>SASL mechanisms SHOULD be designed to minimize the number of challenges and +responses necessary to complete the exchange.</p> +</div> +<div class="paragraph"> +<p>3) An indication of whether the mechanism is capable of transferring +authorization identity strings. +The mechanism SHOULD NOT be capable of transferring both no authorization +identity string and an empty authorization identity.</p> +</div> +<div class="paragraph"> +<p>Mechanisms that are capable of transferring an authorization identity string +MUST be capable of transferring arbitrary non-empty sequences of Unicode +characters, excluding those that contain the NUL (U+0000) character. +The specification MUST detail how any Unicode code points special to the +mechanism that might appear in the authorization identity string are escaped +to avoid ambiguity during decoding of the authorization identity string.</p> +</div> +<div class="paragraph"> +<p>4) The specification MUST detail whether the mechanism offers a security +layer.</p> +</div> +<div class="paragraph"> +<p>5) If the underlying cryptographic technology used by a mechanism supports +data integrity, then the mechanism specification MUST integrity protect the +transmission of an authorization identity and the negotiation of the security +layer.</p> +</div> +<div class="paragraph"> +<p>SASL mechanisms SHOULD be protocol neutral.</p> +</div> +<div class="paragraph"> +<p>SASL mechanisms SHOULD reuse existing credential and identity forms, +as well as associated syntaxes and semantics.</p> +</div> +<div class="paragraph"> +<p>SASL mechanisms SHOULD use the UTF-8 transformation format for encoding +Unicode code points for transfer.</p> +</div> +<div class="paragraph"> +<p>The mechanism SHOULD NOT use the authorization identity string in generation +of any long-term cryptographic keys or hashes as there is no requirement that +the authorization identity string be canonical.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_security_considerations">6. Security Considerations</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_active_attacks">6.1. Active Attacks</h3> +<div class="paragraph"> +<p>When use of a security layer is negotiated by the authentication protocol +exchange, the receiver SHOULD handle gracefully any protected data buffer +larger than the defined/negotiated maximal size. +In particular, it MUST NOT blindly allocate the amount of memory specified in +the buffer size field, as this might cause the "out of memory" condition. +If the receiver detects a large block, it SHOULD close the connection.</p> +</div> +<div class="sect3"> +<h4 id="_hijack_attacks">6.1.1. Hijack Attacks</h4> +<div class="paragraph"> +<p>Implementations SHOULD close the connection security layer report protocol +data lack of data integrity.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_downgrade_attacks">6.1.2. Downgrade Attacks</h4> +<div class="paragraph"> +<p>Implementations SHOULD NOT advertise mechanisms and/or features that cannot +meet their minimum security requirements. +Implementation SHOULD NOT enter into or continue authentication exchanges that +cannot meet their minimum security requirements, and SHOULD verify that +completed authentication exchanges result in security services that meet their +minimum security requirements.</p> +</div> +<div class="paragraph"> +<p>If the client finds that the integrity-protected list (the list obtained after +the security layer was installed) contains a stronger mechanism than those in +the previously obtained list, the client should assume that the previously +obtained list was modified by an attacker and SHOULD close the underlying +transport connection.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_replay_attacks">6.1.3. Replay Attacks</h4> +<div class="paragraph"> +<p>Some mechanisms may be subject to replay attacks unless protected by +external data security services (e.g., TLS).</p> +</div> +</div> +<div class="sect3"> +<h4 id="_truncation_attacks">6.1.4. Truncation Attacks</h4> +<div class="paragraph"> +<p>A protocol can defend against these attacks by ensuring that each information +exchange has a clear final result and that each protocol session has a +graceful closure mechanism, and that these are integrity protected.</p> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_passive_attacks">6.2. Passive Attacks</h3> +<div class="paragraph"> +<p>Many mechanisms are subject to various passive attacks, including simple +eavesdropping of unprotected credential information as well as online and +off-line dictionary attacks of protected credential information.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_re_keying">6.3. Re-keying</h3> +<div class="paragraph"> +<p>Re-keying (key renegotiation process) is a way of addressing the weakening of +cryptographic keys. +The SASL framework does not itself provide for re-keying; SASL mechanisms may. +Designers of future SASL mechanisms should consider providing re-keying +services.</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_mechanism_registry">7. Mechanism Registry</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The SASL mechanism registry is maintained by IANA. +The registry is currently available at +<a href="http://www.iana.org/assignments/sasl-mechanisms" class="bare">http://www.iana.org/assignments/sasl-mechanisms</a>.</p> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2019-01-14 04:52:26 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/SASL_PLAIN.html b/doc/SASL_PLAIN.html new file mode 100644 index 00000000..09e9dc02 --- /dev/null +++ b/doc/SASL_PLAIN.html @@ -0,0 +1,105 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>The PLAIN Simple Authentication and Security Layer (SASL) Mechanism</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article"> +<div id="header"> +<h1>The PLAIN Simple Authentication and Security Layer (SASL) Mechanism</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_introduction">1. Introduction</a></li> +<li><a href="#_mechanism">2. Mechanism</a></li> +<li><a href="#_security_considerations">3. Security Considerations</a></li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This document provide note and summary of RFC 4616, The PLAIN Simple +Authentication and Security Layer (SASL) Mechanism.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_introduction">1. Introduction</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The name associated with this mechanism is "PLAIN".</p> +</div> +<div class="paragraph"> +<p>The PLAIN mechanism does not provide a security layer.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_mechanism">2. Mechanism</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The mechanism consists of a single message, a string of [UTF-8] encoded +[Unicode] characters, from the client to the server.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>message = [authzid] UTF8NUL authcid UTF8NUL password +authcid = 1*SAFE ; MUST accept up to 255 octets +authzid = 1*SAFE ; MUST accept up to 255 octets +password = 1*SAFE ; MUST accept up to 255 octets +UTF8NUL = %x00 ; UTF-8 encoded NUL character + +SAFE = UTF1 / UTF2 / UTF3 / UTF4 + ;; any UTF-8 encoded Unicode character except NUL + +UTF1 = %x01-7F ;; except NUL +UTF2 = %xC2-DF UTF0 +UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / + %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) +UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / + %xF4 %x80-8F 2(UTF0) +UTF0 = %x80-BF</pre> +</div> +</div> +<div class="paragraph"> +<p>The form of the authorization identity (authzid) production is specific to the +application-level protocol’s. +The authentication identity (authcid) and password productions are form-free. +Use of non-visible characters or characters that a user may be unable to +enter on some keyboards is discouraged.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_security_considerations">3. Security Considerations</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>By default, implementations SHOULD NOT advertise and SHOULD NOT make use of +the PLAIN mechanism unless adequate data security services are in place, +generally through use of Transport Layer Security (TLS) service.</p> +</div> +<div class="paragraph"> +<p>Clients are encouraged to have an operational mode where all mechanisms that +are likely to reveal the user’s password to the server are disabled.</p> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2019-01-14 04:51:57 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/doc/SMTP.html b/doc/SMTP.html new file mode 100644 index 00000000..11fe3d1c --- /dev/null +++ b/doc/SMTP.html @@ -0,0 +1,1022 @@ +<!DOCTYPE html> +<html lang="en"> +<head> +<meta charset="UTF-8"> +<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta name="generator" content="Asciidoctor 1.5.8"> +<meta name="author" content="Shulhan"> +<title>Simple Mail Transfer Protocol (SMTP)</title> +<link rel="stylesheet" href="./solarized.css"> +</head> +<body class="article toc2 toc-left"> +<div id="header"> +<h1>Simple Mail Transfer Protocol (SMTP)</h1> +<div class="details"> +<span id="author" class="author">Shulhan</span><br> +<span id="email" class="email"><<a href="mailto:ms@kilabit.info">ms@kilabit.info</a>></span><br> +</div> +<div id="toc" class="toc2"> +<div id="toctitle">Table of Contents</div> +<ul class="sectlevel1"> +<li><a href="#_syntax">1. Syntax</a> +<ul class="sectlevel2"> +<li><a href="#_format_of_request">1.1. Format of Request</a> +<ul class="sectlevel3"> +<li><a href="#_format_of_parameters">1.1.1. Format of Parameters</a></li> +</ul> +</li> +<li><a href="#_format_of_response">1.2. Format of Response</a></li> +<li><a href="#_format_of_path">1.3. Format of Path</a></li> +<li><a href="#_format_of_domain">1.4. Format of Domain</a></li> +<li><a href="#_format_of_mailbox">1.5. Format of Mailbox</a></li> +</ul> +</li> +<li><a href="#_session_initiation">2. Session Initiation</a> +<ul class="sectlevel2"> +<li><a href="#_request">2.1. Request</a></li> +<li><a href="#_success_response">2.2. Success Response</a></li> +<li><a href="#_error_response">2.3. Error Response</a></li> +</ul> +</li> +<li><a href="#_mail_transaction">3. Mail Transaction</a> +<ul class="sectlevel2"> +<li><a href="#_heloehlo">3.1. HELO/EHLO</a> +<ul class="sectlevel3"> +<li><a href="#_request_2">3.1.1. Request</a></li> +<li><a href="#_success_response_2">3.1.2. Success response</a></li> +<li><a href="#_error_responses">3.1.3. Error responses</a></li> +</ul> +</li> +<li><a href="#_mail">3.2. MAIL</a> +<ul class="sectlevel3"> +<li><a href="#_request_3">3.2.1. Request</a></li> +<li><a href="#_success_response_3">3.2.2. Success response</a></li> +<li><a href="#_error_response_2">3.2.3. Error response</a></li> +</ul> +</li> +<li><a href="#_rcpt">3.3. RCPT</a> +<ul class="sectlevel3"> +<li><a href="#_request_4">3.3.1. Request</a></li> +<li><a href="#_success_response_4">3.3.2. Success Response</a></li> +<li><a href="#_error_response_3">3.3.3. Error Response</a></li> +</ul> +</li> +<li><a href="#_data">3.4. DATA</a> +<ul class="sectlevel3"> +<li><a href="#_request_5">3.4.1. Request</a></li> +<li><a href="#_success_response_5">3.4.2. Success Response</a></li> +<li><a href="#_error_responses_2">3.4.3. Error Responses</a></li> +</ul> +</li> +<li><a href="#_message_data">3.5. Message Data</a> +<ul class="sectlevel3"> +<li><a href="#_request_6">3.5.1. Request</a></li> +<li><a href="#_success_response_6">3.5.2. Success Response</a></li> +<li><a href="#_error_responses_3">3.5.3. Error Responses</a></li> +</ul> +</li> +<li><a href="#_rset">3.6. RSET</a> +<ul class="sectlevel3"> +<li><a href="#_request_7">3.6.1. Request</a></li> +<li><a href="#_success_response_7">3.6.2. Success Response</a></li> +<li><a href="#_error_responses_4">3.6.3. Error responses,</a></li> +</ul> +</li> +</ul> +</li> +<li><a href="#_others_commands">4. Others Commands</a> +<ul class="sectlevel2"> +<li><a href="#_vrfy">4.1. VRFY</a> +<ul class="sectlevel3"> +<li><a href="#_request_8">4.1.1. Request</a></li> +<li><a href="#_success_response_8">4.1.2. Success Response</a></li> +<li><a href="#_error_responses_5">4.1.3. Error Responses</a></li> +</ul> +</li> +<li><a href="#_expn">4.2. EXPN</a> +<ul class="sectlevel3"> +<li><a href="#_request_9">4.2.1. Request</a></li> +<li><a href="#_success_response_9">4.2.2. Success Response</a></li> +<li><a href="#_error_responses_6">4.2.3. Error Responses</a></li> +</ul> +</li> +<li><a href="#_help">4.3. HELP</a> +<ul class="sectlevel3"> +<li><a href="#_request_10">4.3.1. Request</a></li> +<li><a href="#_success_responses">4.3.2. Success Responses</a></li> +<li><a href="#_error_responses_7">4.3.3. Error Responses</a></li> +</ul> +</li> +<li><a href="#_noop">4.4. NOOP</a> +<ul class="sectlevel3"> +<li><a href="#_request_11">4.4.1. Request</a></li> +<li><a href="#_success_response_10">4.4.2. Success Response</a></li> +</ul> +</li> +<li><a href="#_quit">4.5. QUIT</a> +<ul class="sectlevel3"> +<li><a href="#_request_12">4.5.1. Request</a></li> +<li><a href="#_success_response_11">4.5.2. Success Response</a></li> +</ul> +</li> +</ul> +</li> +<li><a href="#_extensions">5. Extensions</a></li> +<li><a href="#_glossary">6. Glossary</a></li> +</ul> +</div> +</div> +<div id="content"> +<div id="preamble"> +<div class="sectionbody"> +<div class="paragraph"> +<p>This documentation provide summary and notes on implementation of SMTP +as defined in <a href="https://tools.ietf.org/html/rfc5321">RFC 5321</a>.</p> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_syntax">1. Syntax</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_format_of_request">1.1. Format of Request</h3> +<div class="literalblock"> +<div class="content"> +<pre>Command [ SP argument [ SP parameters ]] CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>Server SHOULD tolerate trailing white space before <code>CRLF</code>.</p> +</div> +<div class="paragraph"> +<p>If argument is mailbox, the syntax of local part MUST conform to receiver site +convention.</p> +</div> +<div class="sect3"> +<h4 id="_format_of_parameters">1.1.1. Format of Parameters</h4> +<div class="paragraph"> +<p>The parameters is only available for MAIL and RCPT commands.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>Mail-parameters = esmtp-param *(SP esmtp-param) + +Rcpt-parameters = esmtp-param *(SP esmtp-param) + +esmtp-param = esmtp-keyword ["=" esmtp-value] + +esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + +esmtp-value = 1*(%d33-60 / %d62-126) + ; any CHAR excluding "=", SP, and control + ; characters. If this string is an email address, + ; i.e., a Mailbox, then the "xtext" syntax [32] + ; SHOULD be used. + +Keyword = Ldh-str + +Argument = Atom</pre> +</div> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_format_of_response">1.2. Format of Response</h3> +<div class="paragraph"> +<p>Every request MUST generate one reply (section 4.2).</p> +</div> +<div class="paragraph"> +<p>There are two mode of response: single line and multi line.</p> +</div> +<div class="paragraph"> +<p>Format for single line response,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>Reply-code SP text CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>Format for multi line response,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> Reply-code "-" text CRLF +*(Reply-code "-" text CRLF) + Reply-code SP text CRLF</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_format_of_path">1.3. Format of Path</h3> +<div class="paragraph"> +<p>There are two type of path: Reverse-path and Forward-path. +Reverse-path is used as an argument on MAIL command, while Forward-path is +used as an argument on RCPT command.</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>Reverse-path = Path / "<>" +Forward-path = Path +Path = "<" [ A-d-l ":" ] Mailbox ">" + +A-d-l = At-domain *( "," At-domain ) + ; Note that this form, the so-called "source + ; route", MUST BE accepted, SHOULD NOT be + ; generated, and SHOULD be ignored. + +At-domain = "@" Domain</pre> +</div> +</div> +<div class="paragraph"> +<p>The use of source routes (The "A-d-l") is deprecated (RFC 5321, Appendix F.2), +while servers MUST be prepared to receive and handle them. +Clients SHOULD NOT transmit them and this section is included in the current +specification only to provide context.</p> +</div> +</div> +<div class="sect2"> +<h3 id="_format_of_domain">1.4. Format of Domain</h3> +<div class="literalblock"> +<div class="content"> +<pre>Domain = sub-domain *("." sub-domain) + +sub-domain = Let-dig [Ldh-str] + +Let-dig = ALPHA / DIGIT + +Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_format_of_mailbox">1.5. Format of Mailbox</h3> +<div class="literalblock"> +<div class="content"> +<pre>Mailbox = Local-part "@" ( Domain / address-literal ) + +Local-part = Dot-string / Quoted-string + ; MAY be case-sensitive + +address-literal = "[" ( IPv4-address-literal / + IPv6-address-literal / + General-address-literal ) "]" + ; See Section 4.1.3 + +Dot-string = Atom *("." Atom) + +Atom = 1*atext + +Quoted-string = DQUOTE *QcontentSMTP DQUOTE + +QcontentSMTP = qtextSMTP / quoted-pairSMTP + +quoted-pairSMTP = %d92 %d32-126 + ; i.e., backslash followed by any ASCII + ; graphic (including itself) or SPace + +qtextSMTP = %d32-33 / %d35-91 / %d93-126 + ; i.e., within a quoted string, any + ; ASCII graphic or space is permitted + ; without blackslash-quoting except + ; double-quote and the backslash itself. + +String = Atom / Quoted-string</pre> +</div> +</div> +<div class="paragraph"> +<p>Additional format defined in RFC 5322, section 3.2.3,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> atext = ALPHA / DIGIT / ; Printable US-ASCII + "!" / "#" / ; characters not including + "$" / "%" / ; specials. Used for atoms. + "&" / "'" / + "*" / "+" / + "-" / "/" / + "=" / "?" / + "^" / "_" / + "`" / "{" / + "|" / "}" / + "~" + + atom = [CFWS] 1*atext [CFWS] + + dot-atom-text = 1*atext *("." 1*atext) + + dot-atom = [CFWS] dot-atom-text [CFWS] + + specials = "(" / ")" / ; Special characters that do + "<" / ">" / ; not appear in atext + "[" / "]" / + ":" / ";" / + "@" / "\" / + "," / "." / + DQUOTE + + qtext = %d33 / ; Printable US-ASCII + %d35-91 / ; characters not including + %d93-126 / ; "\" or the quote character + obs-qtext + + qcontent = qtext / quoted-pair + + quoted-string = [CFWS] + DQUOTE *([FWS] qcontent) [FWS] DQUOTE + [CFWS] + + quoted-pair = ("\" (VCHAR / WSP)) / obs-qp</pre> +</div> +</div> +<div class="paragraph"> +<p>Server SHOULD avoid defining mailboxes where the Local-part requires (or uses) +the Quoted-string form or where the Local-part is case-sensitive.</p> +</div> +<div class="paragraph"> +<p>All quoted forms MUST be treated as equivalent. +The sending system SHOULD transmit the form that uses the minimum quoting +possible.</p> +</div> +<div class="paragraph"> +<p>Systems MUST NOT define mailboxes in such a way as to require the use in SMTP +of non-ASCII characters (octets with the high order bit set to one) or ASCII +"control characters" (decimal value 0-31 and 127). +These characters MUST NOT be used in MAIL or RCPT commands or other commands +that require mailbox names.</p> +</div> +<div class="paragraph"> +<p>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).</p> +</div> +<div class="paragraph"> +<p>Characters outside the set of alphabetic characters, digits, and hyphen MUST +NOT appear in domain name labels for SMTP clients or servers. +In particular, the underscore character is not permitted.</p> +</div> +<div class="paragraph"> +<p>SMTP servers that receive a command in which invalid character codes have been +employed, and for which there are no other reasons for rejection, MUST reject +that command with a 501 response (this rule, like others, could be overridden +by appropriate SMTP extensions).</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_session_initiation">2. Session Initiation</h2> +<div class="sectionbody"> +<div class="sect2"> +<h3 id="_request">2.1. Request</h3> +<div class="paragraph"> +<p>Client open a TCP connection to SMTP server on port 25 or 587 (with STARTTLS).</p> +</div> +</div> +<div class="sect2"> +<h3 id="_success_response">2.2. Success Response</h3> +<div class="paragraph"> +<p>On success, server reply with 220,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>( "220" (SP Domain / address-literal) [ SP text ] CRLF )</pre> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_error_response">2.3. Error Response</h3> +<div class="paragraph"> +<p>On failure, server will reply with 554,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre>"554 No SMTP service here" CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>Client SHOULD wait for the response until 5 minutes.</p> +</div> +<div class="paragraph"> +<p>Client SHOULD wait for this greeting message before sending any commands.</p> +</div> +<div class="paragraph"> +<p>A server that reply with 554 MUST still wait for the client to send a QUIT +(see Section 4.1.1.10) before closing the connection and SHOULD respond to any +intervening commands with "503 bad sequence of commands".</p> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_mail_transaction">3. Mail Transaction</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>Mail transaction constructed by four commands, in sequence order, with message +data and the end of transaction,</p> +</div> +<div class="ulist"> +<ul> +<li> +<p><code>HELO</code> or <code>EHLO</code>,</p> +</li> +<li> +<p><code>MAIL FROM:</code>,</p> +</li> +<li> +<p>One or more <code>RCPT TO:</code></p> +</li> +<li> +<p><code>DATA</code></p> +</li> +<li> +<p>Message data</p> +</li> +</ul> +</div> +<div class="sect2"> +<h3 id="_heloehlo">3.1. HELO/EHLO</h3> +<div class="paragraph"> +<p>Server MUST support HELO.</p> +</div> +<div class="paragraph"> +<p>Client SHOULD start a session by EHLO. If server return "command not +recognized", client SHOULD fall-back to HELO.</p> +</div> +<div class="paragraph"> +<p>Client MUST issue EHLO/HELO before starting a mail transaction.</p> +</div> +<div class="sect3"> +<h4 id="_request_2">3.1.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"HELO" SP Domain CRLF +"EHLO" SP ( Domain / address-literal ) CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>Client MUST use domain name that resolved to DNS A RR (address) +(Section 2.3.5), or SHOULD use IP address if not possible (section 4.1.4).</p> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_2">3.1.2. Success response</h4> +<div class="literalblock"> +<div class="content"> +<pre>( "250" SP Domain [ SP ehlo-greet ] CRLF ) +/ ( "250-" Domain [ SP ehlo-greet ] CRLF + *( "250-" ehlo-line CRLF ) + "250" SP ehlo-line CRLF ) + +ehlo-greet = string of any characters other than CR or LF +ehlo-line = ehlo-keyword *( SP ehlo-param ) +ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") +ehlo-param = any CHAR excluding <SP> and all control characters + (US-ASCII 0-31 and 127 inclusive)</pre> +</div> +</div> +<div class="paragraph"> +<p>EHLO response MUST contains keywords.</p> +</div> +<div class="paragraph"> +<p>EHLO keyword MUST always be processed in case insensitive.</p> +</div> +<div class="paragraph"> +<p>Servers MUST NOT return the extended EHLO- style response to a HELO command.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses">3.1.3. Error responses</h4> +<div class="ulist"> +<ul> +<li> +<p>502 Command not implemented</p> +</li> +<li> +<p>504 Command parameter not implemented</p> +</li> +<li> +<p>550 Requested action not taken: command rejected for policy reasons</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_mail">3.2. MAIL</h3> +<div class="sect3"> +<h4 id="_request_3">3.2.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"MAIL FROM:" Reverse-path [SP Mail-parameters] CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>Request line MUST have no space between colon.</p> +</div> +<div class="paragraph"> +<p>Request line MAY also carry parameters associated with a particular service +extension.</p> +</div> +<div class="paragraph"> +<p>Server MUST recognize source route syntax (section 3.3) in Reverse-path.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_3">3.2.2. Success response</h4> +<div class="literalblock"> +<div class="content"> +<pre>250 [ SP text ] CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_response_2">3.2.3. Error response</h4> +<div class="ulist"> +<ul> +<li> +<p>451 Requested action aborted: local error in processing</p> +</li> +<li> +<p>452 Requested action not taken: insufficient system storage</p> +</li> +<li> +<p>455 Server unable to accommodate parameters</p> +</li> +<li> +<p>503 Bad sequence of commands</p> +</li> +<li> +<p>550 Requested action not taken: mailbox unavailable (e.g., mailbox +not found, no access, or command rejected for policy reasons)</p> +</li> +<li> +<p>552 Requested mail action aborted: exceeded storage allocation</p> +</li> +<li> +<p>553 Requested action not taken: mailbox name not allowed (e.g., +mailbox syntax incorrect)</p> +</li> +<li> +<p>555 MAIL FROM/RCPT TO parameters not recognized or not implemented</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_rcpt">3.3. RCPT</h3> +<div class="sect3"> +<h4 id="_request_4">3.3.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"RCPT TO:" ( "<Postmaster@" Domain ">" + / "<Postmaster>" + / Forward-path ) [SP Rcpt-parameters] CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>MUST have no space between colon.</p> +</div> +<div class="paragraph"> +<p>Client SHOULD NOT generate the optional list of hosts known as a source route.</p> +</div> +<div class="paragraph"> +<p>Client MUST NOT transmit parameters other than those associated with a +service extension offered by the server in its EHLO response.</p> +</div> +<div class="paragraph"> +<p>Server MUST recognize source route syntax (section 3.3)</p> +</div> +<div class="paragraph"> +<p>Server SHOULD strip off the source route specification.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_4">3.3.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>250 [ SP text ] CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_response_3">3.3.3. Error Response</h4> +<div class="ulist"> +<ul> +<li> +<p>450 Requested mail action not taken: mailbox unavailable (e.g., +mailbox busy or temporarily blocked for policy reasons)</p> +</li> +<li> +<p>451 Requested action aborted: local error in processing</p> +</li> +<li> +<p>452 Requested action not taken: insufficient system storage</p> +</li> +<li> +<p>455 Server unable to accommodate parameters</p> +</li> +<li> +<p>503 Bad sequence of commands</p> +</li> +<li> +<p>550 Requested action not taken: mailbox unavailable (e.g., mailbox +not found, no access, or command rejected for policy reasons)</p> +</li> +<li> +<p>551 User not local; please try <forward-path> (See Section 3.4)</p> +</li> +<li> +<p>552 Requested mail action aborted: exceeded storage allocation</p> +</li> +<li> +<p>553 Requested action not taken: mailbox name not allowed (e.g., +mailbox syntax incorrect)</p> +</li> +<li> +<p>555 MAIL FROM/RCPT TO parameters not recognized or not implemented</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_data">3.4. DATA</h3> +<div class="sect3"> +<h4 id="_request_5">3.4.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"DATA" CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_5">3.4.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>"354" [ SP String ] CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_2">3.4.3. Error Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>503 Bad sequence of commands</p> +</li> +<li> +<p>554 Transaction failed (Or, in the case of a connection-opening +response, "No SMTP service here")</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_message_data">3.5. Message Data</h3> +<div class="paragraph"> +<p>Message data MUST NOT be send unless 354 reply code is received.</p> +</div> +<div class="sect3"> +<h4 id="_request_6">3.5.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>(*text) +CRLF +. +CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_6">3.5.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>250 [ SP text ] CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_3">3.5.3. Error Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>450 Requested mail action not taken: mailbox unavailable (e.g., +mailbox busy or temporarily blocked for policy reasons)</p> +</li> +<li> +<p>451 Requested action aborted: local error in processing</p> +</li> +<li> +<p>452 Requested action not taken: insufficient system storage</p> +</li> +<li> +<p>550 Requested action not taken: mailbox unavailable (e.g., mailbox +not found, no access, or command rejected for policy reasons)</p> +</li> +<li> +<p>552 Requested mail action aborted: exceeded storage allocation</p> +</li> +<li> +<p>554 Transaction failed (Or, in the case of a connection-opening +response, "No SMTP service here")</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_rset">3.6. RSET</h3> +<div class="paragraph"> +<p>This command clear the current buffer on MAIL, RCPT, and DATA, but not the +EHLO/HELO buffer.</p> +</div> +<div class="paragraph"> +<p>Server MUST NOT close the connection as the result of receiving a +RSET.</p> +</div> +<div class="sect3"> +<h4 id="_request_7">3.6.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"RSET" CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_7">3.6.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>"250 OK" CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_4">3.6.3. Error responses,</h4> +<div class="paragraph"> +<p>Not available.</p> +</div> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_others_commands">4. Others Commands</h2> +<div class="sectionbody"> +<div class="paragraph"> +<p>The following commands does not affect mail transaction.</p> +</div> +<div class="sect2"> +<h3 id="_vrfy">4.1. VRFY</h3> +<div class="paragraph"> +<p>This command is used to verify the existency of user in remote server.</p> +</div> +<div class="sect3"> +<h4 id="_request_8">4.1.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"VRFY" SP String CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>String MAY be user name with or without domain name.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_8">4.1.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>250 User name <local-part@domain> +/ 250 local-part@domain</pre> +</div> +</div> +<div class="paragraph"> +<p>If query to String return more than one mailbox, server may return 553 with +list of ambigous name,</p> +</div> +<div class="literalblock"> +<div class="content"> +<pre> "553" SP "User ambiguous" CRLF +/ "553-" Description CRLF + 1*("553-" [ user-name ] "<" local-part@domain ">" + "553 " [ user-name ] "<" local-part@domain ">"</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_5">4.1.3. Error Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>502 Command not implemented</p> +</li> +<li> +<p>504 Command parameter not implemented</p> +</li> +<li> +<p>550 Requested action not taken: mailbox unavailable (e.g., mailbox +not found, no access, or command rejected for policy reasons)</p> +</li> +<li> +<p>551 User not local; please try <forward-path> (See Section 3.4)</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_expn">4.2. EXPN</h3> +<div class="paragraph"> +<p>Command to identify mailing-list, if success, it will return list of members.</p> +</div> +<div class="sect3"> +<h4 id="_request_9">4.2.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"EXPN" SP String CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_9">4.2.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre> "250-" mailing-list name +1*("250-" [ member-name ] "<" member-address ">" + "250 " [ member-name ] "<" member-address ">"</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_6">4.2.3. Error Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>500 Syntax error, command unrecognized (This may include errors such +as command line too long)</p> +</li> +<li> +<p>502 Command not implemented</p> +</li> +<li> +<p>504 Command parameter not implemented</p> +</li> +<li> +<p>550 Requested action not taken: command rejected for policy reasons</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_help">4.3. HELP</h3> +<div class="paragraph"> +<p>Command to query information about server command.a</p> +</div> +<div class="paragraph"> +<p>Server SHOULD support HELP without arguments and MAY support it with +arguments.</p> +</div> +<div class="sect3"> +<h4 id="_request_10">4.3.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"HELP" [ SP String ] CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_responses">4.3.2. Success Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>211 System status, or system help reply</p> +</li> +<li> +<p>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)</p> +</li> +</ul> +</div> +</div> +<div class="sect3"> +<h4 id="_error_responses_7">4.3.3. Error Responses</h4> +<div class="ulist"> +<ul> +<li> +<p>502 Command not implemented</p> +</li> +<li> +<p>504 Command parameter not implemented</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_noop">4.4. NOOP</h3> +<div class="sect3"> +<h4 id="_request_11">4.4.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"NOOP" [ SP String ] CRLF</pre> +</div> +</div> +<div class="paragraph"> +<p>If a parameter string is specified, servers SHOULD ignore it.</p> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_10">4.4.2. Success Response</h4> +<div class="ulist"> +<ul> +<li> +<p>250 OK</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="_quit">4.5. QUIT</h3> +<div class="paragraph"> +<p>Command to issue closing the session.</p> +</div> +<div class="paragraph"> +<p>Server MUST NOT intentionally close the transmission channel until it receives +and replies to a QUIT command.</p> +</div> +<div class="paragraph"> +<p>Client MUST NOT intentionally close the transmission channel until it sends a +QUIT command, and it SHOULD wait until it receives the reply.</p> +</div> +<div class="paragraph"> +<p>Any current uncompleted mail transaction will be aborted.</p> +</div> +<div class="sect3"> +<h4 id="_request_12">4.5.1. Request</h4> +<div class="literalblock"> +<div class="content"> +<pre>"QUIT" CRLF</pre> +</div> +</div> +</div> +<div class="sect3"> +<h4 id="_success_response_11">4.5.2. Success Response</h4> +<div class="literalblock"> +<div class="content"> +<pre>"221" [ SP String ] CRLF</pre> +</div> +</div> +</div> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_extensions">5. Extensions</h2> +<div class="sectionbody"> +<div class="ulist"> +<ul> +<li> +<p><a href="ESMTP_DSN.html">Delivery Status Notification (RFC3461-3464)</a></p> +</li> +<li> +<p><a href="ESMTP_TLS.html">SMTP Service Extension for Secure SMTP over Transport +Layer Security (RFC3207)</a></p> +</li> +<li> +<p><a href="ESMTP_AUTH.html">SMTP Service Extension for Authentication (RFC4954)</a></p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect1"> +<h2 id="_glossary">6. Glossary</h2> +<div class="sectionbody"> +<div class="dlist"> +<dl> +<dt class="hdlist1">UA</dt> +<dd> +<p>User Agent</p> +</dd> +<dt class="hdlist1">MTA</dt> +<dd> +<p>Mail Transfer Agent</p> +</dd> +</dl> +</div> +</div> +</div> +</div> +<div id="footer"> +<div id="footer-text"> +Last updated 2019-01-10 16:15:02 +0700 +</div> +</div> +</body> +</html>
\ No newline at end of file |