MBOX-Line: From asuth at mozilla.com  Fri Mar  7 16:17:47 2014
To: imap-protocol@u.washington.edu
From: Andrew Sutherland <asuth@mozilla.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] Is it okay/common for servers to ignore
 commands sent before the greeting? (gmail seems to?)
In-Reply-To: <CABa8R6v9vL5KKx9ArrZ7Fr_nu3uL90fwWTr+Z2W+7960i=Rz9A@mail.gmail.com>
References: <5319E04C.3070105@mozilla.com>
	<CABa8R6v9vL5KKx9ArrZ7Fr_nu3uL90fwWTr+Z2W+7960i=Rz9A@mail.gmail.com>
Message-ID: <531A61AB.9090406@mozilla.com>

Aha!  Yes, the behavior does appear to be new and is manifesting in 
older releases that didn't experience this problem before*.  QA filed 
the bug with a log indicating this problem on 2/27 on 
https://bugzil.la/977867, but it's conceivable this was happening before 
that time.

Thanks!
Andrew

* But that doesn't necessarily guarantee things given the high rate of 
platform change and platform backports occurring for Firefox OS.  In 
this case our IMAP implementation is unchanged and our TCPSocket 
implementation on top of Necko/NSS is unchanged.  I assume NSS changes 
and gets uplifts.

On 03/07/2014 10:34 AM, Brandon Long wrote:
>
> Is this behavior new?
>
> We're just finishing the rollout of a new IMAP proxy, its possible its 
> a bug in the new impl.
>
> Brandon
>
> On Mar 7, 2014 7:06 AM, "Andrew Sutherland" <asuth@mozilla.com 
> <mailto:asuth@mozilla.com>> wrote:
>
>     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
>     Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
>     http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140307/93dc5419/attachment.html>
