82 lines
3.4 KiB
Plaintext
82 lines
3.4 KiB
Plaintext
MBOX-Line: From blong at google.com Fri Mar 7 16:29:19 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.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: <531A61AB.9090406@mozilla.com>
|
|
References: <5319E04C.3070105@mozilla.com>
|
|
<CABa8R6v9vL5KKx9ArrZ7Fr_nu3uL90fwWTr+Z2W+7960i=Rz9A@mail.gmail.com>
|
|
<531A61AB.9090406@mozilla.com>
|
|
Message-ID: <CABa8R6t0ntORM=wrTQoUFGPu9Fd-PxMxRofc2D_ibBdtDmpUpg@mail.gmail.com>
|
|
|
|
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 <asuth@mozilla.com> 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" <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
|
|
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
>
|
|
|