48 lines
2.3 KiB
Plaintext
48 lines
2.3 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Thu Sep 25 03:47:12 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: <14D026C7F297AD44AC82578DD818CDD0345161158B@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>
|
|
<27b2d77f-d522-4f52-82ee-bcac200175fd@gulbrandsen.priv.no>
|
|
<14D026C7F297AD44AC82578DD818CDD0345161158B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
|
Message-ID: <6feaea46-12c8-44a3-aab5-cc11a494b528@gulbrandsen.priv.no>
|
|
|
|
Neil Hunsperger answers me:
|
|
> 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.
|
|
|
|
That's true, but that doesn't follow 5322's syntax, and I don't see any
|
|
permission in 3501 to ignore what 5322 says. Or 2822, or 4422/2222, or...
|
|
|
|
The case Brandon has is similar: The client introduces a violation and the
|
|
server's straightforward error response propagates that. I did the same
|
|
this summer, when I decided that if a client sends an errant SMTP command
|
|
that includes non-ASCII, that client grants the server permission to use
|
|
non-ASCII in the error message too (in the code I wrote that would be
|
|
"parse error near ?re", "will not relay to ?re@v?re.h?ye" or similar).
|
|
|
|
> 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.
|
|
|
|
No, I'm asking whether you have a sensible argument for arguing that the
|
|
server must take the MUSTs in some RFCs seriously and can ignore the MUSTs
|
|
in others.
|
|
|
|
Arnt
|
|
|
|
|