SMTP Authentication

Last updated

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

History

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 system

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.

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, 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 PLAINC: 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:

Standards

Other

See also

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients 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 RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

The Network News Transfer Protocol (NNTP) is an application protocol used for transporting Usenet news articles (netnews) between news servers, and for reading/posting articles by the end user client applications. Brian Kantor of the University of California, San Diego, and Phil Lapsley of the University of California, Berkeley, wrote RFC 977, the specification for the Network News Transfer Protocol, in March 1986. Other contributors included Stan O. Barber from the Baylor College of Medicine and Erik Fair of Apple Computer.

The Local Mail Transfer Protocol (LMTP) is an alternative to (Extended) Simple Mail Transfer Protocol for situations where the receiving side does not have a mail queue, such as a message transfer agent acting as a message delivery agent. LMTP was described in RFC 2033 in 1996.

Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL. Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another. They can also provide a data security layer offering data integrity and data confidentiality services. DIGEST-MD5 provides an example of mechanisms which can provide a data-security layer. Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.

<span class="mw-page-title-main">Digest access authentication</span> Method of negotiating credentials between web server and browser

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

On-Demand Mail Relay (ODMR) is an SMTP extension standardized in RFC 2645 that allows e-mail to be relayed to the recipients after they have been authenticated. It uses the extended SMTP command ATRN, similar to the ETRN command but available for dynamically assigned IP addresses.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

The Generic Security Service Application Program Interface is an application programming interface for programs to access security services.

<span class="mw-page-title-main">Message submission agent</span>

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

In cryptography, CRAM-MD5 is a challenge–response authentication mechanism (CRAM) based on the HMAC-MD5 algorithm. As one of the mechanisms supported by the Simple Authentication and Security Layer (SASL), it is often used in email software as part of SMTP Authentication and for the authentication of POP and IMAP users, as well as in applications implementing LDAP, XMPP, BEEP, and other protocols.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality.

In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.

Token Binding is a proposed standard for a Transport Layer Security (TLS) extension that aims to increase TLS security by using cryptographic certificates on both ends of the TLS connection. Current practice often depends on bearer tokens, which may be lost or stolen. Bearer tokens are also vulnerable to man-in-the-middle attacks or replay attacks. In contrast, bound tokens are established by a user agent that generates a private-public key pair per target server, providing the public key to the server, and thereafter proving possession of the corresponding private key on every TLS connection to the server.

References

  1. ↑ The relevant RFCs for reference are specified in the #Standards section
  2. ↑ 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.
  3. ↑ John Gardiner Myers (April 1995). "SMTP Service Extension for Authentication". IETF . Retrieved 2010-05-30.
  4. ↑ 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.
  5. ↑ 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.
  6. ↑ 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.
  7. ↑ Randall Gellens (January 19, 2005). "Message Submission Interoperability Report". IETF . Retrieved 2019-07-05.
  8. ↑ "Mail parameters". IANA registry. Retrieved 2011-07-23.
  9. ↑ Chris Newman (30 Apr 2010). "Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL". IETF . Retrieved 2010-05-30.
  10. ↑ 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.
  11. ↑ 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.
  12. ↑ Gmail's XOAuth2 SASL protocol
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.