110 lines
4.7 KiB
Plaintext
110 lines
4.7 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Sep 2 14:09:47 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: <6f3e9961-32e6-4b4b-866f-7ce5526b0bf8@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>
|
|
Message-ID: <CABa8R6vJUAo231ECkLyDsTmk08UGgS2E7i6SNZ==x6YwFOiPUw@mail.gmail.com>
|
|
|
|
On Sat, Aug 30, 2014 at 2:02 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
wrote:
|
|
|
|
> This makes me sad.
|
|
>
|
|
> On Saturday, August 30, 2014 2:43:16 AM CEST, Andrew Sutherland wrote:
|
|
>
|
|
>> For example, we already explicitly detect the Gmail specific "NO [ALERT]"
|
|
>> cases of things like the following:
|
|
>> - Application-specific password required
|
|
>> - Your account is not enabled for IMAP use.
|
|
>> - IMAP access is disabled for your domain.
|
|
>>
|
|
>
|
|
> As if 5530 didn't exist.
|
|
|
|
|
|
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. We have no way of knowing if a client handles a given code,
|
|
and we originally went with ALERT so that people could actually see the
|
|
error.
|
|
|
|
Now, it turns out most clients ignore ALERT and don't show it to the user,
|
|
regardless of the spec. We did go through and update most of the login
|
|
errors (and others) to correspond to the 5530 codes where there was a
|
|
match. 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.
|
|
|
|
|
|
> and want to better handle:
|
|
>> - Please log in via your web browser: http://support.google.com/
|
|
>> mail/accounts/bin/answer.py?answer=78754 (Failure)
|
|
>>
|
|
>
|
|
> There is a response code for that, WEBALERT. Not standard, but at least
|
|
> it's better than trying to have a client parsing human-readable text.
|
|
|
|
|
|
Yes, if we have a URL to send, we issue a WEBALERT. There was some debate
|
|
internally about whether or not to re-use the 5530 syntax for our own
|
|
specific codes.
|
|
|
|
|
|
> I believe this new failure adds another specialized error code (and
|
|
>> regrettably, we screw up here, mea culpa.)
|
|
>>
|
|
>> Knowing what the string would be, whether it's localized, etc. would be
|
|
>> handy. We do these detections to try and provide appropriately localized
|
|
>> error messages that might provide better context to the user and
|
|
>> differentiate between persistent failures and transient failures (ex: NO
|
|
>> [UNAVAILABLE]), although I should be clear these are insufficiently
|
|
>> researched hacks.
|
|
>>
|
|
>
|
|
> The point of 5530 and that registry was that clients should not need to do
|
|
> such things. IMO Google screws up by not defininig response codes, not you.
|
|
|
|
|
|
Extending the available codes via RFC seems heavy weight, especially if its
|
|
for things that are more specific to our server. Maybe a list of "generic
|
|
but more specific" ones could be made, but would we really have one for
|
|
"Your domain administrator has disabled IMAP for your domain from this IP"?
|
|
|
|
More examples that we send at this point (most of these also have further
|
|
information, this is a shortened version):
|
|
- [AUTHENTICATIONFAILED] Invalid credentials
|
|
- [ALERT] Your account is not ready for IMAP use. (this was historical and
|
|
unlikely to be sent to anyone anymore)
|
|
- [ALERT] Your account is not enabled for IMAP use.
|
|
- [ALERT] IMAP access is disabled for your domain.
|
|
- [ALERT] IMAP access to your domain is not allowed from this IP
|
|
- [ALERT] Account exceeded command or bandwidth limits.
|
|
- [ALERT] Too many simultaneous connections.
|
|
- [ALERT] Application-specific password required:
|
|
- [ALERT] Please log in via your web browser:
|
|
- [ALERT] Web login required:
|
|
|
|
As for the WEBALERT case, its expected that the correct thing to do is to
|
|
send the user to the url specified, but it has to be the user, they're
|
|
likely to have to authenticate the session.
|
|
|
|
Half of the above would be UNAVAILABLE or maybe CONTACTADMIN, some would be
|
|
LIMIT/OVERQUOTA... but its unclear how much "clearer" these would be if
|
|
they're translated to the user's language via a "generic" category.
|
|
|
|
We have debated having a per-message unique identifier, also useful when
|
|
people contact us about which error they're seeing, but haven't exposed it.
|
|
I'd say we could translate these with our upcoming support for UTF8, but
|
|
these are almost assuredly seen prior to any ENABLE that would help.
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140902/525d3e20/attachment.html>
|