89 lines
3.4 KiB
Plaintext
89 lines
3.4 KiB
Plaintext
MBOX-Line: From angel at 16bits.net Wed Sep 3 13:02:32 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <angel@16bits.net>
|
|
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: <CABa8R6vJUAo231ECkLyDsTmk08UGgS2E7i6SNZ==x6YwFOiPUw@mail.gmail.com>
|
|
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>
|
|
Message-ID: <1409774552.1122.3.camel@16bits.net>
|
|
|
|
El mar, 02-09-2014 a las 14:09 -0700, Brandon Long escribi?:
|
|
>
|
|
>
|
|
>
|
|
On Sat, Aug 30, 2014 at 2:02 PM, Arnt Gulbrandsen:
|
|
> 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"?
|
|
|
|
Instead of a RFC listing each error, that's more suited for creating a
|
|
registry of error codes. Although the idea of using a wiki seems better
|
|
than placing it at IANA.
|
|
|
|
|
|
|
|
>
|
|
> 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,
|
|
|
|
I'm not too keen about providing translated messages unrequested.
|
|
|
|
|
|
> but these are almost assuredly seen prior to any ENABLE that would
|
|
> help.
|
|
|
|
Specially given that you can only use ENABLE in the authenticated state.
|
|
|
|
<random ideas>
|
|
It may be worth taking into account SMAP 'LANG' capability announcing if
|
|
creating an extension for handling that. A extension for supporting
|
|
translated messages might be:
|
|
|
|
The server exposes the capability by announcing a series of
|
|
LANG=<langtag> tokens on its CAPABILITY. <langtag> is a language tag as
|
|
defined by RFC 1766. Providing just LANG means the server supports some
|
|
translations but is not providing the full list.
|
|
|
|
The client requests internationalization of the messages with <tag> LANG
|
|
<langcode>. An untagged response is provided with the actual language
|
|
chosen by the server (eg. the user requested EN-COCKNEY but the server
|
|
provided EN-GB)
|
|
|
|
'<tag> LANG ?' could be used for requesting a list of languages
|
|
supported by the server.
|
|
|
|
And '<tag> LANG' for declaring support for the extension but stating no
|
|
preference. The server may choose a language based on an account
|
|
setting, a default for its domain, ip geolocation, etc. Note that the
|
|
server may decide to send an untagged LANG after login.
|
|
|
|
|
|
1- http://www.courier-mta.org/cone/smap1.html
|
|
|
|
|