MBOX-Line: From blong at google.com Tue Sep 2 14:09:47 2014 To: imap-protocol@u.washington.edu From: Brandon Long 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> <54011E24.4080209@mozilla.com> <6f3e9961-32e6-4b4b-866f-7ce5526b0bf8@gulbrandsen.priv.no> Message-ID: On Sat, Aug 30, 2014 at 2:02 PM, Arnt Gulbrandsen 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: