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.
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. 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 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, and it has
been successively developed and discussed in the IETF along with mail
submission protocol, Extended SMTP, and Simple Authentication and Security
Layer. An older SASL mechanism for ESMTP authentication is CRAM-MD5, and uses of
the MD5 algorithm in HMACs are still considered sound.
The Internet Mail Consortium reported 55% of mail servers were open relays in
1998, but less than 1% in 2002. Role in the mail transport system
Using a mail submission agent, generally on port 587, implies SMTP AUTH. MSA
usage is supported by most software 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 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. "The keywords are provided for
statistical or diagnostic purposes"; 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: 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.
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.
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:
PLAIN LOGIN
GSSAPI DIGEST-MD5
MD5 CRAM-MD5
Standards 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.
RFC 4422, Simple Authentication and Security Layer, Alexey Melnikov and Kurt
D. Zeilenga, June 2006. RFC 4954, SMTP Service Extension for
Authentication, Robert Siemborski and Alexey Melnikov, July 2007.
See also E-mail authentication
Simple Mail Transfer Protocol Mail submission agent
Extended SMTP Email client port numbers
Simple Authentication and Security Layer Open mail relay
POP before SMTP References