Editing Simple Mail Transfer Protocol (section)

==SMTP Extensions==
===Extension discovery mechanism===
Clients learn a server's supported options by using the <code>EHLO</code> greeting, as exemplified below, instead of the original <code>HELO</code>. Clients fall back to <code>HELO</code> only if the server does not support <code>EHLO</code> greeting.<ref>{{cite IETF |title=SMTP Service Extensions |rfc=1869 |author1=John Klensin |author2=Ned Freed |author3=Marshall T. Rose |author4=Einar A. Stefferud |author5=Dave Crocker |date=November 1995 |publisher=[[Internet Engineering Task Force|IETF]] }}</ref>

Modern clients may use the ESMTP extension keyword <code>SIZE</code> to query the server for the maximum message size that will be accepted. Older clients and servers may try to transfer excessively sized messages that will be rejected after consuming network resources, including connect time to network links that is paid by the minute.<ref name=parms>{{cite web|title=MAIL Parameters|url=https://www.iana.org/assignments/mail-parameters/mail-parameters.txt|publisher=IANA|date=14 February 2020|access-date=May 28, 2019|archive-date=May 28, 2019|archive-url=https://web.archive.org/web/20190528161544/https://www.iana.org/assignments/mail-parameters/mail-parameters.txt|url-status=live}}</ref>

Users can manually determine in advance the maximum size accepted by ESMTP servers. The client replaces the <code>HELO</code> command with the <code>EHLO</code> command.
 <span style="color: gray">S:</span> <span style="color: blue">220 smtp2.example.com ESMTP Postfix</span>
 <span style="color: gray">C:</span> EHLO bob.example.org
 <span style="color: gray">S:</span> <span style="color: blue">250-smtp2.example.com Hello bob.example.org [192.0.2.201]</span>
 <span style="color: gray">S:</span> <span style="color: blue">250-SIZE 14680064</span>
 <span style="color: gray">S:</span> <span style="color: blue">250-PIPELINING</span>
 <span style="color: gray">S:</span> <span style="color: blue">250 HELP</span>
Thus ''smtp2.example.com'' declares that it can accept a fixed maximum message size no larger than 14,680,064 [[Octet (computing)|octets]] (8-bit bytes).

In the simplest case, an ESMTP server declares a maximum <code>SIZE</code> immediately after receiving an <code>EHLO</code>. According to {{IETF RFC|1870}}, however, the numeric parameter to the <code>SIZE</code> extension in the <code>EHLO</code> response is optional. Clients may instead, when issuing a <code>MAIL FROM</code> command, include a numeric estimate of the size of the message they are transferring, so that the server can refuse receipt of overly-large messages.

===Binary data transfer===
Original SMTP supports only a single body of ASCII text, therefore any binary data needs to be encoded as text into that body of the message before transfer, and then decoded by the recipient. [[Binary-to-text encoding]]s, such as [[uuencode]] and [[BinHex]] were typically used.

The 8BITMIME command was developed to address this. It was standardized in 1994 as {{IETF RFC|1652|}}<ref>Which was obsoleted in 2011 by {{IETF RFC|6152|}} corresponding to the then new [[Internet standard|STD]] 71</ref> It facilitates the [[Transparency (telecommunication)|transparent]] exchange of [[e-mail]] messages containing octets outside the seven-bit [[ASCII]] character set by encoding them as [[MIME]] content parts, typically encoded with [[Base64]].

===Mail delivery mechanism extensions===

===On-Demand Mail Relay===
{{Main|On-Demand Mail Relay}}
'''On-Demand Mail Relay''' ('''ODMR''') is an SMTP extension standardized in {{IETF RFC|2645}} that allows an intermittently-connected SMTP server to receive email queued for it when it is connected.

===Internationalization extension===
{{Main|International email}}

Original SMTP supports email addresses composed of [[ASCII]] characters only, which is inconvenient for users whose native script is not Latin based, or who use [[diacritic]] not in the ASCII character set. This limitation was alleviated via extensions enabling UTF-8 in address names. {{IETF RFC|5336|}} introduced experimental<ref name=parms/> <code>UTF8SMTP</code> command and later was superseded by {{IETF RFC|6531|}} that introduced <code>SMTPUTF8</code> command. These extensions provide support for multi-byte and non-ASCII characters in email addresses, such as those with diacritics and other language characters such as [[Greek language|Greek]] and [[Chinese language|Chinese]].<ref>{{cite mailing list|url=http://www.ietf.org/mail-archive/web/ima/current/msg05395.html|title=Chinese email address|date=19 December 2014|access-date=24 May 2016|mailing-list=EAI|author=Jiankang Yao|publisher=[[Internet Engineering Task Force|IETF]]|archive-date=October 2, 2015|archive-url=https://web.archive.org/web/20151002170118/http://www.ietf.org/mail-archive/web/ima/current/msg05395.html|url-status=live}}</ref>

Current support is limited, but there is strong interest in broad adoption of {{IETF RFC|6531}} and the related RFCs in countries like [[China]] that have a large user base where Latin (ASCII) is a foreign script.

===Extensions===
Like SMTP, ESMTP is a protocol used to transport Internet mail. It is used as both an inter-server transport protocol and (with restricted behavior enforced) a mail submission protocol.

The main identification feature for ESMTP clients is to open a transmission with the command <code>EHLO</code> (Extended HELLO), rather than <code>HELO</code> (Hello, the original {{IETF RFC|821}} standard). A server will respond with success (code 250), failure (code 550) or error (code 500, 501, 502, 504, or 421), depending on its configuration. An ESMTP server returns the code 250 OK in a multi-line reply with its domain and a list of keywords to indicate supported extensions. A RFC 821 compliant server returns error code 500, allowing ESMTP clients to try either <code>HELO</code> or <code>QUIT</code>.

Each service extension is defined in an approved format in subsequent RFCs and registered with the [[Internet Assigned Numbers Authority]] (IANA). The first definitions were the RFC 821 optional services: <code>SEND</code>, <code>SOML</code> (Send or Mail), <code>SAML</code> (Send and Mail), <code>EXPN</code>, <code>HELP</code>, and <code>TURN</code>. The format of additional SMTP verbs was set and for new parameters in <code>MAIL</code> and <code>RCPT</code>.

Some relatively common keywords (not all of them corresponding to commands) used today are:
* <code>8BITMIME</code>&nbsp;– 8 bit data transmission, {{IETF RFC|6152}}
* <code>ATRN</code>&nbsp;– Authenticated <code>TURN</code> for [[On-Demand Mail Relay]], {{IETF RFC|2645}}
* <code>AUTH</code>&nbsp;– Authenticated SMTP, {{IETF RFC|4954}}
* <code>CHUNKING</code>&nbsp;– Chunking, {{IETF RFC|3030}}
* <code>DSN</code>&nbsp;– Delivery status notification, {{IETF RFC|3461}} (See [[Variable envelope return path]])
* <code>ETRN</code>&nbsp;– Extended version of remote message queue starting command <code>TURN</code>, {{IETF RFC|1985}}
* <code>HELP</code>&nbsp;– Supply helpful information, {{IETF RFC|821}}
* <code>PIPELINING</code>&nbsp;– Command pipelining, {{IETF RFC|2920}}
* <code>SIZE</code>&nbsp;– Message size declaration, {{IETF RFC|1870}}
* <code>[[Opportunistic TLS|STARTTLS]]</code>&nbsp;– [[Transport Layer Security]], {{IETF RFC|3207}} (2002)
* <code>SMTPUTF8</code>&nbsp;– Allow [[UTF-8]] encoding in mailbox names and header fields, {{IETF RFC|6531}}
* <code>UTF8SMTP</code>&nbsp;– Allow [[UTF-8]] encoding in mailbox names and header fields, {{IETF RFC|5336}} (deprecated<ref>{{cite web|title=SMTP Service Extension Parameters|url=https://www.iana.org/assignments/mail-parameters/mail-parameters.txt|publisher=IANA|access-date=5 November 2013|archive-date=May 28, 2019|archive-url=https://web.archive.org/web/20190528161544/https://www.iana.org/assignments/mail-parameters/mail-parameters.txt|url-status=live}}</ref>)

The ESMTP format was restated in {{IETF RFC|2821}} (superseding RFC 821) and updated to the latest definition in {{IETF RFC|5321}} in 2008. Support for the <code>EHLO</code> command in servers became mandatory, and <code>HELO</code> designated a required fallback.

Non-standard, unregistered, service extensions can be used by bilateral agreement, these services are indicated by an <code>EHLO</code> message keyword starting with "X", and with any additional parameters or verbs similarly marked.

SMTP commands are case-insensitive. They are presented here in capitalized form for emphasis only. An SMTP server that requires a specific capitalization method is a violation of the standard.{{ref RFC|5321}}

====8BITMIME====
At least the following servers advertise the 8BITMIME extension:
* [[Apache James]] (since 2.3.0a1)<ref>[http://james.apache.org/server/2.3.0/changelog.html James Server - ChangeLog] {{Webarchive|url=https://web.archive.org/web/20200220075532/http://james.apache.org/server/2.3.0/changelog.html |date=February 20, 2020 }}. James.apache.org. Retrieved on 2013-07-17.</ref>
* [[Citadel/UX|Citadel]] (since 7.30)
* [[Courier Mail Server]]
* [[Gmail]]<ref>8BITMIME service advertised in response to EHLO on gmail-smtp-in.l.google.com port 25, checked 23 November 2011</ref>
* [[IceWarp]]
* [[Internet Information Services|IIS]] SMTP Service
* [[Kerio Connect]]
* [[Lotus Domino]]
* [[Microsoft Exchange Server]] (as of Exchange Server 2000)
* [[Novell GroupWise]]
* [[OpenSMTPD]]
* [[Oracle Communications Messaging Server]]
* [[Postfix (software)|Postfix]]
* [[Sendmail]] (since 6.57)

The following servers can be configured to advertise 8BITMIME, but do not perform conversion of 8-bit data to 7-bit when connecting to non-8BITMIME relays:
* [[Exim]] and [[qmail]] do not translate eight-bit messages to seven-bit when making an attempt to relay 8-bit data to non-8BITMIME peers, as is required by the RFC.<ref>[https://archive.today/20120630212728/http://home.pages.de/~mandree/qmail-bugs.html Qmail bugs and wishlist]. Home.pages.de. Retrieved on 2013-07-17.</ref> This does not cause problems in practice, since virtually all modern mail relays are [[8-bit clean]].<ref>[http://cr.yp.to/smtp/8bitmime.html The 8BITMIME extension] {{Webarchive|url=https://web.archive.org/web/20110607045931/http://cr.yp.to/smtp/8bitmime.html |date=June 7, 2011 }}. Cr.yp.to. Retrieved on 2013-07-17.</ref>
* [[Microsoft Exchange Server]] 2003 advertises 8BITMIME by default, but relaying to a non-8BITMIME peer results in a bounce. This is allowed by {{IETF RFC|6152}}.<ref>{{cite IETF |rfc=6152|section=3|sectionname=The 8bit-MIMEtransport Service Extension |title=SMTP Service Extension for 8-bit MIME Transport|date=March 2011}}</ref>

====SMTP-AUTH====
{{Main| SMTP Authentication}}
The SMTP-AUTH extension provides an access control mechanism. It consists of an [[authentication]] step through which the client effectively logs into the [[mail transfer agent|mail server]] during the process of sending mail. Servers that support SMTP-AUTH can usually be configured to require clients to use this extension, ensuring the true identity of the sender is known. The SMTP-AUTH extension is defined in {{IETF RFC|4954}}.

SMTP-AUTH can be used to allow legitimate users to relay mail while denying relay service to unauthorized users, such as [[spam (e-mail)|spammers]]. It does not necessarily guarantee the authenticity of either the SMTP [[envelope sender]] or the {{IETF RFC|2822}} "From:" header. For example, [[E-mail spoofing|spoofing]], in which one sender masquerades as someone else, is still possible with SMTP-AUTH unless the server is configured to limit message from-addresses to addresses this AUTHed user is authorized for.

The SMTP-AUTH extension also allows one mail server to indicate to another that the sender has been authenticated when relaying mail. In general this requires the recipient server to trust the sending server, meaning that this aspect of SMTP-AUTH is rarely used on the Internet.{{Citation needed|date=October 2019}}

====SMTPUTF8====
Supporting servers include:
* [[Postfix (software)|Postfix]] (version 3.0 and later)<ref>[http://www.postfix.org/SMTPUTF8_README.html "''Postfix SMTPUTF8 support is enabled by default''"] {{Webarchive|url=https://web.archive.org/web/20200807234345/http://www.postfix.org/SMTPUTF8_README.html |date=August 7, 2020 }}, February 8, 2015, postfix.org</ref>
* Momentum (versions 4.1<ref name="momentum">{{cite press release |title=Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities |url=http://www.prnewswire.com/news-releases/message-systems-introduces-latest-version-of-momentum-with-new-api-driven-capabilities-277568381.html |access-date=September 17, 2020 |archive-date=September 15, 2020 |archive-url=https://web.archive.org/web/20200915234830/https://www.prnewswire.com/news-releases/message-systems-introduces-latest-version-of-momentum-with-new-api-driven-capabilities-277568381.html |url-status=live }}</ref> and 3.6.5, and later)
* [[Sendmail]] (experimental support in 8.17.1)
* [[Exim]] (experimental as of the 4.86 release, quite mature in 4.96)
* [[CommuniGate Pro]] as of version 6.2.2<ref>{{cite web |url=https://communigate.com/Communigatepro/History62.html#6.2.2 |title=Version 6.2 Revision History |website=CommuniGate.com |access-date=September 17, 2020 |archive-date=October 29, 2020 |archive-url=https://web.archive.org/web/20201029221905/https://www.communigate.com/Communigatepro/History62.html#6.2.2 |url-status=live }}</ref>
* [[Courier-MTA]] as of version 1.0<ref>{{cite mailing list |url=https://sourceforge.net/p/courier/mailman/message/36417878/ |title=New releases of Courier packages |date=18 September 2018 |mailing-list=courier-announce |author=Sam Varshavchik |access-date=September 17, 2020 |archive-date=August 17, 2021 |archive-url=https://web.archive.org/web/20210817181032/https://sourceforge.net/p/courier/mailman/message/36417878/ |url-status=live }}</ref>
* Halon as of version 4.0<ref>{{cite web |url=https://github.com/halon/changelog |title=Halon MTA changelog |website=GitHub |date=November 9, 2021 |author= |quote=v4.0: New SMTPUTF8 support |access-date=September 17, 2020 |archive-date=September 18, 2020 |archive-url=https://web.archive.org/web/20200918190844/https://github.com/halon/changelog |url-status=live }} Updated for new versions</ref>
* [[Microsoft Exchange Server]] as of protocol revision 14.0<ref>{{cite web |url=https://interoperability.blob.core.windows.net/files/MS-OXSMTP/%5bMS-OXSMTP%5d-180724.docx |date=24 July 2018 |title=MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions |access-date=September 17, 2020 |archive-date=August 16, 2021 |archive-url=https://web.archive.org/web/20210816051106/https://interoperability.blob.core.windows.net/files/MS-OXSMTP/%5bMS-OXSMTP%5d-180724.docx |url-status=live }}</ref>
* [[Haraka (software)|Haraka]] and other servers.<ref>{{cite web |url=https://uasg.tech/wp-content/uploads/2019/02/UASG021D-EN-EAI-Readiness-in-TLDs.pdf |title=EAI Readiness in TLDs |date=12 February 2019 |access-date=September 17, 2020 |archive-date=January 24, 2021 |archive-url=https://web.archive.org/web/20210124205507/https://uasg.tech/wp-content/uploads/2019/02/UASG021D-EN-EAI-Readiness-in-TLDs.pdf |url-status=live }}</ref>
* [[Oracle Communications Messaging Server]] as of release 8.0.2.<ref>{{cite web |url=https://docs.oracle.com/communications/E72263_01/doc.802/e72267/msvrn.htm#BAJGIBHB |title=Communications Messaging Server Release Notes |date=October 2017 |website=oracle.com |access-date=September 17, 2020 |archive-date=November 24, 2020 |archive-url=https://web.archive.org/web/20201124100920/https://docs.oracle.com/communications/E72263_01/doc.802/e72267/msvrn.htm#BAJGIBHB |url-status=live }}</ref>

===Security extensions===
Mail delivery can occur both over plain text and encrypted connections, however the communicating parties might not know in advance of other party's ability to use secure channel.

====STARTTLS or "Opportunistic TLS"====
{{Main|Opportunistic TLS|Email encryption}}
The STARTTLS extensions enables supporting SMTP servers to notify connecting clients that it supports [[Transport Layer Security|TLS]] encrypted communication and offers the opportunity for clients to upgrade their connection by sending the STARTTLS command. Servers supporting the extension do not inherently gain any security benefits from its implementation on its own, as upgrading to a [[Transport Layer Security|TLS]] encrypted session is dependent on the connecting client deciding to exercise this option, hence the term [[Opportunistic TLS|''opportunistic'' TLS]].

STARTTLS is effective only against passive observation attacks, since the STARTTLS negotiation happens in plain text and an active attacker can trivially remove STARTTLS commands. This type of [[man-in-the-middle attack]] is sometimes referred to as [[STRIPTLS]], where the encryption negotiation information sent from one end never reaches the other. In this scenario both parties take the invalid or unexpected responses as indication that the other does not properly support STARTTLS, defaulting to traditional plain-text mail transfer.<ref name=":0">{{Cite web|url=https://www.hardenize.com/blog/mta-sts|title=Introducing MTA Strict Transport Security (MTA-STS) {{!}} Hardenize Blog|website=www.hardenize.com|access-date=2019-04-25|archive-date=April 25, 2019|archive-url=https://web.archive.org/web/20190425063147/https://www.hardenize.com/blog/mta-sts|url-status=live}}</ref> Note that STARTTLS is also defined for [[Internet Message Access Protocol|IMAP]] and [[Post Office Protocol|POP3]] in other RFCs, but these protocols serve different purposes: SMTP is used for communication between message transfer agents, while IMAP and POP3 are for end clients and message transfer agents.

In 2014 the [[Electronic Frontier Foundation]] began "STARTTLS Everywhere" project that, similarly to "[[HTTPS Everywhere]]" list, allowed relying parties to discover others supporting secure communication without prior communication. The project stopped accepting submissions on 29 April 2021, and EFF recommended switching to [[DNS-based Authentication of Named Entities|DANE]] and MTA-STS for discovering information on peers' TLS support.<ref>{{cite web |title=STARTTLS Everywhere |url=https://starttls-everywhere.org/ |publisher=EFF |access-date=4 December 2021 |language=en |archive-date=August 9, 2019 |archive-url=https://web.archive.org/web/20190809085808/https://www.starttls-everywhere.org/ |url-status=live }}</ref>

{{IETF RFC|8314|}} officially declared plain text obsolete and recommend always using TLS for mail submission and access, adding ports with implicit TLS.

==== DANE for SMTP ====
{{IETF RFC|7672}} introduced the ability for DNS records to declare the encryption capabilities of a mail server. Utilising [[DNSSEC]], mail server operators are able to publish a hash of their TLS certificate, thereby mitigating the possibility of unencrypted communications.<ref>{{Cite web |last=v-mathavale |date=2023-07-21 |title=How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications |url=https://learn.microsoft.com/en-us/purview/how-smtp-dane-works |access-date=2024-03-05 |website=learn.microsoft.com |language=en-us}}</ref>

Microsoft expects to enable full SMTP DANE support for Exchange Online customers by the end of 2024.<ref>{{Cite web |title=Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow |url=https://techcommunity.microsoft.com/t5/exchange-team-blog/implementing-inbound-smtp-dane-with-dnssec-for-exchange-online/ba-p/3939694 |access-date=2024-03-05 |website=techcommunity.microsoft.com |language=en}}</ref> 

====SMTP MTA Strict Transport Security====
A newer 2018 {{IETF RFC|8461|}} called "SMTP MTA Strict Transport Security (MTA-STS)" aims to address the problem of active adversaries by defining a protocol for mail servers to declare their ability to use secure channels in specific files on the server and specific [[Domain Name System|DNS]] TXT records. The relying party would regularly check existence of such record, and cache it for the amount of time specified in the record and never communicate over insecure channels until record expires.<ref name=":0" /> Note that MTA-STS records apply only to SMTP traffic between mail servers while communications between a user's client and the mail server are protected by [[Transport Layer Security]] with SMTP/MSA, IMAP, POP3, or [[HTTPS]]<!-- do we need the protocols here? --> in combination with an organizational or technical policy. Essentially, MTA-STS is a means to extend such a policy to third parties.

In April 2019 [[Google Mail]] announced support for MTA-STS.<ref name=":1">{{Cite web|url=https://www.zdnet.com/article/gmail-becomes-first-major-email-provider-to-support-mta-sts-and-tls-reporting/|title=Gmail becomes first major email provider to support MTA-STS and TLS Reporting|last=Cimpanu|first=Catalin|website=ZDNet|language=en|access-date=2019-04-25|archive-date=April 29, 2019|archive-url=https://web.archive.org/web/20190429022852/https://www.zdnet.com/article/gmail-becomes-first-major-email-provider-to-support-mta-sts-and-tls-reporting/|url-status=live}}</ref>

====SMTP TLS Reporting====
Protocols designed to securely deliver messages can fail due to misconfigurations or deliberate active interference, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. {{IETF RFC|8460|}} "SMTP TLS Reporting" describes a reporting mechanism and format for sharing statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

In April 2019 [[Google Mail]] announced support for SMTP TLS Reporting.<ref name=":1" />