Hi again,
As usual, the latest release contained some nasty bugs. Sending mails using PHP's mail() function completely ignored the message headers. This and some charset issues are now fixed. I updated the beta-release package in the download section. Because many files are involved in this bugfix, I did not create a patch file but I rather suggest to download the beta-version again and replace index.php and all contents of the program folder.
Regards, Thomas
Tadashi Jokagi wrote:
Hi Thomas,
Congratulation!! I tried instantly. Correct "From" was not able to be set up by e-mail transmission. I have not checked this problem yet.
Regards,
Fixed the problem for me - thanks Thomas!
Tom
On 2/20/2006 5:51 PM, Thomas Bruederli wrote:
Hi again,
As usual, the latest release contained some nasty bugs. Sending mails using PHP's mail() function completely ignored the message headers. This and some charset issues are now fixed. I updated the beta-release package in the download section. Because many files are involved in this bugfix, I did not create a patch file but I rather suggest to download the beta-version again and replace index.php and all contents of the program folder.
Regards, Thomas
Tadashi Jokagi wrote:
Hi Thomas,
Congratulation!! I tried instantly. Correct "From" was not able to be set up by e-mail transmission. I have not checked this problem yet.
Regards,
Since I tried this as a replacement for Squirrelmail just for my personal use (about 5 accts) I decided to wipe my install clean and go with the new upgraded beta tonite. Works great now. My "nobody" issue is resolved along with the errant "" I would get when using apostrophes in the addressbook display name.
I just noticed I forgot to CHMOD my temp and logs directories to 777. Is this still necessary? Everything works fine.
-Mark
Thomas Bruederli wrote:
Hi again,
As usual, the latest release contained some nasty bugs. Sending mails using PHP's mail() function completely ignored the message headers. This and some charset issues are now fixed. I updated the beta-release package in the download section. Because many files are involved in this bugfix, I did not create a patch file but I rather suggest to download the beta-version again and replace index.php and all contents of the program folder.
Regards, Thomas
On Feb 20, 2006, at 9:28 PM, Mark Pallo wrote:
Since I tried this as a replacement for Squirrelmail just for my
personal use (about 5 accts) I decided to wipe my install clean and go with
the new upgraded beta tonite. Works great now. My "nobody" issue is
resolved along with the errant "" I would get when using apostrophes in the
addressbook display name.I just noticed I forgot to CHMOD my temp and logs directories to
777. Is this still necessary? Everything works fine.
Setting directory permissions to 777 was never necessary. In fact,
its really a race condition waiting to happen. The only user who
needs to be able to write to roundcube's tmp and log dirs is the user
the webserver runs as. If you're going to use 777, you may want to
consider setting the sticky bit as well (like /tmp is by default) to
ensure that user's can only modify their own data.
On a small system its probably not an issue, but on multiuser systems
it can be a problem.
-- J.
I am having an issue I did not notice last night. Today at work when I logged in my existing items are in my inbox, however I have no new messages displayed. When I login I briefly see the number of messages next to "Inbox" on the left (18) flash and then it will disappear. I have to click on Email in the upper right toolbar and/or click on Inbox again for them to appear.
Any ideas?
Jason Stelzer wrote:
On Feb 20, 2006, at 9:28 PM, Mark Pallo wrote:
Since I tried this as a replacement for Squirrelmail just for my personal use (about 5 accts) I decided to wipe my install clean and go with the new upgraded beta tonite. Works great now. My "nobody" issue is resolved along with the errant "" I would get when using apostrophes in the addressbook display name.
I just noticed I forgot to CHMOD my temp and logs directories to 777. Is this still necessary? Everything works fine.
Setting directory permissions to 777 was never necessary. In fact, its really a race condition waiting to happen. The only user who needs to be able to write to roundcube's tmp and log dirs is the user the webserver runs as. If you're going to use 777, you may want to consider setting the sticky bit as well (like /tmp is by default) to ensure that user's can only modify their own data.
On a small system its probably not an issue, but on multiuser systems it can be a problem.
-- J.
Hi,
Since I updated to the new beta version I only get a blank page! I tried it with IE and Firefox.
-----Ursprüngliche Nachricht----- Von: Thomas Bruederli [mailto:roundcube@gmail.com] Gesendet: Dienstag, 21. Februar 2006 00:51 An: RoundCube Dev Cc: users@lists.roundcube.net Betreff: Re: RoundCube Webmail 0.1 Beta released
Hi again,
As usual, the latest release contained some nasty bugs. Sending mails using PHP's mail() function completely ignored the message headers. This and some charset issues are now fixed. I updated the beta-release package in the download section. Because many files are involved in this bugfix, I did not create a patch file but I rather suggest to download the beta-version again and replace index.php and all contents of the program folder.
Regards, Thomas
Tadashi Jokagi wrote:
Hi Thomas,
Congratulation!! I tried instantly. Correct "From" was not able to be set up by e-mail transmission. I have not checked this problem yet.
Regards,
Hi, have you checked the roundcube logs?
Greetings Alex
On Tuesday 21 February 2006 11:53, Stefan Ott wrote:
Hi,
Since I updated to the new beta version I only get a blank page! I tried it with IE and Firefox.
-----Ursprüngliche Nachricht----- Von: Thomas Bruederli [mailto:roundcube@gmail.com] Gesendet: Dienstag, 21. Februar 2006 00:51 An: RoundCube Dev Cc: users@lists.roundcube.net Betreff: Re: RoundCube Webmail 0.1 Beta released
Hi again,
As usual, the latest release contained some nasty bugs. Sending mails using PHP's mail() function completely ignored the message headers. This and some charset issues are now fixed. I updated the beta-release package in the download section. Because many files are involved in this bugfix, I did not create a patch file but I rather suggest to download the beta-version again and replace index.php and all contents of the program folder.
Regards, Thomas
Tadashi Jokagi wrote:
Hi Thomas,
Congratulation!! I tried instantly. Correct "From" was not able to be set up by e-mail transmission. I have not checked this problem yet.
Regards,
I'm having a problem with messages with large attachments. I'm running the 0.1 Beta, but I was having the problem previously on the 20051021 version.
Specifically, when I open up messages of larger than a specific size, I get the "Loading ..." notice up at the top, and the firefox "in-progress" circle circles for a time and then stops, and nothing happens on the screen. Eventually I get a red status bar at the top with a "Request timed out" message, but this is well after the log files showed that all processing was done.
I tracked my mail.log file, opening up a 775K message, which was successful, and a 947K message, which was not. The log subsections are as follows:
==== Open of 775K message; successful
Feb 28 00:36:19 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:36:19 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:36:21 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=2 Feb 28 00:36:22 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:36:22 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:36:22 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=0
==== Open of 947K message, failed
Feb 28 00:41:15 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:41:15 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:41:16 localhost imaplogin: DISCONNECTED, user=username, ip=[::ffff:127.0.0.1], headers=0, body=957685, time=1 Feb 28 00:41:29 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:41:29 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:41:29 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=0
I'm running Courier IMAPD on a Ubuntu server, accessing via Firefox.
To further complicate things, when I open up these large messages in squirrelmail, they open up successfully; BUT, when I visit a mail folder with 2200 messages in it, Roundcube generates the message listing just fine, but Squirrelmail fails similarly on that folder. Both open up folders with a small number of messages just fine, though I haven't tried to determine the cutoff size for squirrelmail.
Also, as one more data point, using the command-line mail client 'mutt' from the shell, but using it via IMAP works just fine, both reading the large messages and the large folders.
So it doesn't really appear that it's the IMAP server, though I guess it still could be if they are accessing things differently there.
Any suggestions on what to do to fix this problem? My wife get lots of large attachments, and this is really getting in her way.
Thanks.
Bruce
Bruce Israel wrote:
I'm having a problem with messages with large attachments. I'm running the 0.1 Beta, but I was having the problem previously on the 20051021 version.
Specifically, when I open up messages of larger than a specific size, I get the "Loading ..." notice up at the top, and the firefox "in-progress" circle circles for a time and then stops, and nothing happens on the screen. Eventually I get a red status bar at the top with a "Request timed out" message, but this is well after the log files showed that all processing was done.
I tracked my mail.log file, opening up a 775K message, which was successful, and a 947K message, which was not. The log subsections are as follows:
==== Open of 775K message; successful
Feb 28 00:36:19 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:36:19 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:36:21 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=2 Feb 28 00:36:22 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:36:22 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:36:22 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=0
==== Open of 947K message, failed
Feb 28 00:41:15 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:41:15 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:41:16 localhost imaplogin: DISCONNECTED, user=username, ip=[::ffff:127.0.0.1], headers=0, body=957685, time=1 Feb 28 00:41:29 localhost imaplogin: Connection, ip=[::ffff:127.0.0.1] Feb 28 00:41:29 localhost imaplogin: LOGIN, user=username, ip=[::ffff:127.0.0.1], protocol=IMAP Feb 28 00:41:29 localhost imaplogin: LOGOUT, user=username, ip=[::ffff:127.0.0.1], headers=0, body=0, time=0
I'm running Courier IMAPD on a Ubuntu server, accessing via Firefox.
To further complicate things, when I open up these large messages in squirrelmail, they open up successfully; BUT, when I visit a mail folder with 2200 messages in it, Roundcube generates the message listing just fine, but Squirrelmail fails similarly on that folder. Both open up folders with a small number of messages just fine, though I haven't tried to determine the cutoff size for squirrelmail.
Also, as one more data point, using the command-line mail client 'mutt' from the shell, but using it via IMAP works just fine, both reading the large messages and the large folders.
So it doesn't really appear that it's the IMAP server, though I guess it still could be if they are accessing things differently there.
Any suggestions on what to do to fix this problem? My wife get lots of large attachments, and this is really getting in her way.
Thanks.
Bruce
enable debugging in courier-imap, or if you run it out of daemontools like i do, stick recordio in the run file. recordio is more verbose than debug logging for courier.
Hi I just upgraded to revision 283 and sorting is completely broken.
It can't sort correctly on any of the fields. Did I miss something in the upgrade? Has anyone else experienced this?
Spellchecking rocks!
Thanks /Alexander
Hi Alexander,
the sorting problem is under heavy attack by the developers and should be fixed soon. If you can, revert to an older version and wait this one out.
For more information, you can read up on this in the archives of the developers list, it's being discussed there.
Cheers, mtu
Thank you for the info. I'll just sit tight.
Regards Alexander
On Mon, 2006-07-31 at 17:00 +0200, Michael Bueker wrote:
Hi Alexander,
the sorting problem is under heavy attack by the developers and should be fixed soon. If you can, revert to an older version and wait this one out.
For more information, you can read up on this in the archives of the developers list, it's being discussed there.
Cheers, mtu