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


