87 lines
3.7 KiB
Plaintext
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>
|