MBOX-Line: From asuth at mozilla.com  Tue Mar 24 16:47:40 2015
To: imap-protocol@u.washington.edu
From: Andrew Sutherland <asuth@mozilla.com>
Date: Fri Jun  8 12:34:54 2018
Subject: [Imap-protocol] Is OpenEmailSurvey open to share method or code?
In-Reply-To: <1427238946.968483.244801809.1E105795@webmail.messagingengine.com>
References: <55109D4C.2080900@laposte.net> <5510BC3A.9020702@verizon.net>
	<5511EDA6.7060107@laposte.net>
	<1427238946.968483.244801809.1E105795@webmail.messagingengine.com>
Message-ID: <CALFQBW2BxiB_CCKtg+VsfQsG25LyQeoi67n1UXqn3SUv8dqJsQ@mail.gmail.com>

On Tue, Mar 24, 2015 at 7:15 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> We like ID commands at FastMail too - we log them and it gives us both an
> idea of usage patterns, and the ability to give more accurate bug reports
> if we
> detect something weird.
>

And some servers can be downright aggressive about.  The Firefox OS email
app experienced the Coremail IMAP servers at 163.com (and presumably all
netease-operated servers) doing things like saying "NO" to a SELECT with
the human-readable string "SELECT The login is not safe! Please update your
mail client: http://mail.163.com/dashi" when we weren't providing a (valid)
ID.  The NO to the select only happened some of the time, but the login
would result in an ad for 163.com's Android/iOS mail clients being injected
into the inbox with apparently very limited duplicate suppression.  Note
that we were using initial-TLS on port 993 with then-current Gecko/NSS.
Some more details at https://bugzilla.mozilla.org/show_bug.cgi?id=1105573
for anyone interested.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/074a44e5/attachment.html>
