102 lines
4.6 KiB
Plaintext
102 lines
4.6 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Wed Sep 3 04:17:05 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
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: <00bd4f8b-cc4e-48b9-8aad-6788e23666af@gulbrandsen.priv.no>
|
|
|
|
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.
|
|
|
|
> 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.
|
|
|
|
Exactly. I knew that and thought most people did. I understand now that I
|
|
should have added a note to 5530 pointing it out. Sorry. I didn't, because
|
|
5530 is about server to client communications, and ALERT is intended for
|
|
when the server wants to bypass the client's state machine and speak to the
|
|
user.
|
|
|
|
> We did go through and
|
|
> update most of the login errors (and others) to correspond to
|
|
> the 5530 codes where there was a match.
|
|
|
|
I've noticed. Good work.
|
|
|
|
> 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.
|
|
|
|
> 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"?
|
|
|
|
Not quite that detailed, but something along those lines, yes, I think so.
|
|
The servers I based 5530 on didn't have a difference between the gmail god
|
|
and the customer's domain administrator and no ability to create problem
|
|
tickets, otherwise I expect CONTACTADMIN would have been a bit richer.
|
|
Perhaps: [PROBLEM issue-id contact-url], with the URL indicating at least
|
|
whom to contact, and the issue-id being something that enables the
|
|
contacted party to look up the problem.
|
|
|
|
> 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.
|
|
|
|
I disagree...
|
|
|
|
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.
|
|
|
|
Arnt
|
|
|
|
|