MBOX-Line: From MRC at Washington.EDU  Tue Feb  5 13:53:26 2008
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@Washington.EDU>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] non-ASCII byte sequences in IMAP?
In-Reply-To: <lpAcVvMb9aegwsaoYFELvw.md5@libertango.oryx.com>
References: <"08Feb3. 133012pst. 58696"@synergy1.parc.xerox.com>
	<3/ZsgW8xag0zKO8asER9/Q.md5@libertango.oryx.com> <"08Feb5.
	091040pst. 58696"@synergy1.parc.xerox.com>
	<rr9fu1gL3aYp0C0eYZ33eQ.md5@libertango.oryx.com>
	<lpAcVvMb9aegwsaoYFELvw.md5@libertango.oryx.com>
Message-ID: <alpine.WNT.1.00.0802051341000.3096@Tomobiki-Cho.CAC.Washignton.EDU>

On Tue, 5 Feb 2008, Arnt Gulbrandsen wrote:
> 8-bit occurs elsewhere too. LOGIN is just an example. Another reasonable 
> example is FETCH BODYSTRUCTURE: If the sender of a message includes 8-bit 
> characters where none are permitted, a compliant and well-behaved IMAP server 
> asked to serve that message is often up the creek.

I do not believe that a server which takes the position of "garbage in, 
garbage out" fails in any way of being "compliant and well-behaved."

I believe that FAR more harm is done by an implementation which, in a 
well-intentioned effort to "fix" garbage, renders what was once usable 
into non-usability.  This opinion of mine predates IMAP by many years, 
when I had to deal with sendmail implementations that "fixed" headers 
(that did not need fixing, just that sendmail didn't grok the syntax in 
question) into complete nonsense.

The IMAP specification does NOT have any syntax that requires that text in 
an ENVELOPE or BODYSTRUCTURE be ASCII; only that any octets greater than 
0x7f be transmitted in a literal.

Data in ENVELOPE and BODYSTRUCTURE is ASCII because that is the way it is 
in the underlying specifications (2822 and MIME).  But as news (foolishly) 
took a "just send 8-bits" position in message headers, non-ASCII is going 
to show up anyway.

This is a case where Postel's robustness principle applies, but it must be 
applied carefully:

You SHOULD avoid sending non-ASCII for fields that are not defined to be 
possibly non-ASCII.  But don't "fix" non-ASCII data that you did not 
originate into ASCII; better to pass the blame for the brokeness to the 
originator than to risk breaking it yourself.

You SHOULD expect non-ASCII for fields that are explicitly defined to be 
ASCII; and you MUST expect non-ASCII for fields that are defined to be 
possibly non-ASCII or where there is no explicit definition.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

