(04-28-2020, 07:40 AM)IndyBeginner Wrote: [ -> ]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.
(04-28-2020, 07:40 AM)IndyBeginner Wrote: [ -> ]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.