40 lines
1.9 KiB
Plaintext
40 lines
1.9 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Wed Sep 17 03:23:56 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: <14D026C7F297AD44AC82578DD818CDD034516112A0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.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>
|
|
<00bd4f8b-cc4e-48b9-8aad-6788e23666af@gulbrandsen.priv.no>
|
|
<CABa8R6vYYpbkV56=b6ydu7peJfdBDVnbUa70dvvEyd_H9NdjEQ@mail.gmail.com>
|
|
<14D026C7F297AD44AC82578DD818CDD034516112A0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
|
Message-ID: <27b2d77f-d522-4f52-82ee-bcac200175fd@gulbrandsen.priv.no>
|
|
|
|
On Tuesday, September 16, 2014 10:43:16 PM CEST, Neil Hunsperger wrote:
|
|
> To elaborate on Brandon?s point, the issue is with following
|
|
> IMAP?s ABNF. Base RFC 3501 strings are CHAR-based instead of
|
|
> CHAR8-based. A UTF-8 response might not ever reach the client if
|
|
> there is an IMAP proxy such as Symantec Desktop Email between
|
|
> the client and server. I would strongly consider ensuring that
|
|
> all server output can be parsed using the ABNF currently agreed
|
|
> upon by the client and server.
|
|
|
|
1. This is about errors. There isn't much to lose if you're already in an
|
|
error situation. As I said, the chance seems slight that the client could
|
|
recover, but fails to recover merely because the human-readable text
|
|
contains bytes outside the legal range.
|
|
|
|
2. Would you make the same argument about the other major grammar involved
|
|
in IMAP: RFC5322? Or do you think it's okay for a server to just-send-8
|
|
when a message violates the rules of RFC5322 and the client hasn't
|
|
indicated that it can accept that?
|
|
|
|
Arnt
|
|
|
|
|