Dev July 2018

dev@lists.roundcube.net

2 participants
3 discussions

Update 1.3.7 released
by Thomas Bruederli 27 Jul '18

27 Jul '18

Dear subscribers We proudly announce the next service release to update the stable version 1.3. It contains fixes to several bugs backported from the master branch including a security fix mitigating the EFAIL issue recently discovered in OpenPGP. See the full changelog in the release notes on the Github download page [1]. This release is considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from https://roundcube.net. And there are more good news ahead: the long awaited responsive theme for Roundcube, codename "elastic", has now matured and we'll publish a beta release with the new skin soon. For a quick preview you can already pull the Docker container roundcube/roundcubemail:elastic which bundles the current git master version with the elastic theme enabled. Best, Alec & Thomas [1] https://github.com/roundcube/roundcubemail/releases/tag/1.3.7

1 0

Problem with mixed charsets
by Vladimir Gorpenko 16 Jul '18

16 Jul '18

Unfortunately, I was inaccurate and used not quite correct ways of saving the attached file. That is, if I saved the attachment with RC menu, everything works correctly. But if I tried to view the attachment or save it by browser command, then the embedded html file is displayed and stored incorrectly. The Hex codes of ciryllic leters are different when I saved them with RC and browser commands. The fact that the RC command "save" is output as D0 A1 D0 BE D1 81 , when saved by the browser (and, probably, when displayed) has the value D0 A0 D0 8E D0 A0. However, it seems that this newsletter has already died and I'm trying in vain. -- Best regards, Vladimir Gorpenko

1 0

Problem with mixed charsets
by Vladimir Gorpenko 12 Jul '18

12 Jul '18

Hello! We are using RC 1.1.4. I understand that this is an old version, and it is not supported. I ask you to see my questions at the end of the letter. A problem was detected with Symantec Endpoint Protection (SEP) reports. The old version of the SEP generated reports in the form of letters with an attached file, and the attached file was supplied in a base64 coding. This worked fine. The new version forms reports in the form of a multipart letter with directly included HTML code. In this case, for the letter as a whole, the charset is not specified. The first part of the letter has such headings: Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 The second part of the letter has such headings: Content-Type: text/html; charset=Cp1251; name="=?UTF-8?B?0JXQttC10LTQvdC10LLQvdGL0Lkg0LjRgtC+0LPQvtCy0Ys=?= =?UTF-8?B?0Lkg0L7RgtGH0LXRgiDQtNC70Y8g0LDQtNC80LjQvdC4?= =?UTF-8?B?0YHRgtGA0LDRgtC+0YDQsF8xMS4wNy4yMDE4IDctMDAtMjEgNDg3Lmh0bWw=?=" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="=?UTF-8?B?0JXQttC10LTQvdC10LLQvdGL0Lkg0LjRgtC+0LPQvtCy0Ys=?= =?UTF-8?B?0Lkg0L7RgtGH0LXRgiDQtNC70Y8g0LDQtNC80LjQvdC4?= =?UTF-8?B?0YHRgtGA0LDRgtC+0YDQsF8xMS4wNy4yMDE4IDctMDAtMjEgNDg3Lmh0bWw=?=" Content-ID: 654=52=K9 8B>3>2K9 >BG5B 4;O 04<8=8AB@0B>@0_11.07.2018 7-00-21 487.html RC correctly displays the body of the letter, that is, the first part. Also, the RC shows that there is an attached file of type xml. However, the RC does not correctly save this attached file and, as a consequence, incorrectly opens it. First, the size of saved file is about a quarter less than the attached one. Secondly, in content, it sharply differs from the same file saved from the same letter with the help of Thunderbird. Questions: 1. Was such a mistake detected and corrected in the later versions of the RC? 2. Is there any reason to consider the report formed by the SEP as incorrectly formed? 3. Are there any settings in the RC that can fix this error? -- Best regards, Vladimir Gorpenko

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev July 2018