Dev December 2012

dev@lists.roundcube.net

20 participants
47 discussions

Replies to HTML messages
by Michael Heydekamp 27 Jan '13

27 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

Sort order of special folders ignored in 0.9-git-master
by Michael Heydekamp 14 Jan '13

14 Jan '13

A while ago, I changed the default sort order of the special folders in main.inc.php to (just because I'd like to have it this way): > $rcmail_config['default_folders'] = array('INBOX', 'Sent', 'Drafts', 'Trash', 'Junk'); This does work in 0.8.4. It also worked in 0.9-git-master, but it doesn't anymore. The first day when I realized this was Nov 13th. Any clue what the cause could be...? Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

4 10

How to fix incorrect CT-declaration "text/x-mail" for .eml attachments?
by Michael Heydekamp 04 Jan '13

04 Jan '13

We're working and testing on this issue for days in the meantime, but to no avail. The issue is: Our system is returning "text/x-mail" (rather than "message/rfc822", how it would be expected) when we throw the PHP function 'finfo_open' against a valid e-mail file, which has been saved locally with Roundcube, starting with a line "Return-path:". Therefore and logically Roundcube is declaring ""text/x-mail" when attaching this .eml to an e-mail, which does prevent Roundcube from handling and rendering the attchment as an e-mail. But, ha...! You won't probably believe it, but while typing this and after days of research in the net and just looking at the .eml again, it occurs to me, that we can "solve" the problem by changing "Return-path:" to "Return-Path:" in the first line of the .eml source file. All of a sudden the .eml file is correctly detected as "message/rfc822". Arrgh!? That can't be true, really, so many lost days... Just because of this "-p" vs. "-P"?! The message that we were using for testing has apparently been composed with the Google webmailer (which does for whatever reason not set any of the several MUA headers being around, I can just assume this from other headers such as "X-Google-Sender-Auth:"). Anyway, there are still a number of questions open then: 1) Our system (Debian GNU/Linux 6.0 Squeeze) is using a compiled magic file "/usr/share/magic.mgc" with a file size of 1.830.800 Byte, which apparently supports "Return-Path:", but not "Return-path:". Is there any other magic.mgc around which does also support "Return-path:" and which is compatible with our system? This question arises because I tried to use a magic.mgc which is bundled with the Linux command 'file' 5.11 (while the original 'file' version of Squeeze is 5.04), but we get an error if we try to open it with 'finfo_open()'. Apparently this magic.mgc does also not support "Return-path:" (because it doesn't contain that string), but this experience shows that you can't use any arbitrary magic.mgc found somewhere. 2) I can find a plain (non-compiled) text file "/usr/share/mime/magic" on our system which does apparently support both "Return-Path:" and "Return-path:", but we're getting an error when trying to load it with 'finfo_open'. This is surprising in so far as we can load another plain (also non-compiled) plain text file "/etc/apache2/magic" without a problem (but which does unfortunately also not support "Return-path:", so it doesn't really help as well, unless being edited). Any idea why 'finfo_open' can load some plain text (non-compiled) magic files, but others not...? 3) The biggest of all mysteries: Where do the declaration "text/x-mail" and the description "ASCII mail text" in the case of "Return-path:" come from at all? These strings are not contained in any of the several (compiled or non-compiled) magic files. Any useful hints most appreciated! Ah, and please: Don't advise to add ".eml" to Roundcube's mimetypes.php. We're aware of that, but according to Thomas advice, this is not the right way to go. To check the difference between the result of an .eml with "Return-Path:" and with "Return-path:", just click on the following link (it may not last forever, so don't be too surprised if it should not work years later): http://srv217.dedi64.de/mime_test/mime_test.php PHP test code is attached. Thanks, cheers (and hoping for helpful hints and answers) -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

7 18

From launchpad to Transifex
by Thomas Bruederli 29 Dec '12

29 Dec '12

Hello folks! I hope you're having some relaxing holidays. At this time of the year we're also in the process of finishing and cleaning up things. After getting a few complaints about launchpad and after having my own issues with the translation system of launchpad, I'm now trying out the capabilities of the Transifex platform. For some unknown reason Transifex didn't appear on my radar when we decided to move from our home-grown translation system some existing online translation service. But compared to launchpad, Transifex really is shiny star with great features: first of all, it natively supports our PHP-style localization files. So no conversion to and from the gettext format is necessary. Then the commandline tools come in very handy and make it easy to sync translations with our git repository. Although I had tackled together a script to import translations from launchpad, there was always something failing which made it impossible to run it automatically in a cron job. The Transifex platform seems to be very solid and well-developed whereas launchpad has some serious issues with updating counts and other meta information. Not to speak of the endless (nonsense) conflicts the system detected which I had to resolve manually by clicking hundreds of buttons... Long story short: I'd like to make Transifex our new and official translation system and shut-down the account on launchpad. I know, this isn't very nice for all of our translators who we made registering accounts on launchpad not so long ago and who now have to register at yet another platform just to follow us. I admit, launchpad was a mistake and I'd like to correct this mistake rather soon. So unless there are serious concerns about the move to Transifex, this shall be our new translation system starting in 2013. As a first step, I registered a project at https://www.transifex.com/projects/p/roundcube-webmail. For quality reasons it is set to limited access which means that translators have to apply to become part of a translation team before they can actually start translating. So if you're interested in becoming a member for a certain language team, choose the language from the list and then click on "Join team" on the upper right part of the overview page. Thanks to all the people who contributed to Roundcube either as developers, translators, testers or in any other way. It's fun to move the project forward and I hope you'll all stick with us in 2013. Happy new year, everybody! ~Thomas

2 1

Re: [RCD] How to fix incorrect CT-declaration "text/x-mai l" for .eml attachments?
by Thomas Bruederli 28 Dec '12

28 Dec '12

This user has now been set to moderation mode. I hope this will avoid more auto-responded messages being posted to the list. > On 27/12/2012 09:13, mvega(a)elconix.com wrote: >> >> Estimados, >> >> Me encuentro fuera de la oficina desde el 26 hasta el 9 de enero 2013, >> Tendre acceso a mi correo y es posible que tome un tiempo en responder. >> >> [...]

3 2

PLEASE fix your BROKEN autoresponder
by Reindl Harald 27 Dec '12

27 Dec '12

hi it is not acceptable that your mailserver ignores "Precedence: list" header and spams mailing lists multiple times with the same autoresponds a sane auto-responder * never responds to bulk/list messages * never responds multiple times to the same sender in a short time frame

1 0

Re: [RCD] How to fix incorrect CT-declaration "text/x-mai l" for .eml attachments?
by mvega＠elconix.com 27 Dec '12

27 Dec '12

Estimados, Me encuentro fuera de la oficina desde el 26 hasta el 9 de enero 2013, Tendre acceso a mi correo y es posible que tome un tiempo en responder. Para cualquier consulta puede comunicarse con Jose vega Director de Operaciones, en jvega(a)elconix.com. Feliz Navidad y Prospero 2013 Moises Vega ELCONIX

1 0

Re: [RCD] How to fix incorrect CT-declaration "text/x-mai l" for .eml attachments?
by mvega＠elconix.com 27 Dec '12

27 Dec '12

1 0

Re: [RCD] How to fix incorrect CT-declaration "text/x-mai l" for .eml attachments?
by mvega＠elconix.com 27 Dec '12

27 Dec '12

1 0

Re: [RCD] How to fix incorrect CT-declaration "text/x-mai l" for .eml attachments?
by mvega＠elconix.com 27 Dec '12

27 Dec '12

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev December 2012