Am 20.08.2013 01:45, schrieb Stan Hoeppner:
On 8/19/2013 4:10 PM, Reindl Harald wrote:
may i suggest you read about how IMAP IDLE works?
Oh, well sure, if you hang your hat on IDLE then your arguments here might make sense. But because of the brain dead one socket per folder architecture of IDLE few have adopted it en masse. Which is why my comments ignored the existence of IDLE. And which is also why the creators of the RFC stated clients must not count on the existence of IDLE and must poll, which seems really odd. Many have, and still ask, why even have IDLE then if we must still poll?
http://tools.ietf.org/html/rfc2177
"(While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can't expect this behaviour and must poll.)"
Given the option of potentially dozens of open sockets between his server and any client simply to allow IDLE to work for all folders, or one or two connections and strictly client polling, I'd guess most admins will choose the latter
why we have IDLE is easy explained, i get around 500 mails per day well, i can't imagine my personal work-load woking without IDLE
30 folders sorted with Sieve
- several lists with own folders
- company (there folders, one for internal lists)
- customers
- vendors
- server-status (logwatch, mail-stats of 20 servers)
- error-notifies from watchdog (own cron-watchdogs, HP ILO, VMware vSphere, UPS...)
INBOX is a place where rarely a message comes in and with K9 on Android it's easy to select which folders should be considered for the common-inbox and which are pointless on a mobile (INBOX is none of them)
on a mailserver which can handle thousands of connections there is rarely a reason to disable IDLE and so a connection limit of 10 per IP is questionable