# SMTP Authentication

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/SMTP_Authentication
> Markdown URL: https://mediated.wiki/source/SMTP_Authentication.md
> Source: https://en.wikipedia.org/wiki/SMTP_Authentication
> Source revision: 1319175844
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

{{Short description|Extension of Internet protocol}}
'''SMTP Authentication''', often abbreviated '''SMTP AUTH''', is an extension of the [Simple Mail Transfer Protocol](/source/Simple_Mail_Transfer_Protocol) (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by [submission](/source/Mail_submission_agent) servers, where authentication is mandatory.<ref>The relevant RFCs for reference are specified in the #Standards section</ref>

==History==
SMTP as specified by [Jon Postel](/source/Jon_Postel) in the 1970s did not provide for using passwords for sending email messages; each server was by design an [open mail relay](/source/open_mail_relay). As a result, [spam](/source/Spam_(electronic)) and [worms](/source/Computer_worm), while not initially a problem, had become a plague by the late '90s.<ref>{{cite web |url=http://www.kb.indiana.edu/data/aivh.html |title=In Unix, what is an open mail relay? |accessdate=2008-04-07 |last=The Trustees of Indiana University |date=2008-04-01 |work=University Information Technology Services |publisher=[Indiana University](/source/Indiana_University) |archiveurl=https://web.archive.org/web/20070617083024/http://kb.iu.edu/data/aivh.html |archivedate=2007-06-17 |url-status=dead }}</ref> Before SMTP AUTH, a ''relay client'' had to be identified by [IP address](/source/IP_address), which is only practical for email services provided by the same [Internet service provider](/source/Internet_service_provider) (ISP) supplying the connection, or else using specific hacks, such as [POP before SMTP](/source/POP_before_SMTP).

John Gardiner Myers published the first draft of SMTP AUTH in 1995,<ref>{{cite web |url=http://tools.ietf.org/html/draft-myers-smtp-auth-00 |title=SMTP Service Extension for Authentication |author=John Gardiner Myers |date=April 1995 |publisher=[IETF](/source/IETF) |accessdate=2010-05-30}}</ref> and it has been successively developed and discussed in the [IETF](/source/IETF) along with mail submission protocol, Extended SMTP (ESMTP), and [Simple Authentication and Security Layer](/source/Simple_Authentication_and_Security_Layer) (SASL). An older SASL mechanism for ESMTP authentication (ESMTPA) is [CRAM-MD5](/source/CRAM-MD5), and uses of the [MD5](/source/MD5) algorithm in [HMAC](/source/HMAC)s (hash-based message authentication codes) are still considered sound.<ref>{{cite ietf
|rfc= 6151
|title= Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms
|author= Sean Turner, Lily Chen 
|publisher=[IETF](/source/IETF)
|date=March 2011}}</ref>

The [Internet Mail Consortium](/source/Internet_Mail_Consortium) (IMC) reported that 55% of mail servers were open relays in 1998,<ref>{{cite web |url=http://www.imc.org/imcr-006.html |title=Allowing Relaying in SMTP: A Survey |author=Paul Hoffman |date=February 1, 1998 |publisher=[Internet Mail Consortium](/source/Internet_Mail_Consortium) |accessdate=2010-05-30 |archive-date=2016-03-05 |archive-url=https://web.archive.org/web/20160305105916/https://www.imc.org/imcr-006.html |url-status=dead }}</ref> but less than 1% in 2002.<ref>{{cite web |url=http://www.imc.org/ube-relay.html |title=Allowing Relaying in SMTP: A Series of Surveys |author=Paul Hoffman |date=August 2002 |publisher=[Internet Mail Consortium](/source/Internet_Mail_Consortium) |accessdate=2010-05-30 |url-status=dead |archiveurl=https://web.archive.org/web/20070118121843/http://www.imc.org/ube-relay.html |archivedate=2007-01-18 }}</ref>

==Role in the mail transport system==
Using a [mail submission agent](/source/mail_submission_agent) (MSA), generally on port 587, implies SMTP AUTH. MSA usage is supported by most software<ref>{{cite web |url=https://www6.ietf.org/iesg/implementation/report-rfc2476.txt |title=Message Submission Interoperability Report |author=Randall Gellens |date=January 19, 2005 |publisher=[IETF](/source/IETF) |accessdate=2019-07-05}}</ref> and is recommended, especially to support nomadic users, as several network hubs either block port 25 or use [SMTP proxies](/source/SMTP_proxy). The MSA is responsible for ensuring that the message envelope contains good addresses, and may enforce local policies for the ''<code>From</code>'' header field. Verifying that the [envelope sender](/source/envelope_sender) (a.k.a. ''<code>Return-Path</code>'') used for [SPF](/source/Sender_Policy_Framework) and the ''From'' address agree with the authenticated ''user-id'' is particularly important for domains that sign messages using [DKIM](/source/DomainKeys_Identified_Mail).

Keywords ending in "A" such as <code>ESMTPA</code> and <code>ESMTPSA</code>, are provided for the ''<code>with</code>'' clause of ''<code>Received</code>'' header fields, when messages are received with SMTP AUTH.<ref>{{cite web
|url=https://www.iana.org/assignments/mail-parameters
|title=Mail parameters
|work=[IANA](/source/Internet_Assigned_Numbers_Authority) registry
|accessdate=2011-07-23}}</ref> ''"The keywords are provided for statistical or diagnostic purposes"'' (RFC 3848); they are checked by some clients, e.g. [Spamassassin](/source/Spamassassin).

==Details==
As with all SMTP extensions, SMTP AUTH is advertised in the EHLO response, along with a list of supported authentication methods. These methods may change after issuing [STARTTLS](/source/Opportunistic_TLS), typically allowing plain text passwords in the latter case only. RFC 4954 provides the following example ("C:" and "S:" are not part of the protocol, they indicate lines sent by the client and server, respectively):

 S: 220 smtp.example.com ESMTP Server
 C: EHLO client.example.com
 S: 250-smtp.example.com Hello client.example.com
 '''S: 250-AUTH GSSAPI DIGEST-MD5'''
 S: 250-ENHANCEDSTATUSCODES
 S: 250 STARTTLS
 C: STARTTLS
 S: 220 Ready to start TLS
     ''... TLS negotiation proceeds.'' 
      ''Further commands protected by TLS layer ...''
 C: EHLO client.example.com
 S: 250-smtp.example.com Hello client.example.com
 '''S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN'''
 '''C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE='''
 S: 235 2.7.0 Authentication successful

SMTP AUTH can be used also on port 25. Usually, servers reject RCPT TO commands that imply relaying unless authentication credentials have been accepted. The specification recommends that servers issue ''530 5.7.0  Authentication required'' in response to most commands in case the server is configured to ''require'' authentication and the client hasn't done it yet. Only servers listening on port 587, or private servers, should be configured that way, not a Message eXchange (MX). However, the historical trait that SMTP is not authenticated by default results in a different behavior with regard to access protocols, in some cases; for example, when using AUTH EXTERNAL after STARTTLS.<ref>{{cite web |url=http://www.ietf.org/mail-archive/web/yam/current/msg00420.html |title=Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL |author=Chris Newman |date=30 Apr 2010 |publisher=[IETF](/source/IETF) |accessdate=2010-05-30}}</ref>

Besides the ''AUTH'' command, the extension also provides for an ''AUTH'' parameter to the ''MAIL FROM'' command, so as to allow to distinguish authentication from authorization. That way, a sender can identify itself and transmit several messages during the same session. While the authentication doesn't need to vary, once established, different messages may be sent according to different agreements and hence require different authorization. For example, messages may be relayed on behalf of different users. Use of this parameter is much less popular than using the command to grant relay privileges.

SMTP Authentication is an "extension" in SMTP terms, so it requires server and client to use EHLO verb for greeting to indicate support for extensions, as opposed to the obsolete HELO greeting.<ref>{{cite ietf |rfc=5321 |title=Simple Mail Transfer Protocol |section=2.2.1|quote=However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.}}</ref> For backward compatibility, HELO greeting may be accepted ''when no extension is used''.

The capitalized text after the ''AUTH'' command is a list of the types of authorization that the SMTP server will accept.

Some examples of authorization protocols include:

*PLAIN (Uses Base64 encoding)
*LOGIN (Uses Base64 encoding)<ref>K. Murchison and M. Crispin, [https://www.ietf.org/archive/id/draft-murchison-sasl-login-00.txt The LOGIN SASL Mechanism], 28 August 2003, expired draft.  LOGIN is described as obsolete in the [https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml SASL Mechanisms] document but the mechanism is still in use.</ref> (obsoleted in favor of PLAIN)
*GSSAPI ([Generic Security Services Application Program Interface](/source/Generic_Security_Services_Application_Program_Interface))
*DIGEST-MD5 ([Digest access authentication](/source/Digest_access_authentication))
*[MD5](/source/MD5)
*[CRAM-MD5](/source/CRAM-MD5)
*OAUTH10A ([OAuth](/source/OAuth) 1.0a HMAC-SHA1 tokens as defined in RFC 5849)
*OAUTHBEARER ([OAuth](/source/OAuth) 2.0 bearer tokens as defined in RFC 6750)
* XOAUTH2 <ref>[https://developers.google.com/gmail/imap/xoauth2-protocol#using_oauth_20 Gmail's XOAuth2 SASL protocol]</ref>

==Standards==
*{{IETF RFC|3207|link=no}}, ''SMTP Service Extension for Secure SMTP over Transport Layer Security'', Paul Hoffman, February 2002.
*{{IETF RFC|3848|link=no}}, ''ESMTP and LMTP Transmission Types Registration'', Chris Newman, July 2004.
*{{IETF RFC|6409|link=no}}, ''Message Submission for Mail'', Randall Gellens and [John C. Klensin](/source/John_Klensin), November 2011 (obsoletes RFC 4409, from 2006, which in turn replaced RFC 2476, from December 1998).
*{{IETF RFC|4422|link=no}}, ''Simple Authentication and Security Layer (SASL)'', Alexey Melnikov and Kurt D. Zeilenga, June 2006.
*{{IETF RFC|4616|link=no}}, ''The PLAIN SASL Mechanism'', K. Zeilenga, Ed., August 2006.
*{{IETF RFC|4954|link=no}}, ''SMTP Service Extension for Authentication'', Robert Siemborski and Alexey Melnikov, July 2007.
*{{IETF RFC|7628|link=no}}, ''A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth'', W. Mills, T. Showalter and H. Tschofenig, August 2015.

== Other ==
* Erwin Hoffmann, [https://www.fehcom.de/qmail/smtpauth.html SMTP Authentication &#91;Tutorial&#93;], last edit 2017-01-10.

==See also==
*[E-mail authentication](/source/E-mail_authentication)
*[Simple Mail Transfer Protocol](/source/Simple_Mail_Transfer_Protocol)
*[Mail submission agent](/source/Mail_submission_agent)
*[Email client port numbers](/source/Email_client)
*[Simple Authentication and Security Layer](/source/Simple_Authentication_and_Security_Layer)
*[Open mail relay](/source/Open_mail_relay)
*[POP before SMTP](/source/POP_before_SMTP)

==References==
{{reflist|2}}

Category:Email authentication
Category:Internet mail protocols
Category:Computer access control protocols

---
Adapted from the Wikipedia article [SMTP Authentication](https://en.wikipedia.org/wiki/SMTP_Authentication) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/SMTP_Authentication?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.