SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the 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 servers, where authentication is mandatory.[1]
SMTP as specified by Jon Postel in the 1970s did not provide for using passwords for sending email messages; each server was by design an open mail relay. As a result, spam and worms, while not initially a problem, had become a plague by the late '90s.[2] Before SMTP AUTH, a relay client had to be identified by IP address, which is only practical for email services provided by the same Internet service provider (ISP) supplying the connection, or else using specific hacks, such as POP before SMTP.
John Gardiner Myers published the first draft of SMTP AUTH in 1995,[3] and it has been successively developed and discussed in the IETF along with mail submission protocol, Extended SMTP (ESMTP), and Simple Authentication and Security Layer (SASL). An older SASL mechanism for ESMTP authentication (ESMTPA) is CRAM-MD5, and uses of the MD5 algorithm in HMACs (hash-based message authentication codes) are still considered sound.[4]
The Internet Mail Consortium (IMC) reported that 55% of mail servers were open relays in 1998,[5] but less than 1% in 2002.[6]
Role in the mail transport systemEdit
Using a mail submission agent (MSA), generally on port 587, implies SMTP AUTH. MSA usage is supported by most software[7] and is recommended, especially to support nomadic users, as several network hubs either block port 25 or use SMTP proxies. The MSA is responsible for ensuring that the message envelope contains good addresses, and may enforce local policies for the From header field. Verifying that the envelope sender (a.k.a. Return-Path) used for SPF and the From address agree with the authenticated user-id is particularly important for domains that sign messages using DKIM.
Keywords ending in "A" such as ESMTPA and ESMTPSA, are provided for the with clause of Received header fields, when messages are received with SMTP AUTH.[8]"The keywords are provided for statistical or diagnostic purposes" (RFC 3848); they are checked by some clients, e.g. Spamassassin.
DetailsEdit
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, 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):
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.[9]
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.[10] 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)[11] (obsoleted in favor of PLAIN)
RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security, Paul Hoffman, February 2002.
RFC 3848, ESMTP and LMTP Transmission Types Registration, Chris Newman, July 2004.
RFC 6409, Message Submission for Mail, Randall Gellens and John C. Klensin, November 2011 (obsoletes RFC 4409, from 2006, which in turn replaced RFC 2476, from December 1998).
RFC 4422, Simple Authentication and Security Layer (SASL), Alexey Melnikov and Kurt D. Zeilenga, June 2006.
RFC 4616, The PLAIN SASL Mechanism, K. Zeilenga, Ed., August 2006.
RFC 4954, SMTP Service Extension for Authentication, Robert Siemborski and Alexey Melnikov, July 2007.
RFC 7628, A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth, W. Mills, T. Showalter and H. Tschofenig, August 2015.
OtherEdit
Erwin Hoffmann, SMTP Authentication [Tutorial], last edit 2017-01-10.
^The relevant RFCs for reference are specified in the #Standards section
^The Trustees of Indiana University (2008-04-01). . University Information Technology Services. Indiana University. Archived from the original on 2007-06-17. Retrieved 2008-04-07.
^John Gardiner Myers (April 1995). "SMTP Service Extension for Authentication". IETF. Retrieved 2010-05-30.
^Sean Turner, Lily Chen (March 2011). Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. IETF. doi:10.17487/RFC6151. RFC 6151.
^Paul Hoffman (February 1, 1998). . Internet Mail Consortium. Archived from the original on 2016-03-05. Retrieved 2010-05-30.
^Paul Hoffman (August 2002). . Internet Mail Consortium. Archived from the original on 2007-01-18. Retrieved 2010-05-30.
^Simple Mail Transfer Protocol. sec. 2.2.1. doi:10.17487/RFC5321. RFC 5321. However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.
^K. Murchison and M. Crispin, The LOGIN SASL Mechanism, 28 August 2003, expired draft. LOGIN is described as obsolete in the SASL Mechanisms document but the mechanism is still in use.
smtp, authentication, often, abbreviated, smtp, auth, extension, simple, mail, transfer, protocol, smtp, whereby, client, using, authentication, mechanism, supported, server, mainly, used, submission, servers, where, authentication, mandatory, contents, histor. SMTP Authentication often abbreviated SMTP AUTH is an extension of the 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 servers where authentication is mandatory 1 Contents 1 History 2 Role in the mail transport system 3 Details 4 Standards 5 Other 6 See also 7 ReferencesHistory EditSMTP as specified by Jon Postel in the 1970s did not provide for using passwords for sending email messages each server was by design an open mail relay As a result spam and worms while not initially a problem had become a plague by the late 90s 2 Before SMTP AUTH a relay client had to be identified by IP address which is only practical for email services provided by the same Internet service provider ISP supplying the connection or else using specific hacks such as POP before SMTP John Gardiner Myers published the first draft of SMTP AUTH in 1995 3 and it has been successively developed and discussed in the IETF along with mail submission protocol Extended SMTP ESMTP and Simple Authentication and Security Layer SASL An older SASL mechanism for ESMTP authentication ESMTPA is CRAM MD5 and uses of the MD5 algorithm in HMACs hash based message authentication codes are still considered sound 4 The Internet Mail Consortium IMC reported that 55 of mail servers were open relays in 1998 5 but less than 1 in 2002 6 Role in the mail transport system EditUsing a mail submission agent MSA generally on port 587 implies SMTP AUTH MSA usage is supported by most software 7 and is recommended especially to support nomadic users as several network hubs either block port 25 or use SMTP proxies The MSA is responsible for ensuring that the message envelope contains good addresses and may enforce local policies for the From header field Verifying that the envelope sender a k a Return Path used for SPF and the From address agree with the authenticated user id is particularly important for domains that sign messages using DKIM Keywords ending in A such as ESMTPA and ESMTPSA are provided for the with clause of Received header fields when messages are received with SMTP AUTH 8 The keywords are provided for statistical or diagnostic purposes RFC 3848 they are checked by some clients e g Spamassassin Details EditAs 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 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 dGVzdAB0ZXN0ADEyMzQ 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 9 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 10 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 11 obsoleted in favor of PLAIN GSSAPI Generic Security Services Application Program Interface DIGEST MD5 Digest access authentication MD5 CRAM MD5 OAUTH10A OAuth 1 0a HMAC SHA1 tokens as defined in RFC 5849 OAUTHBEARER OAuth 2 0 bearer tokens as defined in RFC 6750 XOAUTH2 12 Standards EditRFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security Paul Hoffman February 2002 RFC 3848 ESMTP and LMTP Transmission Types Registration Chris Newman July 2004 RFC 6409 Message Submission for Mail Randall Gellens and John C Klensin November 2011 obsoletes RFC 4409 from 2006 which in turn replaced RFC 2476 from December 1998 RFC 4422 Simple Authentication and Security Layer SASL Alexey Melnikov and Kurt D Zeilenga June 2006 RFC 4616 The PLAIN SASL Mechanism K Zeilenga Ed August 2006 RFC 4954 SMTP Service Extension for Authentication Robert Siemborski and Alexey Melnikov July 2007 RFC 7628 A Set of Simple Authentication and Security Layer SASL Mechanisms for OAuth W Mills T Showalter and H Tschofenig August 2015 Other EditErwin Hoffmann SMTP Authentication Tutorial last edit 2017 01 10 See also EditE mail authentication Simple Mail Transfer Protocol Mail submission agent Email client port numbers Simple Authentication and Security Layer Open mail relay POP before SMTPReferences Edit The relevant RFCs for reference are specified in the Standards section The Trustees of Indiana University 2008 04 01 In Unix what is an open mail relay University Information Technology Services Indiana University Archived from the original on 2007 06 17 Retrieved 2008 04 07 John Gardiner Myers April 1995 SMTP Service Extension for Authentication IETF Retrieved 2010 05 30 Sean Turner Lily Chen March 2011 Updated Security Considerations for the MD5 Message Digest and the HMAC MD5 Algorithms IETF doi 10 17487 RFC6151 RFC 6151 Paul Hoffman February 1 1998 Allowing Relaying in SMTP A Survey Internet Mail Consortium Archived from the original on 2016 03 05 Retrieved 2010 05 30 Paul Hoffman August 2002 Allowing Relaying in SMTP A Series of Surveys Internet Mail Consortium Archived from the original on 2007 01 18 Retrieved 2010 05 30 Randall Gellens January 19 2005 Message Submission Interoperability Report IETF Retrieved 2019 07 05 Mail parameters IANA registry Retrieved 2011 07 23 Chris Newman 30 Apr 2010 Interop problem SMTP submission STARTTLS AUTH EXTERNAL IETF Retrieved 2010 05 30 Simple Mail Transfer Protocol sec 2 2 1 doi 10 17487 RFC5321 RFC 5321 However for compatibility with older conforming implementations SMTP clients and servers MUST support the original HELO mechanisms as a fallback K Murchison and M Crispin The LOGIN SASL Mechanism 28 August 2003 expired draft LOGIN is described as obsolete in the SASL Mechanisms document but the mechanism is still in use Gmail s XOAuth2 SASL protocol Retrieved from https en wikipedia org w index php title SMTP Authentication amp oldid 1165037199, wikipedia, wiki, book, books, library,
