Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Simple Mail Transfer Protocol
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===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> β 8 bit data transmission, {{IETF RFC|6152}} * <code>ATRN</code> β Authenticated <code>TURN</code> for [[On-Demand Mail Relay]], {{IETF RFC|2645}} * <code>AUTH</code> β Authenticated SMTP, {{IETF RFC|4954}} * <code>CHUNKING</code> β Chunking, {{IETF RFC|3030}} * <code>DSN</code> β Delivery status notification, {{IETF RFC|3461}} (See [[Variable envelope return path]]) * <code>ETRN</code> β Extended version of remote message queue starting command <code>TURN</code>, {{IETF RFC|1985}} * <code>HELP</code> β Supply helpful information, {{IETF RFC|821}} * <code>PIPELINING</code> β Command pipelining, {{IETF RFC|2920}} * <code>SIZE</code> β Message size declaration, {{IETF RFC|1870}} * <code>[[Opportunistic TLS|STARTTLS]]</code> β [[Transport Layer Security]], {{IETF RFC|3207}} (2002) * <code>SMTPUTF8</code> β Allow [[UTF-8]] encoding in mailbox names and header fields, {{IETF RFC|6531}} * <code>UTF8SMTP</code> β 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>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)