[Imap-protocol] Is it okay/common for servers to ignore commands sent before the greeting? (gmail seems to?)

Andrew Sutherland <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
We're seeing a problem in the Firefox OS Gaia e-mail app where if we 
manage to send our "A1 CAPABILITY" request to the gmail IMAP server 
(initial-TLS imaps/993) before it sends its greeting, it acts like it 
never hears the request.  Our not-so-clever state machine hangs until 
the connection times out.

There's more details and pcap dumps at https://bugzil.la/977867#c21 but 
basically we sometimes manage to get that request in the same TCP packet 
as the conclusion of TLS setup.  The TCP/TLS packet with the server 
greeting ACKs that packet, so it's quite conceivable our request is 
managing to fall into a very specific edge case/race.

The spec does not seem to have a final word on this, although the state 
flow diagram in http://tools.ietf.org/html/rfc3501#section-3 does seem 
to imply that it's bad form to not wait for the server greeting.  While 
I think it's clear that for gmail we need to wait for the server 
greeting, I am wondering if this is just an unusual complication/bug of 
gmail's likely more complicated server architecture.  I'd expect a 
server intentionally being pedantic to issue a NO or BAD request...

Thoughts / has anyone seen servers that intentionally or accidentally 
get upset in cases like this?

Thanks,
Andrew

PS: We do have a lot of round-trip fat in our connection establishment, 
so it's not the end of the world to explicitly wait for the server 
greeting in all cases, but if it's just gmail (and we appropriately add 
some improved timeout logic that triggers a persistent quirk for the 
server), I could see it make sense to continue not waiting for the greeting.
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.