Dev November 2012

dev@lists.roundcube.net

27 participants
37 discussions

Replies to HTML messages
by Michael Heydekamp 28 Jan '13

28 Jan '13

I have set "Compose HTML messages" to "Never", because that is what I want. I'm a bit confused with regards to plain text replies to messages with a text/html and a text/plain part. Roundcube often (but not always) seems to quote the text/html part rather than the text/plain part. This often leads to really ugly replies/quotes with tons of useless/duplicated links at the end of the message (while the links within the message are sometimes being removed). See message attached. Is this intentional...? (Well, hopefully not) If replying to a HTML only message, Roundcube has of course no other choice than replying to the HTMl part. But in this case I'm still wondering why all links contained in the message are being duplicated at the end of the message with "[1]", "[2]" and so on, and sometimes even being removed within the message text (as can be seen with the attached message). It's a bit of an annoyance to remove these links at the end of the message and the "[1]", "[2]" etc. within the message text. Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?) Or is it a duplicate to "on reply to HTML message only"?. Last but not least, in very few and exceptional cases I'd indeed like to compose a HTML message when replying to a HTML message. Currently I see no other way than to change the option "Compose HTML messages", create the reply, and then reset "Compose HTML messages" back to "Never" (which I then sometimes forget, of course, and which is not too comfortable). Of course I can change the editor type AFTER clicking the reply button, but then all HTML tags of the quoted message are still lost. I currently have no good idea for a UI for this, but a function to reload the HTML part into the message editor (or to load the HTML part upfront after the user has - in which way ever - clearly stated that he exceptionally wants to create a HTML message) would just be great. Regards, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

4 15

New attachment mime-type validation
by Thomas Bruederli 12 Dec '12

12 Dec '12

Hello folks Today we introduced a new validation mechanism for message attachments which are supposed to be displayed inside the browser. Mainly inspired by a recently reported XSS vulnerability [1], the mime-types and filenames extensions stated in the message part headers are now checked against the real mime-type of the effective part bodies. This also requires the filename extension (e.g. ".png") to match the real mime-type of the according attachment. In order to reliably detect mime-types and the matching filename extensions, Roundcube and PHP need to be configured properly: On PHP >= 5.3, we recommend to set $rcmail_config['mime_magic'] = null; which lets the fileinfo module of PHP use its default location for the magic numbers mapping file. The other config option which is important for these new checks is $rcmail_config['mime_types'] = '<path-to-apache-config>/mime.types'; This value should refer to the mime.types file used by the Apache web server to send the right mime-types for static files. If left empty, Roundcube will search for it in some default locations such as /etc/httpd/mime.types but for performance reasons, it's better to set this option right away. In case you can't find such a file on your server, especially when not running apache, you can download it from [2]. Now, with the new attachment validation in place, your users might see some yellow warnings (see attached image) because sometimes email messages are just incorrectly formatted even if all the contents are safe. Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases. Cheers, Thomas [1] http://trac.roundcube.net/ticket/1488828 [2] http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

5 9

Re: [RCD] [Svn] [roundcube/roundcubemail] 30cc01: Use Delivered-To header as a last resort for identity selection (#1488840)
by Michael Heydekamp 09 Dec '12

09 Dec '12

Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this: > Delivered-To: dev-at-lists-dot-roundcube-dot-net(a)lists.roundcube.net So the identity still needs to be changed manually. Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages. Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO. Greets, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 28.11.2012 20:41, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: 30cc01f89daea932d15a1a505d25b543913664ac > > https://github.com/roundcube/roundcubemail/commit/30cc01f89daea932d15a1a505… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-11-28 (Wed, 28 Nov 2012) > > Changed paths: > M CHANGELOG > M program/lib/Roundcube/rcube_imap_generic.php > M program/lib/Roundcube/rcube_storage.php > M program/steps/mail/compose.inc > > Log Message: > ----------- > Use Delivered-To header as a last resort for identity selection (#1488840) > > > Commit: 0247b89c38c7f7ef1a2111239c6a1c8c13394d93 > > https://github.com/roundcube/roundcubemail/commit/0247b89c38c7f7ef1a2111239… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-11-28 (Wed, 28 Nov 2012) > > Changed paths: > M program/lib/Roundcube/rcube_user.php > M program/steps/mail/compose.inc > > Log Message: > ----------- > Move code for identity selection to function, move identities > formatting to rcube_user::list_identities() > > > Compare: > https://github.com/roundcube/roundcubemail/compare/511e1668e6f4...0247b89c3… > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

7 19

Ensure target folder exists before move
by Daniel Kahn Gillmor 06 Dec '12

06 Dec '12

Hi roundcube folks-- http://trac.roundcube.net/ticket/1486802 was about roundcube failures to move drafts, sent messages, and deleted messages into their proper folders. It looks to me like it was fixed for drafts and sent messages, but it was *not* fixed for deleted messages. I can't seem to convince http://trac.roundcube.net/ to let me have an account, but i think that ticket should be re-opened. I think the attached patch fixes the situation for the trash (as well as fixing any other attempt to move into a folder that doesn't exist). Arguably, you might also want to subscribe to the newly-created folder, and not just create it; but as a baseline, i think this is a reasonable patch against v0.8.4. Please let me know if there's anything i should do to help get this adopted, or if there's some reason that this patch itself is a bad idea. Thanks for roundcube, --dkg

4 8

Discrepancy/confusion with regards to file name encodings of attachments
by Michael Heydekamp 03 Dec '12

03 Dec '12

The Roundcube UI has the following options in terms of encoding file names of attachments: > Full RFC 2231 (Thunderbird) > RFC 2047/2231 (MS Outlook) > Full RFC 2047 (other) In main.inc.php, the explanation is different: > // Encoding of long/non-ascii attachment names: > // 0 - Full RFC 2231 compatible > // 1 - RFC 2047 for 'name' and RFC 2231 for 'filename' parameter (Thunderbird's default) > // 2 - Full 2047 compatible > $rcmail_config['mime_param_folding'] = 0; So what is true? Is "RFC 2047/2231" Outlook's (as the UI says) or Thunderbird's (as the config says) default? And what is the best option in terms of backwards compatibility...? Furthermore, this really shouldn't be a user-configurable option. RFC 2047/2231 are way too complex and hard to understand for an end-user. This should be set server-side only. I'm wondering how this option could make it into the UI. -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

3 5

Release 0.8 (stable) with new skin is out
by Thomas Bruederli 28 Nov '12

28 Nov '12

Hello folks, We're proud to finally announce the release of version 0.8 with the brand new skin, codename "Larry", becoming the new default UI for Roundcube. After two preview releases and a lot of fine-tuning, the new design by http://bueroflint.com has now grown up. But to all the nostalgics out there: don't worry! The old skin still remains part of the package and will be maintained for at least one more major release. Beside the new UI, this version also contains more bugfixes and mprovements (see ) as well as some code refactorings. Another major change since the last stable release is the updated license which is now GPL v3+ with exceptions for skin & plugins. Read more about that on http://roundcube.net/license After lots of testing and collecting your feedback, this version is considered stable and we recommend to update all productive installations of Roundcube. Get the new version from http://roundcube.net/download Finally, some important notes for sysadmins to deploy the new Roundcube: * The new skin brings an entirely new look to the webmail application. Please carefully plan a roll-out of the new version and prepare your users accordingly. * We're getting a lot of support requests from users who are under the impression that Roundcube is a public service such as Gmail or Hotmail. Unfortunately we cannot help these people and thus we'd like to encourage everybody to do some branding on your Roundcube installation. You can replace the logo by config (option 'skin_logo') and even more important: the new release now has an option named 'support_url' where everyone should fill in an URL to instructions how to get help for that specific installation of Roundcube. And last but not least: our recent partnership with the Kolab Groupware project is finally showing some results. The Kolab team just published a preview release of their all-new Kolab 3.0 groupware suite including Roundcube as the new web client. Enriched with nice new plugins, Roundcube gives easy access to all relevant groupware functions. Read more about Kolab at http://kolab.org/blog/grote/2012/08/07/alpha-kolab-3.0-and-roundcube-0.8-re… That's definitely worth celebrating, cheers! Thomas

11 48

New feature: display attached images as thumbnails...
by Michael Heydekamp 28 Nov '12

28 Nov '12

Well, THAT's a good and sense making feature, my compliments. Two comments: 1) It would IMHO be a good idea to indicate in some way that the images displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;) 2) Is it planned to provide a second link (next to the "Download" link), which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such). If 2) should not be planned yet, this should change. ;) Thanks again and regards, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 11.11.2012 14:11, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: 03149131f754dd122f8707fbfc9e7ff47e9d6524 > > https://github.com/roundcube/roundcubemail/commit/03149131f754dd122f8707fbf… > Author: Thomas Bruederli <thomas(a)roundcube.net> > Date: 2012-11-10 (Sat, 10 Nov 2012) > > Changed paths: > M config/main.inc.php.dist > M program/include/html.php > M program/include/rcube_image.php > M program/steps/mail/func.inc > M program/steps/mail/get.inc > M skins/classic/mail.css > M skins/larry/mail.css > M skins/larry/templates/messagepart.html > > Log Message: > ----------- > New feature: display attached images as thumbnails below message body > > > Commit: e43dcb0df3e7ea6c05a8c1473b0da7834d5e39d9 > > https://github.com/roundcube/roundcubemail/commit/e43dcb0df3e7ea6c05a8c1473… > Author: Thomas Bruederli <thomas(a)roundcube.net> > Date: 2012-11-11 (Sun, 11 Nov 2012) > > Changed paths: > M CHANGELOG > M installer/rcube_install.php > M plugins/help/package.xml > M plugins/help/skins/larry/help.css > M plugins/help/skins/larry/templates/help.html > M program/steps/mail/func.inc > > Log Message: > ----------- > Merge branch 'master' of github.com:roundcube/roundcubemail > > > Compare: > https://github.com/roundcube/roundcubemail/compare/71649445a0b8...e43dcb0df… > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

4 16

redundant imap calls
by Cor Bosman 27 Nov '12

27 Nov '12

Hey all, i noticed that roundcube 0.8.x does the following call twice during login: Nov 27 09:24:26 roundcube-test roundcube: [8BF7] C: A0003 LIST (SUBSCRIBED) "" "*" Nov 27 09:24:27 roundcube-test roundcube: [1B0C] C: A0003 LIST (SUBSCRIBED) "" "*" It's not an expensive call, but is there a reason to call this twice? Regards, Cor

2 1

Classic vs. Larry (was: Release 0.8 (stable) with new skin is out)
by Michael Heydekamp 25 Nov '12

25 Nov '12

Am 15.11.2012 21:00, schrieb Thomas Bruederli: > The general decision was to only have one skin provided by the core > team. Ok, this is new to me. Has this been stated elsewhere before, and I may have missed it? At least it sounds a bit different to what you posted before under this subject (see my previous posts). > And this will definitely be the new Larry skin. Hmm. :-( But that's of course your decision. > And yes, we heard your complains about wasted space in Larry, along > with others saying the same, and we'll try to improve the header > section anytime soon. Not sure what you mean with "header section", I didn't lose a word about that (yet). It's simply every single message in the message pane which does already take way too much space. Attached see comparison between Classic and Larry skin on my laptop, with identical config settings: 1) Classic is displaying 14 messages in the message pane, Larry just 9. A decrease of approx. 35% (wow). 2) Classic is displaying 26 folder levels in the folder pane (with still some space left at the bottom), Larry just 19 (with no space left at the bottom). A decrease of approx. 27%. 3) Although the text font in the Classic skin is a lot larger than in the Larry skin (I didn't patch the Larry skin to the larger font yet), Classic is displaying one more line of the body than Larry. 4) Links in the message header "Mailing list" are not visible as such (= not underlined), unless you hover them. But why should you do that, if you don't get the idea that they might be links? So which skin would YOU choose...? ;-) Ok, I'll stop here. The only real advantage that I can see is that the buttons have text, but "Allen antwor..." doesn't also look too nice. And why the heck have those "bars" (or how do you call that?) e.g. at the bottom of the folder list - the one with the cogwheel - such an extreme height? My impression is: The guys who invented this skin must have been sitting in front of a huge screen and didn't care too much about us poor laptop users. Not to speak about smartphone users (luckily, I don't have one). No offense, though. Greets, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

4 5

timing info in debug
by Cor Bosman 23 Nov '12

23 Nov '12

Hey all, would it theoretically be possible to log timing info in debug output? For instance SQL and IMAP debugging? It would be invaluable to find performance problems I would think. Regards, Cor

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev November 2012