39 lines
2.5 KiB
Plaintext
39 lines
2.5 KiB
Plaintext
MBOX-Line: From Neil_Hunsperger at symantec.com Wed Sep 17 10:57:36 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Neil Hunsperger <Neil_Hunsperger@symantec.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
|
|
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>
|
|
<27b2d77f-d522-4f52-82ee-bcac200175fd@gulbrandsen.priv.no>
|
|
Message-ID: <14D026C7F297AD44AC82578DD818CDD0345161158B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
|
|
|
> 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.
|
|
|
|
[snip]
|
|
|
|
> 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
|
|
|
|
That's a great question about avoiding propagating existing protocol violations. My goal was to avoid introducing more protocol violations. Looking at the IMAP fetch responses, it appears to me that the server can always send the original email content in a literal to follow RFC 3501's own syntax. If somewhere in RFC 3501 there were email content transmitted to the client where a literal isn't allowed, then yes I would make the same argument.
|
|
|
|
I'm not sure if you were asking about a server deeply parsing email content for the purpose of protecting the client from 8-bit content found where RFC 5322 disallows it. If so, I would suggest leaving in the syntax errors and letting the client take a guess at how to render it. Most of the unlabeled high bytes I've seen in headers were ISO-8859-1 instead of UTF-8 anyway. I've seen clients recover from this issue.
|