Re: [Dovecot] Improving interaction/performance with Mail.app
On July 1, Alan Schmitt wrote:
What OS are you using in server side? And what filesystem?
Mac OS X.4.7, with HFS+ as files system.
I think I've heard before that Dovecot doesn't behave too great with OSX..
This might be the cause. I've had the plan to move my IMAP server to
a linux box, this might be the good time.Hmm. I guess it's time to put this in wiki:
Good to know. I just need to find a way to reproduce the problem.
Thanks a lot for your help,
Alan
I just moved to Dovecot. I'm looking forward to figuring out how to allow users to have access to (old) email in mbox format, an have all new mailboxes go to maildirs. . . But I digress.
When we switched, no one complained of performance issues -- except myself.
mail.app would seem to stall on caching a message, then report that it was reconnecting, and move a bit further, then stall. . .
What apparently was happening was the dovecot was polling for /dev/urandom, over and over again, waiting for some random bits, and Mail.app would timeout and reconnect. Turning off SSL made it MUCH faster.
Of course, that's not a solution.
So, I hunted the mailing lists, and ran across some notes about dovecot using /dev/urandom a little too enthusiastically. I haven't had a chance to grub through the code (hard to do with a 2-year old that won't sleep until midnight on many a nights!), and this post is somewhat premature, but I'm curious if turning off SSL removes the problem.
Of course, switching to a Linux server will (sort of) negate the problem, in that apparently Linux is a little faster at finding random bits (I guess, I've never looked into it).
My server is Solaris 9. My client is Mail.app from 10.3.9.
As I grub through the code, I'll try and identify cryptographically significant randomness from non-cryptographically significant randomness.
Sean
Hi.
Before anyone bothers to mention that I'm an idiot, let me say it first.
OK, I now understand the difference between /dev/random and /dev/urandom.
Now I need to figure out what's really going on, since urandom claims it will *NEVER* block. . .
Sean
On 8/1/2006, "Sean Kamath" kamath@geekoids.com wrote:
On July 1, Alan Schmitt wrote:
What OS are you using in server side? And what filesystem?
Mac OS X.4.7, with HFS+ as files system.
I think I've heard before that Dovecot doesn't behave too great with OSX..
This might be the cause. I've had the plan to move my IMAP server to a linux box, this might be the good time.
Hmm. I guess it's time to put this in wiki:
Good to know. I just need to find a way to reproduce the problem.
Thanks a lot for your help,
Alan
I just moved to Dovecot. I'm looking forward to figuring out how to allow users to have access to (old) email in mbox format, an have all new mailboxes go to maildirs. . . But I digress.
When we switched, no one complained of performance issues -- except myself.
mail.app would seem to stall on caching a message, then report that it was reconnecting, and move a bit further, then stall. . .
What apparently was happening was the dovecot was polling for /dev/urandom, over and over again, waiting for some random bits, and Mail.app would timeout and reconnect. Turning off SSL made it MUCH faster.
Of course, that's not a solution.
So, I hunted the mailing lists, and ran across some notes about dovecot using /dev/urandom a little too enthusiastically. I haven't had a chance to grub through the code (hard to do with a 2-year old that won't sleep until midnight on many a nights!), and this post is somewhat premature, but I'm curious if turning off SSL removes the problem.
Of course, switching to a Linux server will (sort of) negate the problem, in that apparently Linux is a little faster at finding random bits (I guess, I've never looked into it).
My server is Solaris 9. My client is Mail.app from 10.3.9.
As I grub through the code, I'll try and identify cryptographically significant randomness from non-cryptographically significant randomness.
Sean
participants (1)
-
Sean Kamath