On Thu, 6 Oct 2005, Shawn Walker wrote:
We have a from address that has:
From: =?UTF-8?Q? Fr=C3=A9d=C3=A9ric ?= <[EMAIL PROTECTED]>"
utf8_mime2text() can't decode that, if there is no spaces in the encoding
such as
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric?= <[EMAIL PROTECTED]>"
utf8_mime2text() decodes it just fine.
That behavior is intentional and correct. The first paragraph of RFC 2047
section 2 states that "white space characters MUST NOT appear between
components of an 'encoded-word'."
Later on in section 2, we find:
IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
by an RFC 822 parser. As a consequence, unencoded white space
characters (such as SPACE and HTAB) are FORBIDDEN within an
'encoded-word'. For example, the character sequence
=?iso-8859-1?q?this is some text?=
would be parsed as four 'atom's, rather than as a single 'atom' (by
an RFC 822 parser) or 'encoded-word' (by a parser which understands
'encoded-words'). The correct way to encode the string "this is some
text" is to encode the SPACE characters as well, e.g.
=?iso-8859-1?q?this=20is=20some=20text?=
RFC 2047 also permits the use of "_" instead of "=20", so that example can
also be stated as:
=?iso-8859-1?q?this_is_some_text?=
In conclusion, the problem is with the the entity that generated that From
address, not with c-client.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
