On 3/24/12 8:01 PM, Eric Shubert wrote:
On 03/24/2012 07:36 PM, Casey Price wrote:
I've done a few conversions in the past on development machines..pretty
straightforward when following the guide on the wiki. Do you think that
could be the cause of this issue?
I think the probability is very high. I'd bet on it.
I've heard from numerous sources that
Courier has issues with large mailboxes, but this issue just strikes me
as very odd...I'll post a little snippet of the imap log for further
details - however I don't get why the phone wouldn't initiate a new
connection when the original connection was lost.
Some email client programs on 'smart' phones are not what I'd call
robust. I can't say exactly why, but this doesn't surprise me.
After all...its not
like the device is maintaining a constant connection with the server -
it should just be connecting at a specified interval to check for new
mail...
Not exactly. The imap protocol allows the server to notify the client
immediately when a message arrives (see
http://en.wikipedia.org/wiki/IMAP_IDLE), which negates the need for
the client to poll the server like pop3 does (and imap can). Hard to
say if this is coming into play at all or not.
although, now that I'm said that I'm wondering how often he has
it set to check for messages. I think I overlooked that one. Wonder if:
As items arrive "get email" could be causing some issues.
Possibly, especially if the device is polling again before courier
realizes that the previous poll has timed out.
Anyways, take a look and see if I'm missing something here:
2012-03-22 16:28:28.363847500 INFO: LOGIN, [email protected],
ip=[97.2.78.209], protocol=IMAP
2012-03-22 16:29:41.798428500 INFO: DISCONNECTED, [email protected],
ip=[97.2.78.209], headers=0, body=83133, rcvd=970, sent=102267, time=73
2012-03-22 16:31:46.727932500 INFO: DISCONNECTED, [email protected],
ip=[97.2.78.209], headers=0, body=609203, rcvd=1341, sent=640760,
time=198
2012-03-22 17:21:01.895961500 INFO: TIMEOUT, [email protected],
ip=[97.2.78.209], headers=0, body=177089, rcvd=2103, sent=200534,
time=10572
2012-03-22 17:49:17.330010500 INFO: LOGIN, [email protected],
ip=[97.33.103.230], protocol=IMAP
The fact that it's timing out indicates a problem of some sort. I'm
not positive, but I would guess that the phone isn't configured to
wait long enough for courier to do its thing (which it's very poor at
doing with mailboxes that large). It might need to wait quite some time.
I don't know enough of the details to hazard a guess as to why things
are locking up. I suspect though that either the client or server (or
both) aren't recovering from the timeout properly.
Even if it's the phone that's not doing what it should in this
situation, I expect that dovecot would solve the problem, as it's so
efficient that the timeout would never occur.
Alrighty...dovecot it is! Can't hurt, right?
Casey Price
Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>
Follow us on Twitter <https://twitter.com/#%21/SmileInternet>
Find us on Facebook <https://www.facebook.com/smileglobal>
