Dev

dev@lists.roundcube.net

1 participants
4315 discussions

Re: [RCD] possible bug in roundcube ?
by Alessandro Vesely 14 Dec '12

14 Dec '12

On Thu Dec 13 23:28:23 CET 2012 Michael Heydekamp wrote: > Am 13.12.2012 17:13, schrieb Benny Pedersen: > >> http://tools.ietf.org/html/rfc5322#section-3.4 can be angle-addr >> only when there is a non-empty display-name. > > The "only" in this sentence is not correct. Right. I should have had more coffee yesterday :-/ > RFC-wise, both are correct. > > But being a purist in this respect, I would also prefer if Roundcube would > eliminate the angle brackets if no display name is given. The problem is that some software eliminates those angle-brackets, thereby breaking any DKIM signature added meanwhile. I'll make a patch to optionally avoid such behavior in Courier-MTA. (Belt and brackets.) Of course, it may be irritating for users not to be able to set an address exactly the way they want to. It takes a bit of wisdom to handle this issue adequately... Should I file a feature request for this? Ciao Ale

2 2

possible bug in roundcube ?
by Benny Pedersen 14 Dec '12

14 Dec '12

http://tools.ietf.org/html/rfc5322#section-3.4 can be angle-addr only when there is a non-empty display-name. in To: header with roundcube From: Benny Pedersen <me(a)junc.org> To: <opendkim-users(a)lists.opendkim.org> Subject: Re: adsp fail there must imho not be < > around To: header here example from mozilla From: Alessandro Vesely <vesely(a)tana.it> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: opendkim-users(a)lists.opendkim.org Subject: Re: adsp fail is more correct ?

3 2

is roundcube supposed to see calendar attachments?
by Cor Bosman 13 Dec '12

13 Dec '12

Hey all, i am getting some reports that people aren't seeing calendar attachments. Not even as a downloadable attachment. Is this supposed to work at all? I just verified and indeed am totally unable to see text/calendar attachments in roundcube in any shape or form. I suppose this is because it's a multipart/alternative and RC just shows the first one. But this works fine in OSX and other clients. And this is being sent by outlook and an android client so we're not talking some fringe clients. I tried changing this to a mixed multipart, but that doesn't help either. Some local config problem? Cor Content-Type: multipart/alternative; boundary="_002_E16AD7C7A3955F4E81058F413D1224A2016EE105ABEXBE4officexs_" --_002_E16AD7C7A3955F4E81058F413D1224A2016EE105ABEXBE4officexs_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4C602A7FDD6F814780DA61DA58ED84FB(a)xs4all.net> Content-Transfer-Encoding: quoted-printable Organizer: "rj" <xxxxxxxx(a)xs4all.net> Start time: 2012-12-13 18:30 Central European Time End time: 2012-12-13 19:30 Central European Time *~*~*~*~*~*~*~*~*~* --_002_E16AD7C7A3955F4E81058F413D1224A2016EE105ABEXBE4officexs_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 Q………. <the actual calendar invite>…. --_002_E16AD7C7A3955F4E81058F413D1224A2016EE105ABEXBE4officexs_--

3 4

Re: [RCD] [Svn] [roundcube/roundcubemail] bb5d72: Use also Envelope-To for identity selection (#1488553)
by Michael Heydekamp 13 Dec '12

13 Dec '12

Thanks! Is it planned to support the (last) Received: header as well (see messages from Sebastian J. Bronner and Harald Reindl in this list)? Regards, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 12.12.2012 08:55, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: bb5d7282855dd83ccdd211cb77d0776dce71468e > > https://github.com/roundcube/roundcubemail/commit/bb5d7282855dd83ccdd211cb7… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-12-11 (Tue, 11 Dec 2012) > > Changed paths: > M CHANGELOG > M program/lib/Roundcube/rcube_storage.php > M program/steps/mail/compose.inc > > Log Message: > ----------- > Use also Envelope-To for identity selection (#1488553) > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

3 4

Format of GitHub messages in SVN list
by Michael Heydekamp 12 Dec '12

12 Dec '12

I sent this message to the SVN list already, but it appears that it doesn't arrive there (but I did also not receive a rejection through a moderator message). Since the move from SVN to GitHub, the format of the messages in the SVN list looks a bit strange to me: 1) Roundcube is displaying the attachment icon for each message, although there is no attachment at all in any of the messages. 2) All messages are declared as "multitype/mixed" for no real reason (the second part just containing the signature, this could perfectly be appended to the first part without creating a second part). 3) The Content-Type of the first part (i.e. the real content of the message) is "text/plain; charset=UTF-8", the Content-Transfer-Encoding "7bit". If CTE is 7bit, shouldn't the charset be "US-ASCII" then? The UTF-8 declaration will probably (and unnecessarily) invoke a decoding routine in most MUAs, although there is nothing to decode. 2) and 3) are minor issues, but 1) (the attachment icon) appears to be a wrong indication. Not sure if the declaration of the messages is misleading in some way, or if Roundcube's interpretation is wrong? If the latter, this could also affect any other messages. Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

4 9

Re: [RCD] git-pull am 11.11. nicht geklappt? (was: [Svn] [roundcube/roundcubemail] d9f109: Allow forwarding of multiple emails (#1486854))
by Michael Heydekamp 12 Dec '12

12 Dec '12

Sorry, this mail shouldn' have gone to the list. Grrr... -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 12.12.2012 20:16, schrieb Michael Heydekamp: > Hallo Martin, > > siehe unten. Kannst Du da was feststellen? > > Gruß, > -- > Michael Heydekamp > xxxxxxxxxxxxx > xxxxxxxxxxxxxxxxxx > Tel.: xxxxxxxxxxxxxxxxxx (privat) > Tel.: xxxxxxxxxxxxxxxxxxxx (Büro) > Fax: xxxxxxxxxxxxxxxxx (Büro) > Mobil: xxxxxxxxxxxxxxxxxx > eMail: xxxxxxxxxxxxxxxxxxxx > WWW: xxxxxxxxxxxxxxxxxxxxxxx > > > Am 12.12.2012 20:10, schrieb Michael Heydekamp: >> Am 12.12.2012 19:10, schrieb A.L.E.C: >>> On 12/12/2012 06:50 PM, Michael Heydekamp wrote: >> >>>> How does this feature work? >>>> >>>> If I mark more than one message, the forward button is being disabled. >>> >>> Works for me. Forward button is enabled, only "forward inline" is disabled. >> >> Sorry, I wasn't careful enough. Due to some still unknown reason, our >> git-pull seems to have failed last night, as I'm still running "GIT >> 20121210.2232". Therefore it's more than logical that your commit of Dec >> 11th can't work here. Sorry... >> -- >> Michael Heydekamp >> Co-Admin freexp.de >> Düsseldorf/Germany >> _______________________________________________ >> Roundcube Development discussion mailing list >> dev(a)lists.roundcube.net >> http://lists.roundcube.net/mailman/listinfo/dev

1 0

Re: [RCD] [Svn] [roundcube/roundcubemail] d9f109: Allow forwarding of multiple emails (#1486854)
by Michael Heydekamp 12 Dec '12

12 Dec '12

How does this feature work? If I mark more than one message, the forward button is being disabled. -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 11.12.2012 08:33, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: d9f109b56af2015eae7aadc5e87c06365854eda0 > > https://github.com/roundcube/roundcubemail/commit/d9f109b56af2015eae7aadc5e… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-12-10 (Mon, 10 Dec 2012) > > Changed paths: > M CHANGELOG > M program/js/app.js > M program/steps/mail/compose.inc > M program/steps/mail/sendmail.inc > M skins/classic/includes/messagetoolbar.html > M skins/larry/includes/mailtoolbar.html > > Log Message: > ----------- > Allow forwarding of multiple emails (#1486854) > > > Commit: 25bf00ecbc2cab20ce66845513980b83b03f7c49 > > https://github.com/roundcube/roundcubemail/commit/25bf00ecbc2cab20ce6684551… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-12-10 (Mon, 10 Dec 2012) > > Changed paths: > M program/lib/Roundcube/rcube_message.php > M program/lib/Roundcube/rcube_message_header.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/message.html > M skins/larry/templates/messagepreview.html > > Log Message: > ----------- > Merge branch 'master' of github.com:roundcube/roundcubemail > > > Compare: > https://github.com/roundcube/roundcubemail/compare/31521613e40b...25bf00ecb… > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

2 2

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

11 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

Regression with replies to own messages: Mail being addressed to myself
by Michael Heydekamp 08 Dec '12

08 Dec '12

In 0.8.4 (and since a few days ago also in 0.9-git-master) there is a pretty cool and intelligent logic when replying to own messages: They are addressed exactly in the same way as the message the user did send previously. So if an own message had those headers... ----------------------------- From: my.local.part(a)my.domain To: local.part1(a)do.main Cc: local.part2(a)do.main ----------------------------- ...then any self-created reply (to all) to this own message had also exactly the same headers. This logic got lost in 0.9-git-master a few days ago. :-( I just can't tell exactly when. Probably in connection with the identity issue (support of Delivered-To)...? Now the reply (to all) has these headers (if I don't edit them manually): ---------------------------------------------- From: my.local.part(a)my.domain To: my.local.part(a)my.domain Cc: local.part1(a)do.main, local.part2(a)do.main ---------------------------------------------- The same issue does apply in a similar way to messages with have been sent to a single recipient. Then a "normal" reply (i.e. not "to all") has these headers: ----------------------------- From: my.local.part(a)my.domain To: my.local.part(a)my.domain ----------------------------- This change of the previous behaviour isn't hopefully deliberate, is it? If it isn't: Shall I open a ticket? I loved the previous logic, as Roundcube is the only MUA that I'm aware of which does/did provide it. So please bring it back! ;) Regards, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev