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>
