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

87 lines
3.7 KiB
Plaintext

MBOX-Line: From blong at google.com Wed Sep 3 13:11:32 2014
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun 8 12:34:53 2018
Subject: [Imap-protocol] Seeking clarity on Gmail "Access for less
secure apps" setting for non XOAuth2 access
In-Reply-To: <00bd4f8b-cc4e-48b9-8aad-6788e23666af@gulbrandsen.priv.no>
References: <5400A146.4020602@mozilla.com>
<CABa8R6se2WefF4q-cFzR2qtU_5_jDL-wioPF+jPmOTdpCaJhtw@mail.gmail.com>
<54011E24.4080209@mozilla.com>
<6f3e9961-32e6-4b4b-866f-7ce5526b0bf8@gulbrandsen.priv.no>
<CABa8R6vJUAo231ECkLyDsTmk08UGgS2E7i6SNZ==x6YwFOiPUw@mail.gmail.com>
<00bd4f8b-cc4e-48b9-8aad-6788e23666af@gulbrandsen.priv.no>
Message-ID: <CABa8R6vYYpbkV56=b6ydu7peJfdBDVnbUa70dvvEyd_H9NdjEQ@mail.gmail.com>
On Wed, Sep 3, 2014 at 4:17 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
wrote:
> On Tuesday, September 2, 2014 11:09:47 PM CEST, Brandon Long wrote:
>
>> It didn't when we wrote the server. Even now that it does, and I believe
>> I've mentioned this before, the 5530 codes are inherently non-backward
>> compatible.
>>
>
> That's not a compatbility break, for two reasons.
>
> One is that you know very, very little about what the client acts on, so
> 5530 is business as usual. For example, I can't at the moment think of any
> GUI client that obeys the RECENT-related MUST rule in 3501, so sending the
> RECENT response is a bit hit and miss.
>
> The other is that there was nothing there to really be compatible with.
> 5530 is based on client and server surveys. Take NOPERM for example:
> Various servers tested for that, and all reported failure as "NO some
> human-readable text here", and I could not find any client that used the
> human-readable text as basis for any behaviour.
>
> Or take OVERQUOTA. IIRC I found a client that did "if the response is NO
> and the human-readable text contains the string quot". I have a problem
> with talking about something is compatible with such fuzzily unclear fuzz.
Sure, I was being specific to [ALERT] meaning "show the user", not any
fuzzy logic that people were using on the strings themselves.
[snip]
We could also use separate tagged/untagged responses to give both an ALERT
>> and a specific code, but that's obviously something of a hack and its not
>> clear most clients handle that either.
>>
>
> My two cents: ALERT is a bit pointless, but if you want to send ALERT,
> send that in an untagged response of its own. ALERT is intended for the
> user, and the user has no use for the command tag. Put client-directed
> response codes in the tagged response, because most clients know their tags
> and tie the tagged response tightly to the command.
At this point, I'm willing to concede that point.
[snip]
> You're talking about a server that issues UTF8=ACCEPT in CAPABILITY when
> asked, and how it behaves in some exceptional problem. If there's a
> problem, then I venture to suggest that there's a very slim chance that a)
> the client parses the hr-text at all and b) would be able to recover from
> the problem but c) is not able to recover because the hr-text contains UTF8.
>
> Sending UTF8 if there isn't a problem sounds riskier. That's a common
> cazse, not exceptional, and there's more to lose.
Funny, we just got an external bug report today due to us sending UTF8 in
the OK response to logins for user's with UTF8 names (which we'll be
fixing).
It is interesting to violate in case of errors. I assume that will make
things worse for people who are actually inspecting our strings, though.
Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140903/eca45780/attachment.html>