Search code examples
emailgmailprotocolsimap

Gmail doesn't respond with TAG OK via IMAP on successful login

Here's its response gotten via socket in my application:

* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT APPENDLIMIT=35882577 LIST-EXTENDED LIST-STATUS

when login is successful on the port 993. Here's is one when a login or password is wrong on the same port:

TAG_2 NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)

Where's OK and Tag in the 1st case?

Solution

  • An IMAP server is allowed, and will, provide multiple responses to a command. In this case, Gmail is providing an unsolicited CAPABILITY response, so you don't have to request it yourself later.

    Sample session from gmail:

    > a LOGIN user password
< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT APPENDLIMIT=35882577 LIST-EXTENDED LIST-STATUS
< a OK user authenticated (Success)

    LOGIN is just like any other command, it can have several responses, just like SELECT has many responses before finishing:

    > b SELECT INBOX
< * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Junk $NotJunk $NotPhishing $Phishing Junk NonJunk NotJunk)
< * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Junk $NotJunk $NotPhishing $Phishing Junk NonJunk NotJunk \*)] Flags permitted.
< * OK [UIDVALIDITY 636588758] UIDs valid.
< * 271 EXISTS
< * 0 RECENT
< * OK [UIDNEXT 24821] Predicted next UID.
< * OK [HIGHESTMODSEQ 917752]
< b OK [READ-WRITE] INBOX selected. (Success)

    You should simply continue reading lines until you receive the tagged response to your query. Any untagged responses (starting with *) are informative, and can be ignored or processed as required.

    This particular behaviour, sending CAPABILITY on LOGIN is expressly allowed by RFC 3501, section 7.2.1:

      A server MAY send capabilities automatically, by using the
  CAPABILITY response code in the initial PREAUTH or OK responses,
  and by sending an updated CAPABILITY response code in the tagged
  OK response as part of a successful authentication.  It is
  unnecessary for a client to send a separate CAPABILITY command if
  it recognizes these automatic capabilities.

    Please also see section 2.2.2, which indicates: A client MUST be prepared to accept any server response at all times. This includes server data that was not requested.