85 lines
3.6 KiB
Plaintext
85 lines
3.6 KiB
Plaintext
MBOX-Line: From mrc+imap at panda.com Sun Jul 11 11:02:00 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc+imap@panda.com>
|
|
Date: Fri Jun 8 12:34:45 2018
|
|
Subject: [Imap-protocol] Re: folding/encoding of subject in ENVELOPE
|
|
In-Reply-To: <4C397959.5090606@sun.com>
|
|
References: <4C37C781.5060700@sun.com>
|
|
<FCB729DF-4574-4EA5-BA6C-B21F5B67B9D1@iki.fi>
|
|
<alpine.BSF.2.00.1007091831130.49338@legolas.orthanc.ca>
|
|
<alpine.WNT.2.00.1007091852190.2580@Shimo-Tomobiki.Panda.COM>
|
|
<4C397959.5090606@sun.com>
|
|
Message-ID: <alpine.WNT.2.00.1007110934440.5552@Shimo-Tomobiki.Panda.COM>
|
|
|
|
On Sun, 11 Jul 2010, Bill Shannon wrote:
|
|
> Ok, so now I'm confused.
|
|
|
|
And you're asking questions instead of making assumptions. Good! Thank
|
|
you!
|
|
|
|
> The server is required to interpret and remove some parts of the encoding
|
|
> (i.e., folding) but not other parts (MIME encoded words)?
|
|
|
|
Not the way that I would put it, but basically yes.
|
|
|
|
IMAP ENVELOPE was always intended to be a canonicalized representation of
|
|
the fields in the RFC 822 (and successor) headers. Line folding is an RFC
|
|
822 transmission representation; it does not actually represent a newline
|
|
in the field. And, if you read RFC 822 carefully, you will discover that
|
|
headers can (and in practice are) rewritten with completely different line
|
|
folds than the original sender's composition.
|
|
|
|
As for MIME encoded words, you are quite correct that this is a wart and a
|
|
violation of my intentions. However, the ENVELOPE is 7-bit (having
|
|
preceded MIME encoded words by several years) and thus can not transport
|
|
the 8-bit content necessary to do this. Also, in the case of a MIME
|
|
encoded word that references a charset unknown to the server, the server
|
|
can not resolve it into UTF-8. Thus, even in a future world where these
|
|
would be resolved, there is still the possibility of the odd encoded word
|
|
coming through.
|
|
|
|
However, since only the server can truly handle encoded words properly (at
|
|
the client level, it is ambiguous whether it's an encoded word or a quoted
|
|
string that looks like an encoded word), I hope to have server-based
|
|
decoding of encoded words in the future.
|
|
|
|
> I should *never* expect to see a newline in the subject field of the
|
|
> ENVELOPE, and if I do that's a bug in the server?
|
|
|
|
Yes. However, IMAP does not specifically forbid it. So clients should
|
|
not crash when they encounter a newline in any ENVELOPE member, and cope
|
|
with it in some way. Some will truncate display of any field after a
|
|
newline (e.g., a message index display).
|
|
|
|
> Or is unfolding the header something servers are allowed to do but not
|
|
> required to do?
|
|
|
|
"Allowed" is a very wide word.
|
|
|
|
An ssh server is "allowed" to treat an invalid password attempt as a
|
|
command to destroy the account and all its files. I assume that we all
|
|
agree that this would be a very bad thing for the server to do.
|
|
|
|
Subjects are not defined to contain newlines. Remember that RFC 822 line
|
|
folding is to fold long lines for transport, and NOT to embed newlines.
|
|
They can be rewritten at any time with folding in completely different
|
|
places.
|
|
|
|
A client is "allowed" to treat a newline in the subject part of an
|
|
ENVELOPE as an instruction to format the user's hard drive. Once again,
|
|
that would be a very bad thing.
|
|
|
|
Perhaps what you what to say instead of "allowed" is "what implementations
|
|
that want to be more than a piece of crap will do"...
|
|
|
|
IMAP was designed in a kinder, gentler time when people cared about making
|
|
servers do the right thing, instead of inflicting whatever filth they
|
|
wanted upon the world.
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Science does not emerge from voting, party politics, or public debate.
|
|
Si vis pacem, para bellum.
|
|
|