Squirrelmail doesn't decode properly multi-line subjects.
For example, the ASCII version of an e-mail sent to Squirrelmail:
The decodeheader i18n option doesn't handle newlines, or tabs at the beginning
of the lines:
- $ret = str_replace("\t", "", $ret);
+ $ret = str_replace(array("\t", "\n"," "), "", $ret);
Patch from Hideshi Fuchi <email@example.com>
Created attachment 137633 [details]
Is this broken in RHEL3 but not RHEL4?
Either way, *PLEASE* submit this patch and have upstream accept it.
Could you attach encoded header instead of pasting it in bug report? I suspect
that some data is lost.
If header looks same way as in bug report, could you explain why encoded word is
splitted into two lines and why there is no separator between two atoms? With
appropriate references to rfcs.
rfc 2047 states that "'encoded-word's are designed to be recognized as 'atom's
by an RFC 822 parser". According to rfc822 atoms are separated with single
space. They don't look separated in your bug report.
This issue should be fixed squirrelmail-1.4.8-5.el3
You can't fix it in SquirrelMail, because bug is not in SquirrelMail.
provided Subject (multi)line seems wrong. It is not decoded correctly even in
Evolution/Sylpheed, so I used this, slightly modified:
But this one is OK everywhere, SquirrelMail works correctly with it. Please
could you attach Subject (multi)line which causes problems and description of
Thanks in advance,
header in original report contains incorrectly encoded mixed Japanese and ASCII
characters. Probably incorrect decision by some smart mime header encoding
function. No spaces between atoms and incorrect multiline wrapping.
When you modified header, you've removed ASCII chars.
I suspect that header contains encoded "あ a い i う u え e お o" or "あaいiうu
えeおo" text. Depends on how broken mime encoder is.
Header is generated with SquirrelMail Japanese translation. Create message with
"あaいiうuえeおo" subject and save it as draft. SquirrelMail has similar bug
report (#1693322). Fix proposed in bugzilla is not correct. Japanese XTRA_CODE
functions must be fixed.
Problem seems to be in foldLine() function in class/deliver/Deliver.class.php.
It tries to split long headers along RFC2047, but it has troubles with more than
one Japanese char separated by ASCII chars.
I rewrote foldLine() so that it split subject at right places, but since the
ascii chars are left as they are, we got some unwanted extra spaces in header
(like this あaいi うuえe おo). I hope that converting ascii chars to ISO-2022-JP
will help to avoid those extra spaces.
I tried to create mail with our subject in thunderbird and it produces this:
which is nice also according to RFC2047.
I'm not sure wahat is the preffered way to fix this for the upstream so I have
to consult them first.
I am not sure if there is a bug in foldLine. Invalid code is in
japanese_charset_xtra() function, encodeheader switch.
Header posted by Bastien Nocera can be generated with SquirrelMail in Japanese
translation. Before you change foldLine() make sure that header is encoded
(In reply to comment #18)
As I understand it, header is encoded properly (but not very nicely)
If it is not folded later most mail clients display the header properly.
Foldmethod as it is by now folds the header inside the multibyte atoms (it is
wrong). "Fixed" foldmethod folds the header on borders of atoms, but this adds
some extra spaces when interpreted by mail client.
I think the ideal way to fix this is to convert all chars in headers to either
ISO-2022-JP or UTF-8 or UNICODE. Unfortunatley I'm not very familiar with
encodings conversion so it will need some more investigation.
Patch provided was insufficient. Devel is working with the upstream community
however they do not expect to have a new patch by the 3.9 deadline.
Marco (GSS) checked with customer and they are happy with a php workaround.
The errata has been dropped from RHEL3-QU9.
Changed bugzilla status to CLOSED/WONTFIX.
If this continues to be an issue post 3.9 GA, feel free to reopen and raise for
an async errata.
Created attachment 154673 [details]
functions/i18n.php sm-1.4.10a patch
replaces 'encodeheader' code with simple non-smart encoding.
"Bad decoding of multiple Subjects" issue can't be fixed. rfc2047 - "6.3. Mail
reader handling of incorrectly formed 'encoded-word's" chapter.
A mail reader need not attempt to display the text associated with an
'encoded-word' that is incorrectly formed. However, a mail reader
MUST NOT prevent the display or handling of a message because an
'encoded-word' is incorrectly formed.
"Bad encoding issue" should be fixed in attached patch. Please note that I am
the one who wrote encodeHeaderBase64(). SquirrelMail has three header encoding
functions and I trust only encodeHeaderBase64(). Patch requires SquirrelMail
1.4.6 and php mbstring extension with Japanese support. If patch is applied to
older SquirrelMail version, you must port related functions. If code executed on
PHP install without mbstring support, Japanese translation should fail on
Fix is simple. I have added blocks of comments in order to explain what I am
doing. If you need explanations why original code is broken, I can tag invalid
decisions made by original code.