2.2.1 AUTH Extensions

Article
06/24/2021

The first category of POP3 messages is messages that fall within the AUTH extensibility framework. These messages are specified in [RFC1734]. Some messages have parameters that must be customized by the extensibility mechanism (such as NTLM). The following customizations are introduced in this document:

A client can query the server to learn whether or not NTLM is supported. This is accomplished by issuing the AUTH command without any parameters. In the following definition, this command is shown in Augmented Backus-Naur Form (ABNF) (for more information on ABNF, see [RFC5234]).
```
  AUTH<SPACE><CR><LF>
```
where:
```
 <SPACE>
```
is defined as a single space character.

This mechanism is intended for clients that want to determine which authentication methods are available. A client can either issue this command to query whether NTLM is available and then initiate an NTLM auth session, or the client can simply try to initiate an NTLM session expecting it to fail if NTLM is not supported. Issuing the AUTH command does not change the state of the client; it is still in an unauthenticated state. In this state, the client can either issue another AUTH command or start the authentication process.
The server responds to this message with a message followed by a list of supported authentication mechanisms, followed by a list termination message. This sequence is shown in the following ABNF definition.
```
 +OK<CR><LF>NTLM<CR><LF>.<CR><LF>
```
If NTLM is not supported, the POP3 server returns a failure status code as defined by [RFC1734] and a POP3_AUTH_NTLM_Fail_Response message is returned in response to the "AUTH<SPACE><CR><LF>" message. The only data in this message that is useful is -ERR. The remaining data is human-readable and has no bearing on the authentication. The syntax of this command is shown in the following ABNF definition. This syntax is referred to as POP3_AUTH_NTLM_Fail_Response in this specification.
```
 -ERR <human_readable_string><CR><LF>
```
[RFC1734] section 2 defines the syntax of the AUTH command to initiate authentication. The parameter "mechanism" is defined to be the string "NTLM" for NTLM POP3 Extension. The command to initiate an NTLM conversation by a client is shown in the following ABNF definition. This is referred to as POP3_AUTH_NTLM_Initiation_Command in this document.
```
 AUTH NTLM<CR><LF>
```
If NTLM is supported, the POP3 server will respond with a POP3 message to indicate that NTLM is supported. The syntax of this command is shown in the following ABNF definition. This is referred to as POP3_NTLM_Supported_Response in this document.
```
 +OK<CR><LF>
```
If NTLM is not supported, the POP3 server returns a failure status code as defined by [RFC1734]. The only data in this message that is useful is -ERR. The remaining data is human-readable data and has no bearing on the authentication. The syntax of this command is shown in the following ABNF definition. This is referred to as POP3_AUTH_NTLM_Fail_Response in this document.
```
 -ERR <human_readable_string> <CR><LF>
```
At every point of time during the authentication exchange, the client must parse the responses in the messages sent by the server and interpret them as defined by [RFC1734]. The responses define various states such as success in authenticating, failure to authenticate, and any other arbitrary failures that the software might encounter.

The client can receive any one of the following responses during authentication. Note that the syntax and meaning of all these messages are completely defined by [RFC1734].
- POP3_AUTH_NTLM_Blob_Response: This message is partially defined in [RFC1734]. The plus sign (+) status code indicates ongoing authentication and indicates that <base64-encoded-NTLM-message> is to be processed by the authentication subsystem. In this case, the client must de-encapsulate the data and pass it to the NTLM subsystem.
```
 + <base64-encoded-NTLM-message><CR><LF>
```
- POP3_AUTH_NTLM_Fail_Response: This message is defined in [RFC1734] and indicates that the authentication has terminated unsuccessfully, either because the user name or password was incorrect, or because of some other arbitrary error such as a software or data corruption error.
```
 -ERR <human-readable-string><CR><LF>
```
- POP3_AUTH_NTLM_Succeeded_Response: This message is defined in [RFC1734] and indicates that the authentication negotiation has completed with the client successfully authenticating to the server.
```
 +OK <human-readable-string><CR><LF>
```
- POP3_AUTH_NTLM_Cancelled_Response: This message is defined in [RFC1734] and indicates that the authentication negotiation has been canceled with the client.<3>
```
 -ERR <human-readable-string><CR><LF>
```
NTLM messages encapsulated by the client and sent to the server, are referred to as POP3_AUTH_NTLM_Blob_Command in this document. They have the following syntax defined in ABNF and conform to the prescription of [RFC1734].
```
 <base64-encoded-NTLM-message><CR><LF>
```
Once the POP3_AUTH_NTLM_Initiation_Command has been sent to start the authentication process, the client is able to cancel the authentication request by issuing a POP3_AUTH_Cancellation_Command. This has the following syntax, defined in ABNF.
```
 *<CR><LF>
```
As specified in [RFC1734], the client can cancel the authentication request at any point during the exchange. Once sent, the client then remains in an unauthenticated state.

2.2.1 AUTH Extensions

Additional resources