57 lines
2.6 KiB
Plaintext
57 lines
2.6 KiB
Plaintext
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.
|
|
|