Say we compose a message like this:
----------------------------
This is composed text #1.
> This is quoted text #1.
This is composed text #2.
> This is quoted text #2.
> This is quoted text #3.
>
>> This is quoted text #4.
>
> This is quoted text #5.
>
>> This is quoted text #6.
This is composed text #3.
>> This is quoted text #7.
>>
>>> This is quoted text #8.
>>
>> This is quoted text #9.
>>
>>> This is quoted text #10.
----------------------------
Then we save it as draft and exit the message.
Later on, we edit the draft. The message body is now loaded like this:
----------------------------
This is composed text #1.
> This is quoted text #1.
This is composed text #2.
> This is quoted text #2.
> This is quoted text #3.
>
>> This is quoted text #4.
> This is quoted text #5.
>
>> This is quoted text #6.
This is composed text #3.
>> This is quoted text #7.
>>
>>> This is quoted text #8.
>> This is quoted text #9.
>>
>>> This is quoted text #10.
----------------------------
Result: The (blank) quoted lines between...
>> This is quoted text #4.
> This is quoted text #5.
...and...
>>> This is quoted text #8.
>> This is quoted text #9.
...have been deleted due to some odd reason.
Environment and relevant config settings:
-----------------------------------------
IE8, Win7/64, "$rcmail_config['line_length'] = 76;",
"$rcmail_config['send_format_flowed'] = false;"
Things to be noted:
-------------------
1) All quote chars ">" have a trailing white space on all quoted lines
(i.e. also on all blank quoted lines) during composing. Even if I delete
those trailing blanks on all blank quoted lines during composing, they
apparently get re-inserted upon saving the draft (I verified that by saving
the draft message to disk and looking at it with a hex editor), so the
result is the same when I edit the message again later on.
2) Draft messages are saved as "format=flowed" since Nov 19th 2012, no
matter what. This is intentional and should not be re-changed again. Thomas
committed this change upon my request here:
https://github.com/roundcube/roundcubemail/commit/ac382e114570537e038eca79d…
See also: http://trac.roundcube.net/ticket/1488799
I'm not sure if the behaviour described above is connected to this commit,
at least in 0.8.4 the behaviour is the same when I load the message which
has been saved as draft with 0.9-git.
But I assume that this all does have to do with the format=flowed thingy in
some way. I may be wrong, of course.
Ticket required...?
--
Michael Heydekamp
Co-Admin freexp.de
Düsseldorf/Germany
Is this for incoming or for outgoing messages?
--
Michael Heydekamp
Co-Admin freexp.de
Düsseldorf/Germany
Am 06.01.2013 13:11, schrieb GitHub:
> Branch: refs/heads/master
> Home: https://github.com/roundcube/roundcubemail
> Commit: a5b8ef99d4e26bdb00e9b74221f107767a084a6e
>
> https://github.com/roundcube/roundcubemail/commit/a5b8ef99d4e26bdb00e9b7422…
> Author: Aleksander Machniak <alec(a)alec.pl>
> Date: 2013-01-06 (Sun, 06 Jan 2013)
>
> Changed paths:
> M CHANGELOG
> M program/lib/Roundcube/rcube.php
> M program/lib/Roundcube/rcube_charset.php
> M tests/Framework/Charset.php
>
> Log Message:
> -----------
> Improve charset detection by prioritizing charset according to user
> language (#1485669)
>
>
>
>
> _______________________________________________
> Roundcube SVN commits mailing list
> svn(a)lists.roundcube.net
> http://lists.roundcube.net/mailman/listinfo/svn
If this commit was meant to fix the wrong encoding of the headers
"Mail-Reply-To:" und "Mail-Follow-Up-To:", then I can confirm that it does
indeed fix it. :) At least for "Mail-Reply-To:", I couldn't test
"Mail-Follow-Up-To:" (when is the latter header BTW created at all?).
Thanks and cheers,
--
Michael Heydekamp
Co-Admin freexp.de
Düsseldorf/Germany
Am 02.01.2013 19:16, schrieb GitHub:
> Branch: refs/heads/master
> Home: https://github.com/roundcube/roundcubemail
> Commit: 4fb36eb1a83c334a9c9cf20fa8d1caa4c9170150
>
> https://github.com/roundcube/roundcubemail/commit/4fb36eb1a83c334a9c9cf20fa…
> Author: Thomas Bruederli <thomas(a)roundcube.net>
> Date: 2013-01-02 (Wed, 02 Jan 2013)
>
> Changed paths:
> M program/lib/Mail/mime.php
> M program/lib/Mail/mimeDecode.php
> M program/lib/Mail/mimePart.php
>
> Log Message:
> -----------
> Upgrade PEAR:Mail_mime package to latest version
>
>
>
>
> _______________________________________________
> Roundcube SVN commits mailing list
> svn(a)lists.roundcube.net
> http://lists.roundcube.net/mailman/listinfo/svn
Just wanted to confirm that this fix works for me.
Thanks!
--
Michael Heydekamp
Co-Admin freexp.de
Düsseldorf/Germany
Am 02.01.2013 20:06, schrieb GitHub:
> Branch: refs/heads/master
> Home: https://github.com/roundcube/roundcubemail
> Commit: 240ad59dcded9b33826582fe6b9abd22dd479121
>
> https://github.com/roundcube/roundcubemail/commit/240ad59dcded9b33826582fe6…
> Author: Aleksander Machniak <alec(a)alec.pl>
> Date: 2013-01-02 (Wed, 02 Jan 2013)
>
> Changed paths:
> M CHANGELOG
> M skins/classic/iehacks.css
>
> Log Message:
> -----------
> Fix #countcontrols issue in IE<=8 when text is very long (#1488890)
>
>
>
>
> _______________________________________________
> Roundcube SVN commits mailing list
> svn(a)lists.roundcube.net
> http://lists.roundcube.net/mailman/listinfo/svn
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
Hi!
My problem:
I want my users to use a solid skin (by default) on their desktop
but also want to serve them a proper mobile skin.
First off, i don't know how the browser/roundcube selects
the correct mobile skin for mobile devices.
Is this pure CSS magic or is it selected somewhere in the skin's
code?
Second, I'm thinking that Larry is a solid skin and is also well
supported by the developers and the community.
So, does anyone provide a mobile version for the Larry skin?
I've looked into various (commercial) skins but none provides
the look and feel I'm looking for
I would be willing to pay the normal fee that others are
charging - around 50 USD.
If that is not possible, I would also be willing to hack my
installation (either make a custom skin on top of Larry or
do some dirty stuff in the template-selection-routines)
to serve another mobile skin when the user is visiting with a mobile device.
However, i rather prefer a different solution ;)
Cheers,
Raoul
--
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia(a)ipax.at
Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office(a)ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________
Finally! Thanks, Alec.
But let me take the opportunity to point to an issue which I believe to
encounter:
In the past, I did a body search by entering "body:<search string>" in the
search field. Sometimes, approx. ten seconds after starting the search, the
spinning wheel of the Ajax message "Searching..." at the top is stopping,
and a few seconds later the message disappears completely. So I'm often not
sure if the search is still active, or has been interrupted due to some
reason, or if no match has been found. In most of these cases no feedback
message is given at all, and the message list stays empty.
But in very rare cases I also get a feedback message "Search found no
matches", and the message list gets reloaded. The behaviour is not
consistent.
The above SEEMS to happen more likely in folders with many messages (>
10,000?).
Cheers,
--
Michael Heydekamp
Co-Admin freexp.de
Düsseldorf/Germany
Am 01.01.2013 10:56, schrieb GitHub:
> Branch: refs/heads/master
> Home: https://github.com/roundcube/roundcubemail
> Commit: 347ba311e68f3a641805a268313fcd5ed851feb7
>
> https://github.com/roundcube/roundcubemail/commit/347ba311e68f3a641805a2683…
> Author: Aleksander Machniak <alec(a)alec.pl>
> Date: 2013-01-01 (Tue, 01 Jan 2013)
>
> Changed paths:
> M CHANGELOG
> M program/localization/en_US/labels.inc
> M program/steps/mail/search.inc
> M skins/classic/templates/mail.html
> M skins/larry/templates/mail.html
>
> Log Message:
> -----------
> Add possibility to search in message body only (#1488770)
>
>
>
>
> _______________________________________________
> Roundcube SVN commits mailing list
> svn(a)lists.roundcube.net
> http://lists.roundcube.net/mailman/listinfo/svn