_doc: prefix the simplified RFC file name with "RFC XXXX"

The idea is to know which file belong to which RFC without opening it.
Sometimes I forgot that I have read and summarize the RFC.

1 files changed, 101 insertions, 0 deletions

diff --git a/_doc/RFC_3207__ESMTP_TLS.adoc b/_doc/RFC_3207__ESMTP_TLS.adoc
new file mode 100644
index 00000000..2b156bf3
--- /dev/null
+++ b/_doc/RFC_3207__ESMTP_TLS.adoc
@@ -0,0 +1,101 @@
+= SMTP Service Extension for Secure SMTP over Transport Layer Security
+:author: Shulhan
+:email: <ms@kilabit.info>
+:toc:
+:toclevels: 4
+:sectnums:
+:url-rfc3207: https://tools.ietf.org/html/rfc3207
+
+This documentation provide summary and notes on implementation of SMTP
+service extension for secure SMTP over Transport Layer Security (TLS) as
+defined in {url-rfc3207}[RFC3207].
+
+== Service Extension
+
+The EHLO keyword value associated with the extension is "STARTTLS" with no
+parameter.
+
+A new SMTP command "STARTTLS" is defined.
+
+A publicly-referenced SMTP server (on port 25) MUST NOT require use of the
+STARTTLS extension in order to deliver mail locally.
+
+
+== STARTTLS command
+
+=== Request
+
+....
+"STARTTLS" CRLF
+....
+
+==== Success Response
+
+....
+"220" SP *text CRLF
+....
+
+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.
+
+==== Error Response
+
+* 454 TLS not available due to temporary reason
+* 501 Syntax error (no parameters allowed)
+
+If the client receives the 454 response, the client must decide whether or not
+to continue the SMTP session.
+
+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:
+
+    "530 Must issue a STARTTLS command first" CRLF
+
+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.
+
+
+== Post TLS Handshake
+
+=== Client
+
+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.
+
+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.
+
+A client MUST NOT attempt to start a TLS session if a TLS session is already
+active.
+
+=== Server
+
+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.
+
+A server MUST NOT return the STARTTLS extension in response to an EHLO command
+received after a TLS handshake has completed.
+
+== Security Considerations
+
+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.
+
+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,
+
+    "554 Command refused due to lack of security" CRLF
+
+the server may choose to not accept any more SMTP commands.