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

We've identified at least one bug here and submitted a fix.  Not sure
the exact timeframe of rollout.

Brandon

On Fri, Mar 7, 2014 at 4:17 PM, Andrew Sutherland <[email protected]> wrote:
> 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" <[email protected]> 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
>> [email protected]
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol