dr inż. Jurand BIEŃ
Instytut Zaawansowanych Technologii Energetycznych
Wydział Inżynierii Środowiska i Biotechnologii
Politechnika Częstochowska
ul. J.H.Dabrowskiego 73; 42-200 Częstochowa
tel/fax: 34 3250-933
e-mail: jurand@fluid.is.pcz.pl
Lumir, sorry for the delay. You can always apply the patch by hand. The change that caused your failures is fairly minor. However, please find attached an updated version of the patch that will apply cleanly to 1.4.23. People using 1.4.22, please use "version_2" of the patch, found earlier in this tracker.
patching file functions/i18n.php
Hunk #2 FAILED at 186.
1 out of 2 hunks FAILED -- saving rejects to file functions/i18n.php.rej
patching file functions/strings.php
Hunk #1 FAILED at 1489.
Hunk #2 FAILED at 1500.
Hunk #3 FAILED at 1508.
3 out of 3 hunks FAILED -- saving rejects to file functions/strings.php.rej
Posting in HTML is not helpful. IIRC, I tested version 2 of the patch against vanilla 1.4.22 so you appear to have modified your code. If you make modifications, you're going to have to take responsibility for applying patches yourself. Go into the patch file and make the changes manually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't modify any SM code.
I checked modified dates of all SM files.
All are the original but
config/config.php
config/config.pl
functions/i18n.php (this has commented changes made by the patch)
I manually replaced this in i18n.php
- if (! $save_html) $string = sm_encode_html_special_chars ($string);
+ if (! $save_html) $string = sm_encode_html_special_chars($string, ENT_COMPAT, $charset);
But I was enable to make patches on functions/strings.php
My strings.php has 1459 lines but the patch file has changes in lines 1489, 1500 and 1508
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apologies, I thought I had tested the creation of a patch for 1.4.22, but that was something else.
I've attached a patch that I verified should apply to 1.4.22, but I did not actually run the code. 1.4.22 has many other changes, some of which relate to this issue, so if this doesn't fix the problem for you, you should really be using 1.4.23
I found a related problem.
I've sent and replayed emails from SM to myself with accented vowels both in the body and the subject and all went fine.
The issue comes when replying from SM a mail replayed from Thundirbird (client email) that was prevously sent from SM. The problem is only in the subject.
Here are screenshots from SM and Thundirbird of previous and received subjects.
We'd have to see the configuration you have in SquirrelMail, the full headers for each broken message, etc. There have been several important fixes in 1.4.23, so if you want this kind of detailed accuracy, I suggest you begin by installing that. If you still see this problem, feel free to post to our mailing list or create a new tracker with as much data as you can possibly provide so we can reproduce.
Thanks for your interest and effort!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote an email in Thunderbird and opened it in SM
Here's the source from SM
Return-Path:
X-Original-To:
Delivered-To:
Received: from [192.168.1.134]...
...(Postfix) with ESMTPA id 667B71CA077C
for ... Tue, 3 May 2016 19:54:27 -0300 (UYT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=...;
s=default; t=1462316067;
bh=HcrYO2239Enhpg6JpMbCg0UgebzksFH2dlxA/hYyWeE=;
h=To:From:Subject:Date;
b=AiTivQOsgrk5h7gzTMbKPUcIVU8jP3UhSHq5YjTr2AG5qfCZIrNzH0/IvzH4nAxFt
IUSSGJ6ObCGAzuhf0QojUYPaspsXjiCWz7Ca9AsVLzZPCqVT+ueiR3dOYW9RlngF/m
Bk9QyfJzyqNd4f9x1JOFN5qZmsAeZe1XH/LzUSwE=
To: ...
From: ...
Subject: =?UTF-8?B?RWwgcGXDscOzbg==?=
Message-ID: ...
Date: Tue, 3 May 2016 19:54:10 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="------------080007060304030309090407"
This is a multi-part message in MIME format.
--------------080007060304030309090407
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000099">
Se llenó de ñandúes o ñandús o ñanduces
</body>
</html>
Here's how it looks when I open it in SM.
Green highlights = good
Red higlights = bad
I think this may be caused by the user account having selected the es_ES language setting in their display preferences (and/or $default_charset in config.php), which is currently provided in iso-8859-1. If you try in utf-8 (or change the charset Thunderbird uses when sending), I suspect the problem will go away.
SquirrelMail translations will be changed to utf-8 in the near future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, I cannot get any of the patches to solve the issue after upgrading to PHP 7 (specifically 7.0.16 from Debian packages).
Version 2 of the patch applies cleanly on top of the last 1.4.23 SVN release made in Debian before the package was pulled (svn20120406), and version 3 applies cleanly against relevant files in latest 1.4.23 from SVN (20170417_0200-SVN). Running the same Squirrelmail setup under PHP 5.6.30 makes everything work fine, leading me to suspect further changes may be needed to get things working in PHP 7.
This appears to apply to any QP-encoded subject or sender in a non-UTF-8 charset (or at least ISO-8859-1).
I found that there is a preg_replace with a /e flag in line 706 of mime.php. This line needs to be updated to preg_replace_callback to work with PHP 7. If anyone is still interested in this bug, let me know and I will post the replacement line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At long last, I've committed these patches to our repositories. There is a more accurate but costly way to try and carefully make the needed charset conversions, but I haven't seen evidence that anyone needs them -- it may be that the loss/munging of a few characters as provided by the simplified/naive charset override is not noticed or is tolerable for most. If anyone notices this munging, it would be interesting if the other approach can be completed and tested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's on the previous page, named "quoted_printable_fix-1.4.x-version_2.diff"
Thanks a lot.
Best regards
Jurand Bien
Dnia 7 Czerwca 2015, 19:49, N, Paul Lesniewski napisał(a):
Pozdrawiam
Jurand Bień
dr inż. Jurand BIEŃ
Instytut Zaawansowanych Technologii Energetycznych
Wydział Inżynierii Środowiska i Biotechnologii
Politechnika Częstochowska
ul. J.H.Dabrowskiego 73; 42-200 Częstochowa
tel/fax: 34 3250-933
e-mail: jurand@fluid.is.pcz.pl
Related
Bugs:
#2806patch -p0 < quoted_printable_fix-1.4.x-version_2.diff
patching file functions/i18n.php
patching file functions/strings.php
Hunk #1 succeeded at 1489 with fuzz 2.
Hunk #2 FAILED at 1506.
Hunk #3 FAILED at 1514.
2 out of 3 hunks FAILED -- saving rejects to file functions/strings.php.rej
am I doing something wrong?
sq version 1.4.23SVN downloaded yeasterday
Lumir, sorry for the delay. You can always apply the patch by hand. The change that caused your failures is fairly minor. However, please find attached an updated version of the patch that will apply cleanly to 1.4.23. People using 1.4.22, please use "version_2" of the patch, found earlier in this tracker.
Thank you,
I did apply the patch by hand afterwards.
But thank you anyway for the reply.
With the patch I have no more complains...
Updated patch for 1.5.x
Hello,
I copy-paste a message I've sent to squirrelmail SM-I18N group I sent on Feb 24 and got no answer.
Hello Paul,
I tried to apply this patch
For 1.4.22, use quoted_printable_fix-1.4.x-version_2.diff
uploaded to the public main SM directory
patch -p1 < quoted_printable_fix-1.4.x-version_2.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|Index: functions/i18n.php
|===================================================================
|--- functions/i18n.php (revision 14363)
|+++ functions/i18n.php (working copy)
File to patch: ^C
Then I tried with
patch -p0 < quoted_printable_fix-1.4.x-version_2.diff
patching file functions/i18n.php
Hunk #2 FAILED at 186.
1 out of 2 hunks FAILED -- saving rejects to file functions/i18n.php.rej
patching file functions/strings.php
Hunk #1 FAILED at 1489.
Hunk #2 FAILED at 1500.
Hunk #3 FAILED at 1508.
3 out of 3 hunks FAILED -- saving rejects to file functions/strings.php.rej
.rej file content:
--- i18n.php (working copy)
+++ i18n.php (revision 14363)
@@ -184,7 +182,7 @@
}
if (! $save_html) $string = sm_encode_html_special_chars ($string);
$charset = strtolower($charset);
set_my_charset();
Thank you
Posting in HTML is not helpful. IIRC, I tested version 2 of the patch against vanilla 1.4.22 so you appear to have modified your code. If you make modifications, you're going to have to take responsibility for applying patches yourself. Go into the patch file and make the changes manually.
I didn't modify any SM code.
I checked modified dates of all SM files.
All are the original but
config/config.php
config/config.pl
functions/i18n.php (this has commented changes made by the patch)
I manually replaced this in i18n.php
- if (! $save_html) $string = sm_encode_html_special_chars ($string);
+ if (! $save_html) $string = sm_encode_html_special_chars($string, ENT_COMPAT, $charset);
But I was enable to make patches on functions/strings.php
My strings.php has 1459 lines but the patch file has changes in lines 1489, 1500 and 1508
Apologies, I thought I had tested the creation of a patch for 1.4.22, but that was something else.
I've attached a patch that I verified should apply to 1.4.22, but I did not actually run the code. 1.4.22 has many other changes, some of which relate to this issue, so if this doesn't fix the problem for you, you should really be using 1.4.23
Great!
It works.
I manually added comments and the new function.
One small detail: pasted strings.php code was after line 1956, not 1955.
Thank you
I found a related problem.
I've sent and replayed emails from SM to myself with accented vowels both in the body and the subject and all went fine.
The issue comes when replying from SM a mail replayed from Thundirbird (client email) that was prevously sent from SM. The problem is only in the subject.
Here are screenshots from SM and Thundirbird of previous and received subjects.
SM
http://postimg.org/image/dn0rpkegn/
Thunderbird
http://postimg.org/image/6wvhzmas5/
http://postimg.org/image/t7jczl82d/
Even worse, continuing replying from Thundirbird and the last reply from SM
http://postimg.org/image/jk10ixgl3/
Last edit: dstonek 2016-04-05
We'd have to see the configuration you have in SquirrelMail, the full headers for each broken message, etc. There have been several important fixes in 1.4.23, so if you want this kind of detailed accuracy, I suggest you begin by installing that. If you still see this problem, feel free to post to our mailing list or create a new tracker with as much data as you can possibly provide so we can reproduce.
Thanks for your interest and effort!
Hi Paul.
I've upgraded to 1.4.23
I only had to copy config.php and locale ES dir
I also applied this patch https://sourceforge.net/p/squirrelmail/bugs/_discuss/thread/feebafb3/f2f7/2c33/attachment/quoted_printable_fix-1.4.x-version_3.diff
(by hand to both i18n and strings.php)
I wrote an email in Thunderbird and opened it in SM
Here's the source from SM
Here's how it looks when I open it in SM.
Green highlights = good
Red higlights = bad
http://i.cubeupload.com/SqU8fy.png
and here is when I reply the message. Notice that signature with an accented vowel is correct
http://i.cubeupload.com/N5EQNo.png
I don't know what else to do.
Thanks
Last edit: dstonek 2016-05-06
I think this may be caused by the user account having selected the es_ES language setting in their display preferences (and/or $default_charset in config.php), which is currently provided in iso-8859-1. If you try in utf-8 (or change the charset Thunderbird uses when sending), I suspect the problem will go away.
SquirrelMail translations will be changed to utf-8 in the near future.
Unfortunately, I cannot get any of the patches to solve the issue after upgrading to PHP 7 (specifically 7.0.16 from Debian packages).
Version 2 of the patch applies cleanly on top of the last 1.4.23 SVN release made in Debian before the package was pulled (svn20120406), and version 3 applies cleanly against relevant files in latest 1.4.23 from SVN (20170417_0200-SVN). Running the same Squirrelmail setup under PHP 5.6.30 makes everything work fine, leading me to suspect further changes may be needed to get things working in PHP 7.
This appears to apply to any QP-encoded subject or sender in a non-UTF-8 charset (or at least ISO-8859-1).
Relevant config portions:
$squirrelmail_default_language = 'en_US';
$default_charset = 'utf-8';
$lossy_encoding = false;
default_charset = "UTF-8" is set in Apache's php.ini for both PHP5 and 7.
Appreciate your efforts so far here, please let me know if there's anything I can provide (or try) to help.
I found that there is a preg_replace with a /e flag in line 706 of mime.php. This line needs to be updated to preg_replace_callback to work with PHP 7. If anyone is still interested in this bug, let me know and I will post the replacement line.
It's not like that here. What is the date of the SVN source you are reading?
1.4.23~svn20120406-2+deb7u2
Debian 9.4
I'm sorry if I didn't follow accepted protocol.
I suggest to move to a more recent SVN.
BTW there are two issues open for PHP 7.2, but it's working:
https://sourceforge.net/p/squirrelmail/bugs/2847/
https://sourceforge.net/p/squirrelmail/bugs/2848/
At long last, I've committed these patches to our repositories. There is a more accurate but costly way to try and carefully make the needed charset conversions, but I haven't seen evidence that anyone needs them -- it may be that the loss/munging of a few characters as provided by the simplified/naive charset override is not noticed or is tolerable for most. If anyone notices this munging, it would be interesting if the other approach can be completed and tested.
Thanks for all that helped on this ticket in the past -- much appreciated!