Indy, OAuth 2.0 with protocol POP

[rlebeau]

I decided to look inside the Indy code, to IdPOP3 and IdIMAP4 classes. I found differences in the part of code, where authorization is - please, look at the TIdIMAP4.Login and TIdPOP3.Login pictures in attachment. I use initial-response in connection via SMTP and IMAP, but it looks like TIdPOP3 does not support initial-response.

There are comments about that in the source code for TIdPOP3.Login() and TIdSASLEntries.LoginSASL(), which is the method that both TIdPOP3 and TIdSMTP use:

Code:

// SASL in POP3 did not originally support Initial-Response. It was added
// in RFC 2449 along with the CAPA command. If a server supports the CAPA
// command then it *should* also support Initial-Response as well, however
// many POP3 servers support CAPA but do not support Initial-Response
// (which was formalized in RFC 5034). So, until we can handle that
// descrepency better, we will simply disable Initial-Response for now.

Code:

// SASL in SMTP and DICT supported Initial-Response from the beginning,
// as should any new SASL-enabled protocol moving forward.
//
// SASL in IMAP did not originally support Initial-Response, but it was
// added in RFC 4959 along with an explicit capability ('SASL-IR') to
// indicate when Initial-Response is supported. SASL in IMAP is currently
// handled by TIdIMAP4 directly, but should it be updated to use
// TIdSASLEntries.LoginSASL() in the future then it will set the
// ACanAttemptIR parameter accordingly.
//
// SASL in POP3 did not originally support Initial-Response. It was added
// in RFC 2449 along with the CAPA command. If a server supports the CAPA
// command then it *should* also support Initial-Response as well, however
// many POP3 servers support CAPA but do not support Initial-Response
// (which was formalized in RFC 5034). So, to handle that descrepency,
// TIdPOP3 currently sets ACanAttemptIR to false.  In the future, we could
// let it set ACanAttemptIR to True instead, and then if Initial-Response
// fails here for POP3 then re-attempt without Initial-Response before
// exiting with a failure.

As you can see in TIdPOP3.Login(), it does indeed set ACanAttemptIR=False, whereas TIdSMTP sets ACanAttemptIR=True unconditionally, and TIdIMAP4 uses the initial-response parameter based on the presence of the SASL-IR capability.

So, to do what you want in POP3, you will have to set ACanAttemptIR=True instead, but know that it MAY fail on older non-Google servers.

On the other hand, the initial-response parameter of an AUTH command in POP3 is optional, even by modern RFCs, so Google should not be requiring clients to use the initial-response parameter. If it is, that is a bug on Google's part.

So, will I manage to connect with OAuth2 with POP3 in Indy (avoiding using app password)?

If Google is requiring the use of the initial-response parameter in an AUTH XOAUTH2 command, and if you don't update the source code for TIdPOP3.Login() to set ACanAttemptIR=True, then no, unless you handle the SASL commands manually by calling TIdPOP3.SendCmd() directly.