Editing Simple Mail Transfer Protocol (section)

===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" />