Extended SMTP

From HandWiki
Short description: Computer network protocol

Extended SMTP (ESMTP), sometimes referred to as Enhanced SMTP, is a definition of protocol extensions to the Simple Mail Transfer Protocol (SMTP) standard. ESMTP was defined in November 1995 in IETF publication RFC 1869 which established a general structure for all existing and future extensions.

ESMTP defines consistent and manageable means by which ESMTP clients and servers can be identified and servers can indicate supported extensions.

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 EHLO (Extended HELLO), rather than HELO (Hello, the original 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 HELO or QUIT.

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: SEND, SOML (Send or Mail), SAML (Send and Mail), EXPN, HELP, and TURN. The format of additional SMTP verbs was set and for new parameters in MAIL and RCPT.

Some relatively common keywords (not all of them corresponding to commands) used today are:

  • 8BITMIME – 8 bit data transmission, RFC 6152
  • ATRN – Authenticated TURN for On-Demand Mail Relay, RFC 2645
  • AUTH – Authenticated SMTP, RFC 4954
  • CHUNKING – Chunking, RFC 3030
  • DSN – Delivery status notification, RFC 3461 (See Variable envelope return path)
  • ETRN – Extended version of remote message queue starting command TURN, RFC 1985
  • HELP – Supply helpful information, RFC 821
  • PIPELINING – Command pipelining, RFC 2920
  • SIZE – Message size declaration, RFC 1870
  • STARTTLS – Transport Layer Security, RFC 3207 (2002)
  • SMTPUTF8 – Allow UTF-8 encoding in mailbox names and header fields, RFC 6531
  • UTF8SMTP – Allow UTF-8 encoding in mailbox names and header fields, RFC 5336 (deprecated[1])

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

Non-standard, unregistered, service extensions can be used by bilateral agreement, these services are indicated by an EHLO 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.[citation needed]

List of supporting servers

  • IceWarp
  • Postfix – no patches needed for RFC 6531..RFC 6533.
  • Sendmail – source code patch necessary for SMTPUTF8 support
  • HMailServer – free mail server for Windows
  • Exim
  • MailEnable – support only in Enterprise Edition
  • MagicMail – pipe-lining is intentionally not supported

8BITMIME

List of supporting servers

At least the following servers advertise the 8BITMIME extension:

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.[4] This does not cause problems in practice, since virtually all modern mail relays are 8-bit clean.[5]
  • Microsoft Exchange Server 2003 advertises 8BITMIME by default, but relaying to a non-8BITMIME peer results in a bounce. This is allowed by RFC 6152 section 3.

SMTP-AUTH

Main page: 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 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 RFC 4954.

SMTP-AUTH can be used to allow legitimate users to relay mail while denying relay service to unauthorized users, such as spammers. It does not necessarily guarantee the authenticity of either the SMTP envelope sender or the RFC 2822 "From:" header. For example, 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]

SMTPUTF8

List of supporting servers

List of supporting local servers

Local delivery servers (LMTP)

  • None

List of supporting clients

  • nmh (from version 1.7)

List of supporting content filters

See also

References

  1. ↑ "SMTP Service Extension Parameters". IANA. http://www.iana.org/assignments/mail-parameters/mail-parameters.txt. Retrieved 5 November 2013. 
  2. ↑ James Server - ChangeLog. James.apache.org. Retrieved on 2013-07-17.
  3. ↑ 8BITMIME service advertised in response to EHLO on gmail-smtp-in.l.google.com port 25, checked 23 November 2011
  4. ↑ Qmail bugs and wishlist. Home.pages.de. Retrieved on 2013-07-17.
  5. ↑ The 8BITMIME extension. Cr.yp.to. Retrieved on 2013-07-17.
  6. ↑ "Postfix SMTPUTF8 support is enabled by default", February 8, 2015, postfix.org
  7. ↑ "Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities" (Press release).
  8. ↑ "Version 6.2 Revision History". https://communigate.com/Communigatepro/History62.html#6.2.2. 
  9. ↑ Sam Varshavchik (18 September 2018). "New releases of Courier packages". courier-announce (Mailing list).
  10. ↑ changelog
  11. ↑ "MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions". 24 July 2018. https://interoperability.blob.core.windows.net/files/MS-OXSMTP/%5bMS-OXSMTP%5d-180724.docx. 
  12. ↑ "EAI Readiness in TLDs". 12 February 2019. https://uasg.tech/wp-content/uploads/2019/02/UASG021D-EN-EAI-Readiness-in-TLDs.pdf. 
  13. ↑ "Communications Messaging Server Release Notes". October 2017. https://docs.oracle.com/communications/E72263_01/doc.802/e72267/msvrn.htm#BAJGIBHB. 
  14. ↑ Martinec, Mark. "ANNOUNCE: amavisd-new-2.10.0 has been released". http://lists.amavis.org/pipermail/amavis-users/2014-October/003252.html. Retrieved 1 October 2019. 

External links

  • IANA registry of mail parameters includes service extension keywords
  • RFC 1869 SMTP Service Extensions
  • RFC 5321 Simple Mail Transfer Protocol
  • RFC 4954 – SMTP Service Extension for Authentication (obsoletes RFC 2554)
  • RFC 3848 – SMTP and LMTP Transmission Types Registration (with ESMTPA)
  • RFC 6409 – Message Submission for Mail (obsoletes RFC 4409, which obsoletes RFC 2476)

de:Simple Mail Transfer Protocol#Extended SMTP




Retrieved from "https://handwiki.org/wiki/index.php?title=Extended_SMTP&oldid=96188"