Wikipedia

Simple Mail Transfer Protocol: Difference between revisions

Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
→History: tweaks
Replaced incorrect redirect-distinguish with distinguish
 
(39 intermediate revisions by 21 users not shown)
Line 1:
{{Short description|Internet protocol used for relaying e-mails}}
{{RedirectDistinguish|SMTP|the, email delivery companyInc.|SMTPGSM (company)|03.40{{!}}Short Message Transfer Protocol|GSM 03.40}}
{{Use mdy dates|date=October 2013}}
{{IPstack}}
The '''Simple Mail Transfer Protocol''' ('''SMTP''') is an [[Internet Standard|Internet standard]] [[communication protocol]] for [[email|electronic mail]] transmission. Mail servers and other [[message transfer agent]]s use SMTP to send and receive mail messages. User-level [[email client]]s typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per {{IETF RFC|8314}}. For retrieving messages, [[Internet Message Access Protocol|IMAP]] (which replaced the older [[Post Office Protocol|POP3]]) is standard, but proprietary servers also often implement proprietary protocols, e.g., [[Exchange ActiveSync]].
 
SMTP's origins began in 1980, building on concepts implemented on the [[ARPANET]] since 1971. It has been updated, modified and extended multiple times. The protocol version in common use today has extensible structure with various extensions for [[SMTP Authentication|authentication]], [[Email encryption|encryption]], binary data transfer, and [[International email|internationalized email addresses]]. SMTP servers commonly use the [[Transmission Control Protocol]] on [[port number]] 25 (forbetween plaintextservers) and 587 (for encryptedsubmission communicationsfrom authenticated clients), both with or without encryption.
 
==History==
Line 12:
Various forms of one-to-one [[Instant messaging|electronic messaging]] were used in the 1960s. Users communicated using systems developed for specific [[mainframe computer]]s. As more computers were interconnected, especially in the U.S. Government's [[ARPANET]], standards were developed to permit exchange of messages between different operating systems.
 
Mail on the ARPANET traces its roots to 1971: the Mail Box Protocol, which was not implemented,<ref>[http://www.multicians.org/thvv/mail-history.html The History of Electronic Mail] {{Webarchive|url=https://web.archive.org/web/20171202025034/http://www.multicians.org/thvv/mail-history.html |date=December 2, 2017 }}'', [[Tom Van Vleck]]: "''It is not clear this protocol was ever implemented''"''</ref> but is discussed in {{IETF RFC|196}}; and the [[SNDMSG]] program, which [[Ray Tomlinson]] of [[BBN Technologies|BBN]] adapted that year to send messages across two computers on the ARPANET.<ref>[//openmap.bbn.com/~tomlinso/ray/firstemailframe.html ''The First Network Email''], [[Ray Tomlinson]], BBN</ref><ref>Picture of "[//openmap.bbnkingsmtp.com/~tomlinsothe-first-email-computer/ray/ka10.html The First Email Computer]" by Dan Murphy, a [[PDP-10]]</ref><ref>[http://www.opost.com/dlm/tenex/ Dan Murphy's TENEX and TOPS-20 Papers] {{webarchive |url=https://web.archive.org/web/20071118204016/http://www.opost.com/dlm/tenex/ |date=November 18, 2007 }}</ref> A further proposal for a Mail Protocol was made in RFC 524 in June 1973,<ref>{{IETF RFC|524}} – A Proposed Mail Protocol</ref> which was not implemented.<ref>{{Cite journal |last=Crocker |first=David H. |date=December 1977 |title=Framework and Functions of the "MS" Personal Message System |url=https://www.rand.org/content/dam/rand/pubs/reports/2007/R2134.pdf |journal=The RAND Corporation |access-date=April 17, 2022 |archive-date=May 13, 2022 |archive-url=https://web.archive.org/web/20220513083616/https://www.rand.org/content/dam/rand/pubs/reports/2007/R2134.pdf |url-status=live }}</ref>
 
The use of the [[File Transfer Protocol]] (FTP) for "network mail" on the ARPANET was proposed in RFC 469 in March 1973.<ref>{{IETF RFC|469}} – Network Mail Meeting Summary</ref> Through RFC 561, RFC 680, RFC 724, and finally RFC 733 in November 1977, a standardized framework for "electronic mail" using FTP mail servers on was developed.<ref name=":12">RFC 733, 21 November 1977, Standard for the Format of ARPA Network Text Message</ref><ref>{{Cite news |date=2023-05-20 |title=A history of e-mail: Collaboration, innovation and the birth of a system |url=https://www.washingtonpost.com/national/on-innovations/a-history-of-e-mail-collaboration-innovation-and-the-birth-of-a-system/2012/03/19/gIQAOeFEPS_story.html |access-date=2024-07-07 |work=Washington Post |language=en-US |issn=0190-8286}}</ref>
 
SMTP grew out of these standards developed during the 1970s. Ray Tomlinson discussed network mail among the [[International Network Working Group]] in ''INWG Protocol note 2'', written in September 1974.<ref name=":03">{{Cite journal |last=McKenzie |first=Alexander |date=2011 |title=INWG and the Conception of the Internet: An Eyewitness Account |journal=IEEE Annals of the History of Computing |volume=33 |issue=1 |pages=66–71 |doi=10.1109/MAHC.2011.9 |issn=1934-1547 |s2cid=206443072}}</ref> INWG discussed protocols for electronic mail in 1979,<ref>Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979.</ref> which was referenced by [[Jon Postel]] in his early work on Internet email. Postel first proposed an Internet Message Protocol in 1979 as part of the [[Internet Experiment Note]] (IEN) series.<ref>{{Cite IETF|ien=85}}</ref><ref>{{Cite IETF|ien=113}}</ref><ref>{{Cite web |title=Internet Experiment Note Index |url=https://www.rfc-editor.org/ien/ien-index.html |access-date=2024-07-07 |website=www.rfc-editor.org}}</ref>
SMTP grew out of these standards developed during the 1970s.
 
=== Original SMTP ===
In 1980, [[Jon Postel]] and Suzanne Sluizer published {{IETF RFC|772}} which proposed the Mail Transfer Protocol as a replacement for the use of the FTP for mail. {{IETF RFC|780}} of May 1981 removed all references to FTP and allocated port 57 for [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]],{{Citation needed|date=March 2021}} an allocation that has since been removed by [[Internet Assigned Numbers Authority|IANA]]. In November 1981, Postel published {{IETF RFC|788}} "Simple Mail Transfer Protocol".
 
The SMTP standard was developed around the same time as [[Usenet]], a one-to-many communication network with some similarities.{{cn|date=April 2021}}
Line 32:
In November 1995, {{IETF RFC|1869}} defined Extended Simple Mail Transfer Protocol (ESMTP), which established a general structure for all existing and future extensions which aimed to add-in the features missing from the original SMTP. ESMTP defines consistent and manageable means by which ESMTP clients and servers can be identified and servers can indicate supported extensions.
 
Message submission ({{IETF RFC|2476}}) and [[SMTP Authentication|SMTP-AUTH]] ({{IETF RFC|2554}}) were introduced in 1998 and 1999, both describing new trends in email delivery. Originally, SMTP servers were typically internal to an organization, receiving mail for the organization ''from the outside'', and relaying messages from the organization ''to the outside''. But as time went on, SMTP servers (mail transfer agents), in practice, were expanding their roles to become [[Mail submission agent|message submission agents]] for [[Email client|Mailmail user agents]], some of which were now relaying mail ''from the outside'' of an organization. (e.g. a company executive wishes to send email while on a trip using the corporate SMTP server.) This issue, a consequence of the rapid expansion and popularity of the [[World Wide Web]], meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email ([[Email spam|spam]]). Work on message submission ({{IETF RFC|2476}}) was originally started because popular mail servers would often rewrite mail in an attempt to fix problems in it, for example, adding a domain name to an unqualified address. This behavior is helpful when the message being fixed is an initial submission, but dangerous and harmful when the message originated elsewhere and is being relayed. Cleanly separating mail into submission and relay was seen as a way to permit and encourage rewriting submissions while prohibiting rewriting relay. As spam became more prevalent, it was also seen as a way to provide authorization for mail being sent out from an organization, as well as traceability. This separation of relay and submission quickly became a foundation for modern email security practices.
 
As this protocol started out purely [[ASCII]] text-based, it did not deal well with binary files, or characters in many non-English languages. Standards such as Multipurpose Internet Mail Extensions ([[MIME]]) were developed to encode binary files for transfer through SMTP. Mail transfer agents (MTAs) developed after [[Sendmail]] also tended to be implemented [[8-bit clean]], so that the alternate "just send eight" strategy could be used to transmit arbitrary text data (in any 8-bit ASCII-like character encoding) via SMTP. [[Mojibake]] was still a problem due to differing character set mappings between vendors, although the email addresses themselves still allowed only [[ASCII]]. 8-bit-clean MTAs today tend to support the 8BITMIME extension, permitting some binary files to be transmitted almost as easily as plain text (limits on line length and permitted octet values still apply, so that MIME encoding is needed for most non-text data and some text formats). In 2012, the <code>SMTPUTF8</code> extension was created to support [[UTF-8]] text, allowing international content and addresses in non-[[Latin script|Latin]] scripts like [[Cyrillic script|Cyrillic]] or [[Chinese characters|Chinese]].
Line 41:
[[Image:SMTP-transfer-model.svg|thumb|300px|Blue arrows depict implementation of SMTP variations]]
 
Email is submitted by a mail client ([[mail user agent]], MUA) to a mail server ([[mail submission agent]], MSA) using SMTP on [[Transmission Control Protocol|TCP]] port 587. Most [[Mailbox Provider|mailbox providers]] still allow submission on traditional port 25. The MSA delivers the mail to its mail transfer agent ([[mail transfer agent]], (MTA). Often, these two agents are instances of the same software launched with different options on the same machine. Local processing can be done either on a single machine, or split among multiple machines; mail agent processes on one machine can share files, but if processing is on multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a [[smart host]]. Each process is an MTA (an SMTP server) in its own right.
 
The boundary MTA uses [[Domain name system|DNS]] to look up the [[MX record|MX (mail exchanger) record]] for the recipient's domain (the part of the [[email address]] on the right of <code>@</code>). The MX record contains the name of the target MTA. Based on the target host and other factors, the sending MTA selects a recipient server and connects to it to complete the mail exchange.
Line 67:
 
===SMTP vs mail retrieval===
SMTP is a delivery protocol only. In normal use, mail is "pushed" to a destination mail server (or next-hop mail server) as it arrives. Mail is routed based on the destination server, not the individual user(s) to which it is addressed. Other protocols, such as the [[Post Office Protocol]] (POP) and the [[Internet Message Access Protocol]] (IMAP) are specifically designed for use by individual users retrieving messages and managing [[email mailbox|mail boxesmailboxes]]. To permit an intermittently-connected mail server to ''pull'' messages from a remote server on demand, SMTP has a feature to initiate mail queue processing on a remote server (see [[#Remote Message Queue Starting|Remote Message Queue Starting]] below). POP and IMAP are unsuitable protocols for relaying mail by intermittently-connected machines; they are designed to operate after final delivery, when information critical to the correct operation of mail relay (the "mail envelope") has been removed.
 
===Remote Message Queue Starting===
Line 110:
After the message sender (SMTP client) establishes a reliable communications channel to the message receiver (SMTP server), the session is opened with a greeting by the server, usually containing its [[fully qualified domain name]] (FQDN), in this case ''smtp.example.com''. The client initiates its dialog by responding with a <code>HELO</code> command identifying itself in the command's parameter with its FQDN (or an address literal if none is available).<ref name="rfc5321">{{IETF RFC|5321}}, ''Simple Mail Transfer Protocol'', J. Klensin, The Internet Society (October 2008)</ref>
 
<span style="color: bluegray">S:</span> <span style="color: blue">220 smtp.example.com ESMTP Postfix</span>
<span style="color: gray">C:</span> HELO relay.example.org
<span style="color: bluegray">S:</span> <span style="color: blue">250 Hello relay.example.org, I am glad to meet you</span>
<span style="color: gray">C:</span> MAIL FROM:<bob@example.org>
<span style="color: bluegray">S:</span> <span style="color: blue">250 Ok</span>
<span style="color: gray">C:</span> RCPT TO:<alice@example.com>
<span style="color: bluegray">S:</span> <span style="color: blue">250 Ok</span>
<span style="color: gray">C:</span> RCPT TO:<theboss@example.com>
<span style="color: bluegray">S:</span> <span style="color: blue">250 Ok</span>
<span style="color: gray">C:</span> DATA
C: DATA
<span style="color: bluegray">S:</span> <span style="color: blue">354 End data with <CR><LF>.<CR><LF></span>
<span style="color: gray">C:</span> {{codett|2=email|From: "Bob Example" <bob@example.org>}}
<span style="color: gray">C:</span> {{codett|2=email|To: "Alice Example" <alice@example.com>}}
<span style="color: gray">C:</span> {{codett|2=email|Cc: theboss@example.com}}
<span style="color: gray">C:</span> {{codett|2=email|Date: Tue, 15 Jan 2008 16:02:43 -0500}}
<span style="color: gray">C:</span> {{codett|2=email|Subject: Test message}}
<span style="color: gray">C:</span>
C:
<span style="color: gray">C:</span> Hello Alice.
<span style="color: gray">C:</span> This is a test message with 5 header fields and 4 lines in the message body.
<span style="color: gray">C:</span> Your friend,
<span style="color: gray">C:</span> Bob
C: Bob
<span style="color: gray">C:</span> .
C: .
<span style="color: bluegray">S:</span> <span style="color: blue">250 Ok: queued as 12345</span>
<span style="color: gray">C:</span> QUIT
C: QUIT
<span style="color: bluegray">S:</span> <span style="color: blue">221 Bye</span>
<span style="color: gray">{The server closes the connection}</span>
 
The client notifies the receiver of the originating email address of the message in a <code>MAIL FROM</code> command. This is also the return or [[bounce address]] in case the message cannot be delivered. In this example the email message is sent to two mailboxes on the same SMTP server: one for each recipient listed in the <code>To:</code> and <code>Cc:</code> header fields. The corresponding SMTP command is <code>RCPT TO</code>. Each successful reception and execution of a command is acknowledged by the server with a [[List of SMTP server return codes|result code and response message]] (e.g., <code>250 Ok</code>).
Line 141:
The transmission of the body of the mail message is initiated with a <code>DATA</code> command after which it is transmitted verbatim line by line and is terminated with an end-of-data sequence. This sequence consists of a new-line (<code><CR><LF></code>), a single [[full stop]] (<code>.</code>), followed by another new-line (<code><CR><LF></code>). Since a message body can contain a line with just a period as part of the text, the client sends ''two'' periods every time a line starts with a period; correspondingly, the server replaces every sequence of two periods at the beginning of a line with a single one. Such escaping method is called ''dot-stuffing''.
 
The server's positive reply to the end-of-data, as exemplified, implies that the server has taken the responsibility of delivering the message. A message can be doubled if there is a communication failure at this time, e.g. due to a power shortageoutage: Until the sender has received that <code>250 Ok</code> reply, it must assume the message was not delivered. On the other hand, after the receiver has decided to accept the message, it must assume the message has been delivered to it. Thus, during this time span, both agents have active copies of the message that they will try to deliver.<ref>{{IETF RFC|1047}}</ref> The probability that a communication failure occurs exactly at this step is directly proportional to the amount of filtering that the server performs on the message body, most often for anti-spam purposes. The limiting timeout is specified to be 10 minutes.<ref>{{cite web| url = https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6| title = rfc5321#section-4.5.3.2.6| date = October 2008| access-date = June 7, 2010| archive-date = January 16, 2015| archive-url = https://web.archive.org/web/20150116021100/http://tools.ietf.org/html/rfc5321#section-4.5.3.2.6| url-status = live| last1 = Klensin| first1 = John C.}}</ref>
 
The <code>QUIT</code> command ends the session. If the email has other recipients located elsewhere, the client would <code>QUIT</code> and connect to an appropriate SMTP server for subsequent recipients after the current destination(s) had been queued. The information that the client sends in the <code>HELO</code> and <code>MAIL FROM</code> commands are added (not seen in example code) as additional header fields to the message by the receiving server. It adds a <code>Received</code> and <code>Return-Path</code> header field, respectively.
Line 154:
 
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: bluegray">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: bluegray">S:</span> <span style="color: blue">250-smtp2.example.com Hello bob.example.org [192.0.2.201]</span>
<span style="color: bluegray">S:</span> <span style="color: blue">250-SIZE 14680064</span>
<span style="color: bluegray">S:</span> <span style="color: blue">250-PIPELINING</span>
<span style="color: bluegray">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).
 
Line 207:
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>{{citationCite report |url=https://datatracker.ietf.org/doc/rfc5321/ |title=Simple Mail Transfer Protocol |last=Klensin |first=John C. needed|date=October 20192008 |publisher=Internet Engineering Task Force |issue=RFC 5321}}</ref>
 
====8BITMIME====
Line 246:
* [[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 (software)|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>
Line 263:
 
{{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 adversaryadversaries 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>
Line 284 ⟶ 289:
==Implementations==
{{Main|List of mail server software|Comparison of mail servers}}
 
==Related requests for comments==
* {{IETF RFC|1123}} – Requirements for Internet Hosts—Application and Support (STD 3)▼
* {{IETF RFC|1870}} – SMTP Service Extension for Message Size Declaration (оbsoletes: {{IETF RFC|1653}})▼
* {{IETF RFC|2505}} – Anti-Spam Recommendations for SMTP MTAs (BCP 30)▼
* {{IETF RFC|2821}} – Simple Mail Transfer Protocol▼
* {{IETF RFC|2920}} – SMTP Service Extension for Command Pipelining (STD 60)▼
* {{IETF RFC|3030}} – SMTP Service Extensions for Transmission of Large and Binary MIME Messages▼
* {{IETF RFC|3207}} – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes {{IETF RFC|2487}})▼
* {{IETF RFC|3461}} – SMTP Service Extension for Delivery Status Notifications (obsoletes {{IETF RFC|1891}})▼
* {{IETF RFC|3463}} – Enhanced Status Codes for SMTP (obsoletes {{IETF RFC|1893}}, updated by {{IETF RFC|5248}})▼
* {{IETF RFC|3464}} – An Extensible Message Format for Delivery Status Notifications (obsoletes {{IETF RFC|1894}})▼
* {{IETF RFC|3798}} – Message Disposition Notification (updates {{IETF RFC|3461}})▼
* {{IETF RFC|3834}} – Recommendations for Automatic Responses to Electronic Mail▼
* {{IETF RFC|3974}} – SMTP Operational Experience in Mixed IPv4/v6 Environments▼
* {{IETF RFC|4952}} – Overview and Framework for Internationalized Email (updated by {{IETF RFC|5336}})▼
* {{IETF RFC|4954}} – SMTP Service Extension for Authentication (obsoletes {{IETF RFC|2554}}, updates {{IETF RFC|3463}}, updated by {{IETF RFC|5248}})▼
* {{IETF RFC|5068}} – Email Submission Operations: Access and Accountability Requirements (BCP 134)▼
* {{IETF RFC|5248}} – A Registry for SMTP Enhanced Mail System Status Codes (BCP 138) (updates {{IETF RFC|3463}})▼
* {{IETF RFC|5321}} – The Simple Mail Transfer Protocol (obsoletes {{IETF RFC|821}} aka STD 10, {{IETF RFC|974}}, {{IETF RFC|1869}}, {{IETF RFC|2821}}, updates {{IETF RFC|1123}})▼
* {{IETF RFC|5322}} – Internet Message Format (obsoletes {{IETF RFC|822}} aka STD 11, and {{IETF RFC|2822}})▼
* {{IETF RFC|5504}} – Downgrading Mechanism for Email Address Internationalization▼
* {{IETF RFC|6409}} – Message Submission for Mail (STD 72) (obsoletes {{IETF RFC|4409}}, {{IETF RFC|2476}})▼
* {{IETF RFC|6522}} – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes {{IETF RFC|3462}}, and in turn {{IETF RFC|1892}})▼
* {{IETF RFC|6531}} – SMTP Extension for Internationalized Email Addresses (updates {{IETF RFC|2821}}, {{IETF RFC|2822}}, {{IETF RFC|4952}}, and {{IETF RFC|5336}})▼
*{{IETF RFC|8314|}} – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access▼
 
==See also==
Line 338 ⟶ 317:
* {{cite book | last=Rhoton | first=J | title=Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP | publisher=Elsevier | year=1999 | isbn=978-1-55558-212-8}}
* {{cite book | last=Wood | first=D | title=Programming Internet Mail | publisher=O'Reilly | year=1999 | isbn=978-1-56592-479-6 | url-access=registration | url=https://archive.org/details/livesofcaptivere00petz }}
 
==Further reading==
▲* {{IETF RFC|1123}} – Requirements for Internet Hosts—Application and Support (STD 3)
▲* {{IETF RFC|1870}} – SMTP Service Extension for Message Size Declaration (оbsoletes: {{IETF RFC|1653}})
▲* {{IETF RFC|2505}} – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
▲* {{IETF RFC|2821}} – Simple Mail Transfer Protocol
▲* {{IETF RFC|2920}} – SMTP Service Extension for Command Pipelining (STD 60)
▲* {{IETF RFC|3030}} – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
▲* {{IETF RFC|3207}} – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes {{IETF RFC|2487}})
▲* {{IETF RFC|3461}} – SMTP Service Extension for Delivery Status Notifications (obsoletes {{IETF RFC|1891}})
▲* {{IETF RFC|3463}} – Enhanced Status Codes for SMTP (obsoletes {{IETF RFC|1893}}, updated by {{IETF RFC|5248}})
▲* {{IETF RFC|3464}} – An Extensible Message Format for Delivery Status Notifications (obsoletes {{IETF RFC|1894}})
▲* {{IETF RFC|3798}} – Message Disposition Notification (updates {{IETF RFC|3461}})
▲* {{IETF RFC|3834}} – Recommendations for Automatic Responses to Electronic Mail
▲* {{IETF RFC|3974}} – SMTP Operational Experience in Mixed IPv4/v6 Environments
▲* {{IETF RFC|4952}} – Overview and Framework for Internationalized Email (updated by {{IETF RFC|5336}})
▲* {{IETF RFC|4954}} – SMTP Service Extension for Authentication (obsoletes {{IETF RFC|2554}}, updates {{IETF RFC|3463}}, updated by {{IETF RFC|5248}})
▲* {{IETF RFC|5068}} – Email Submission Operations: Access and Accountability Requirements (BCP 134)
▲* {{IETF RFC|5248}} – A Registry for SMTP Enhanced Mail System Status Codes (BCP 138) (updates {{IETF RFC|3463}})
▲* {{IETF RFC|5321}} – The Simple Mail Transfer Protocol (obsoletes {{IETF RFC|821}} aka STD 10, {{IETF RFC|974}}, {{IETF RFC|1869}}, {{IETF RFC|2821}}, updates {{IETF RFC|1123}})
▲* {{IETF RFC|5322}} – Internet Message Format (obsoletes {{IETF RFC|822}} aka STD 11, and {{IETF RFC|2822}})
▲* {{IETF RFC|5504}} – Downgrading Mechanism for Email Address Internationalization
▲* {{IETF RFC|6409}} – Message Submission for Mail (STD 72) (obsoletes {{IETF RFC|4409}}, {{IETF RFC|2476}})
▲* {{IETF RFC|6522}} – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes {{IETF RFC|3462}}, and in turn {{IETF RFC|1892}})
▲* {{IETF RFC|6531}} – SMTP Extension for Internationalized Email Addresses (updates {{IETF RFC|2821}}, {{IETF RFC|2822}}, {{IETF RFC|4952}}, and {{IETF RFC|5336}})
▲*{{IETF RFC|8314|}} – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
 
==External links==
Retrieved from "https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol"