SMTP Authentication

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol whereby an SMTP client may log in using an authentication mechanism chosen among those supported by the SMTP server. The authentication extension is mandatory for submission servers.[1]

History

Differently from mail-access protocols, the original SMTP specified by Jon Postel in the 1970s did not provide for using passwords for sending email messages. This lack of security gave rise to open mail relays, unprotected mail servers used to propagate spam and worms that became a plague in 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 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. For example, (from RFC 4954):

  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.

When using authentication, EHLO should be used for the greeting to indicate that Extended SMTP is in use, as opposed to the HELO greeting in standard SMTP.

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

See also

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.
  5. ↑ Paul Hoffman (February 1, 1998). "Allowing Relaying in SMTP: A Survey". Internet Mail Consortium. Retrieved 2010-05-30.
  6. ↑ Paul Hoffman (August 2002). "Allowing Relaying in SMTP: A Series of Surveys". Internet Mail Consortium. Retrieved 2010-05-30.
  7. ↑ Randall Gellens (January 19, 2005). "Message Submission Interoperability Report". IETF. Retrieved 2010-05-30.
  8. ↑ "Mail parameters". IANA registry. Retrieved 2011-07-23.
  9. ↑ Chris Newman (Fri, 30 Apr 2010 16:28:32 -0700). "Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL". IETF. Retrieved 2010-05-30. Check date values in: |date= (help)
This article is issued from Wikipedia - version of the 11/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.