wasm-demo/demo/ermis-f/imap-protocol/cur/1600095025.22659.mbox:2,S

55 lines
2.0 KiB
Plaintext

MBOX-Line: From mg at MIT.EDU Mon Oct 28 12:00:13 2013
To: imap-protocol@u.washington.edu
From: Michael Grinich <mg@MIT.EDU>
Date: Fri Jun 8 12:34:51 2018
Subject: [Imap-protocol] Mac OS 10.9 particularly buggy implementation of
IMAP
In-Reply-To: <20131028132511.GA13146@gulbrandsen.priv.no>
References: <1382749818.11252.38686053.54FA9CC9@webmail.messagingengine.com>
<20131028132511.GA13146@gulbrandsen.priv.no>
Message-ID: <CAO3aFYtjUT4=08VVB2H1jiQJU0Wnhrj9OM6E5ZT0PEC+tsPNRw@mail.gmail.com>
Have you seen the 2-million-message-copy behavior on multiple users? That
seems like a bug that might be related to some weird rules, or perhaps a
buggy migration of rules from 10.8 to 10.9.
From talking to people at Apple, literally the *best* way to get stuff like
this fixed is to file bug reports on BugReporter<http://bugreporter.apple.com>.
After that, please post the issue to
OpenRadar<http://www.openradar.me/page/1> so
others can see it. For your users that actively report problems, you can
send them some boilerplate to also submit a bug, and include the original
bug number so it can be marked as a dupe.
On Mon, Oct 28, 2013 at 6:25 AM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no>wrote:
> On Sat, Oct 26, 2013 at 12:10:18PM +1100, Bron Gondwana wrote:
> > (there's another interesting pattern, it appears to send the 'D' of
> > 'DONE' in a separate packet when finishing IDLE... no idea why. I've
> > never seen DONE split over two reads before)
>
> Two possibilities:
>
> 1. It's a neat hack to learn whether a middlebox has killed the
> connection.
>
> 2. They're sending the D, O and N separately to extend NAT timeouts.
>
> Arnt
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20131028/51fa2d41/attachment.html>