Skip to main content

SMTP Service Extension for Authentication
RFC 4954

Revision differences

Document history

Date Rev. By Action
2020-01-21
09 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
09 (System)
Received changes through RFC Editor sync (changed abstract to 'This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate …
Received changes through RFC Editor sync (changed abstract to 'This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554. [STANDARDS-TRACK]')
2015-10-14
09 (System) Notify list changed from alexey.melnikov@isode.com, robsiemb@google.com to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Sam Hartman
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-08-10
09 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-08-10
09 Amy Vezza [Note]: 'RFC 4954' added by Amy Vezza
2007-07-24
09 Chris Newman Fixing Rob's address in tracker to match address in document.
2007-07-24
09 Chris Newman State Change Notice email list have been change to alexey.melnikov@isode.com, robsiemb@google.com from alexey.melnikov@isode.com, rjs3+@andrew.cmu.edu
2007-07-23
09 (System) RFC published
2007-04-27
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-04-27
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-04-27
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-04-27
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-04-24
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-04-20
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-04-16
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-04-10
09 (System) IANA Action state changed to In Progress
2007-04-07
09 Amy Vezza IESG state changed to Approved-announcement sent
2007-04-07
09 Amy Vezza IESG has approved the document
2007-04-07
09 Amy Vezza Closed "Approve" ballot
2007-04-07
09 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-04-07
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-04-05
09 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman
2007-04-03
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-04-03
09 (System) New version available: draft-siemborski-rfc2554bis-09.txt
2007-03-09
09 (System) Removed from agenda for telechat - 2007-03-08
2007-03-08
09 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-03-08
09 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2007-03-08
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-03-08
09 Sam Hartman
[Ballot discuss]
This spec is inconsistent with the following text from RFc 4616:

>  By default, implementations SHOULD advertise and make use of the  …
[Ballot discuss]
This spec is inconsistent with the following text from RFc 4616:

>  By default, implementations SHOULD advertise and make use of the              PLAIN mechanism only when adequate data security services are in
>  place.  Specifications for IETF protocols that indicate that this
>  mechanism is an applicable authentication mechanism MUST mandate that
>  implementations support an strong data security service, such as TLS.
 










First, it's not sufficient to have a mandatory configuration in which
plain is only advertized when external security services are in place:
this configuration SHOULD be the default, and your text needs to say
this.  Clearly, implementations with a good reason to do so can
violate this or any other SHOULD.


Second, you need to mandate a particular external security service to
guarantee interoperability.  I recommend that you address this by
requiring all implementations of this spec implement starttls.  You
will also need to look at the issue of certificate verification.  It
is common (and in many environments appropriate) for SMTP
implementations not to verify the TLS server certificate.  That's
actually a good thing for the most part.  But in the configuration
where plain is only used over TLS, clients MUST NOT use plain if the
server certificate failed to verify.
2007-03-08
09 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2007-03-08
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-03-08
09 Bill Fenner [Ballot discuss]
While it doesn't happen often, RFCs can advance from PS to DS in-place so the abstract shouldn't identify this document as Proposed Standard.
2007-03-08
09 Bill Fenner [Ballot Position Update] New position, Discuss, has been recorded by Bill Fenner
2007-03-07
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-03-07
09 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2007-03-07
09 Cullen Jennings [Ballot comment]
2007-03-07
09 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2007-03-07
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-03-07
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-03-07
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-03-06
09 Cullen Jennings
[Ballot discuss]
In section 6, you have a status code of X.5.6. If this is correct, just let me know but this confused me on …
[Ballot discuss]
In section 6, you have a status code of X.5.6. If this is correct, just let me know but this confused me on what it meant - I thought it needed to start with 2,4, or 5 and was not sure what this signified here. If it means any, well it does not seem appropriate for 2.
2007-03-06
09 Cullen Jennings [Ballot comment]
The second paragraph in IANA section made no sense to me.
2007-03-06
09 Cullen Jennings
[Ballot discuss]
In section 6, you have a status code of X.5.6. If this is correct, This confused me on what it meant - I …
[Ballot discuss]
In section 6, you have a status code of X.5.6. If this is correct, This confused me on what it meant - I thought it needed to start with 2,4, or 5 and was not sure what this signified here.
2007-03-06
09 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2007-03-05
09 Russ Housley [Ballot comment]
s/insure interoperability/ensure interoperability/

  The final paragraph of the Security Considerations section is not
  indented preperly.
2007-03-05
09 Russ Housley
[Ballot discuss]
The security Considerations say:
  >
  > Implementations MUST support a configuration where SASL mechanisms
  > that are vulnerable to passive …
[Ballot discuss]
The security Considerations say:
  >
  > Implementations MUST support a configuration where SASL mechanisms
  > that are vulnerable to passive eavesdropping attacks (such as
  > [PLAIN]) are not advertised or used without the presence of an
  > external security layer such as [TLS].
  >
  I do not think that these words convey the intended meaning.  I think
  that the intent is something like: "If an implementation supports
  SASL mechanisms that are vulnerable to passive eavesdropping attacks
  (such as [PLAIN]), then the implemenations MUST support at least one
  configuration where these SASL mechanisms are not advertised or used
  without the presence of an external security layer such as [TLS]."
2007-03-05
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-03-05
09 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault
2007-03-05
09 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2007-03-02
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-02-23
09 Ted Hardie State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie
2007-02-23
09 Ted Hardie Placed on agenda for telechat - 2007-03-08 by Ted Hardie
2007-02-23
09 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2007-02-23
09 Ted Hardie Ballot has been issued by Ted Hardie
2007-02-23
09 Ted Hardie Created "Approve" ballot
2007-02-23
08 (System) New version available: draft-siemborski-rfc2554bis-08.txt
2007-02-21
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-02-16
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sean Turner.
2007-02-05
09 Yoshiko Fong
IANA  Additional Comments:

>First, in the MAIL Parameters registry located at:
>http://www.iana.org/assignments/mail-parameters
>in the SMTP Service Extensions registry a new SMTP
>service extension will …
IANA  Additional Comments:

>First, in the MAIL Parameters registry located at:
>http://www.iana.org/assignments/mail-parameters
>in the SMTP Service Extensions registry a new SMTP
>service extension will be added:
>
>Keywords Description
>------------------- ---------------------------
>AUTHENTICATION Authentication

You don't need to add a new entry, you need to replace an
existing entry:

Keywords Description
------------------- ---------------------------
AUTH Authentication mechanism [RFC2554]

to point to draft-siemborski-rfc2554bis. You should also
change the Description to read "Authentication".
2007-02-01
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sean Turner
2007-02-01
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sean Turner
2007-01-31
09 Yoshiko Fong
IANA Last Call Comments:

Upon approval of this document, IANA understands it must
complete two actions.

First, in the MAIL Parameters registry located at:

http://www.iana.org/assignments/mail-parameters …
IANA Last Call Comments:

Upon approval of this document, IANA understands it must
complete two actions.

First, in the MAIL Parameters registry located at:

http://www.iana.org/assignments/mail-parameters

in the SMTP Service Extensions registry a new SMTP
service extension will be added:

Keywords Description
------------------- ---------------------------
AUTHENTICATION Authentication

Second, in the GSSAPI/Kerberos/SASL service names
registry located at:

http://www.iana.org/assignments/gssapi-service-names

the reference will be changed to point at the newly
approved document for the  service name "smtp"

The IANA understands that these are the only actions
required upon approval of the document.
2007-01-24
09 Amy Vezza Last call sent
2007-01-24
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-01-24
09 Lisa Dusseault Last Call was requested by Lisa Dusseault
2007-01-24
09 Lisa Dusseault State Changes to Last Call Requested from AD Evaluation by Lisa Dusseault
2007-01-24
09 (System) Ballot writeup text was added
2007-01-24
09 (System) Last call text was added
2007-01-24
09 (System) Ballot approval text was added
2007-01-24
09 Lisa Dusseault Intended Status has been changed to Proposed Standard from None
2007-01-23
07 (System) New version available: draft-siemborski-rfc2554bis-07.txt
2007-01-23
09 Lisa Dusseault State Changes to AD Evaluation from Publication Requested::AD Followup by Lisa Dusseault
2006-12-13
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-12-13
06 (System) New version available: draft-siemborski-rfc2554bis-06.txt
2006-12-01
09 Lisa Dusseault Alexey is requesting reviews of this before proceeding
2006-12-01
09 Lisa Dusseault Draft Added by Lisa Dusseault in state Publication Requested
2006-11-26
05 (System) New version available: draft-siemborski-rfc2554bis-05.txt
2005-02-23
04 (System) New version available: draft-siemborski-rfc2554bis-04.txt
2004-04-13
03 (System) New version available: draft-siemborski-rfc2554bis-03.txt
2003-12-05
02 (System) New version available: draft-siemborski-rfc2554bis-02.txt
2003-11-19
01 (System) New version available: draft-siemborski-rfc2554bis-01.txt
2003-10-10
00 (System) New version available: draft-siemborski-rfc2554bis-00.txt