We have been playing around with Dovecot
this week. Dovecot lets you compile with epoll support,
which can drastically improve the efficiency of applications that
handle a large number of concurrent of network connections.
Our current POP3/IMAP proxies run Perdition. Perdition uses "poll" – Linux’s old network event dispatcher. With "poll", performance suffers
when you start processing thousands of concurrent connections,
because it does a linear scan of socket file descriptors in order to
detect network events. The more connections you have, the more file
descriptors you have, and so the longer it takes to respond to network events. "epoll" does not need to do this linear scan, so the
response rate for network events is completely independent of the
number of network connections, making it much more scalable.
We got our first Dovecot proxy sever setup this morning. If you are brave, please
help us test it. Post your results to this blog post, especially if
you encounter any errors or weirdness…
Server Name: newproxy.mlsrvr.com
Supported Protocols:
POP3, port 110 (plain text or TLS)
IMAP, port 143 (plain text or TLS)
POP3S, port 995 (SSL)
IMAPS, port 993 (SSL)
If you use TLS or SSL you will get a SSL security warning. Just ignore it.
Using IMAP (SSL) everything seemed to work fine and I received several emails as normal (sending from one account to another), moved emails from one folder to another etc. I am not sure whether I should see greater responsiveness or the same. I suppose that will only be noticed when there is a far greater load on it than just a few people trying it out.
Sorry for not being able to give a lot of feedback but everything seemed to work the same as before.
Peter
Thanks. What IMAP program are you using Peter?
One problem that I am seeing so far is Thunderbird isn’t storing mail in the IMAP Sent folder when sending. This may be a problem with my Thunderbird config though… I have customized a lot and may have broken something. Just curious if anyone else is seeing it.
I too am using Thunderbird. 1.5 using the 1.8.1 branch (that which will end up as Thunderbird 2.0). Last night I did not have it when I simply changed the server to newproxy.mlsrvr.com, received the mismatched domain message and started using it.
After doing my tests last night I changed back to secure.emailsrvr.com and left things as that. However, after seeing your follow-up, I tried again but some time in my testing closed Thunderbird down and restarted it. I then had the same problem as you, not copying a message to the sent folder.
I did a bit of digging and found this old thread from 2004 I believe which is the exact same problem as we are encountering:
http://blog.gmane.org/gmane.mail.imap.dovecot/month=20040701
There are a couple of other threads when doing a search at gmane.org eg
http://article.gmane.org/gmane.mail.imap.dovecot/7962/match=thunderbird+sent+folder
http://article.gmane.org/gmane.mail.imap.dovecot/7054/match=thunderbird+sent+folder
One of the threads above links to this – although no mention of Dovecot:
http://www.mozillazine.org/talkback.html?article=5728
Looking around forums.mozillazine.org I don’t see anything particular so I suppose this might necessitate having a look in: https://bugzilla.mozilla.org/query.cgi
However, this may not be just a problem peculiar to Thunderbird.
I tried reducing the number of connections from 5-4 and then 2 but that did not change matters.
Back to secure.emailsrvr.com for me.
Peter
Thanks for the links. I did a bunch of reading testing and this appears to be related to Dovecot announcing different IMAP capabilities than the real backend IMAP servers (via the CAPABILITY command). If I am right, then this should be simple to fix. I’ll post an update soon.
Yep that was it – and it is fixed now. You will need to restart Thunderbird, so that it will read in the new CAPABILITY command. Please let me know if you find any other issues.
I will confirm that on my system the problem of being unable to save an email to the sent folder has been fixed. I will report back on any other issues I encounter.
Peter
[I inadvertently sent the above before completion – add after the URL the following]
That at least one individual was finding occasional failures – say 1 in 20 or so – to copy to the sent folder.
Peter
[Ignore, preferably delete, the post above sent at 3:18 pm]
I had a problem now with the copying of the mail to the sent folder. I had not changed anything in the last hour or so.
Previously emails sent had no problem with this but I received two warnings in a row that the message could not be copied. I tried a third time and no problem with the copying. This was all during the period 12:05 pm PST – 12:07 pm PST.
A little bit hairy for me at the moment during the business day 🙂 so I have changed back to secure.emailsrvr.com
I think in one of the threads that I referenced – or from a search here:
http://blog.gmane.org/gmane.mail.imap.dovecot/
that at least one individual was finding occasional failures – say 1 in 20 or so – to copy to the sent folder.
Peter
I haven’t been able to reproduce that. I have a lot of folks in our office using the newproxy now, so we’ll keep an eye out.
One thing I did run into is when you close and reload Thunderbird after I installed the fix, the Thunderbird process in some cases would continue running in the background for 20 seconds or so. And if you start it back up during that time it may not reload the IMAP CAPABILITY command.
We’ll do some more testing.
I had noticed that the “throbber” in the top right hand corner continuing to spin on occasion. I am not saying this is *never* the case with secure.emailsrvr.com but this was something I noticed a few times with newproxy.mlsrvr.com. I have been two months now with Webmail.us and Thunderbird has worked extremely well with secure.emailsrvr.com.
With the time I gave you – 12:05-12:07 pm Pacific – is there anything in the logs that you could pick up on as to what happened with my two failures to copy the sent message?
Peter