82 lines
3.5 KiB
Plaintext
82 lines
3.5 KiB
Plaintext
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>
|