Tere.

wont work. as you can do many operations after 1 login. at login, when this msg is written to the log, the imap server cant know what you will do.

Really? Debug log and common log are different things. I'd just like to get some option, that in common mail logs one user's login's are summerised. I can't imagine what kind of log traffic these servers, which have a lot imap users with subfolders, are running?

Btw - isn't this massive log writing a very big performance loss?

-- Sysadmin

Timo Sirainen wrote:

On Tue, 2006-07-11 at 16:23 +0300, Sysadmin wrote:

...

Hello.

Migrating from pop3 to imap I have now situation, that every user has a lot sub folders, for example 100 sub folders and now every mail check writes in the mail log also login/logout log for every sub folder:

dovecot: Jul 11 16:16:31 Info: imap-login: Login: anti, [192.168.20.1], PLAIN, TLS dovecot: Jul 11 16:16:31 Info: IMAP(anti): Disconnected in IDLE

What client is doing this? Either it's a bug in the client or the client is behaving in a really stupid way. There's no point in creating a new connection for each mailbox.

Well, speaking from the client's perspective, it makes perfect sense to have five idling connections to five mailboxes that are expected to receive new mails rather than doing periodical STATUS polls on them. No client should rely on such a behavior, though, and a lot of people would probably say that it's insane to open 100 concurrent connections. I'd agree with them :)

Cheers, -jkt

-- cd /local/pub && more beer > /dev/mouth

On Fri, Aug 11, 2006 at 02:48:01AM +0200, Jan Kundrát wrote:

Timo Sirainen wrote:

...

On Tue, 2006-07-11 at 16:23 +0300, Sysadmin wrote:

...

Hello.

Migrating from pop3 to imap I have now situation, that every user has a lot sub folders, for example 100 sub folders and now every mail check writes in the mail log also login/logout log for every sub folder:

dovecot: Jul 11 16:16:31 Info: imap-login: Login: anti, [192.168.20.1], PLAIN, TLS dovecot: Jul 11 16:16:31 Info: IMAP(anti): Disconnected in IDLE

What client is doing this? Either it's a bug in the client or the client is behaving in a really stupid way. There's no point in creating a new connection for each mailbox.

Well, speaking from the client's perspective, it makes perfect sense to have five idling connections to five mailboxes that are expected to receive new mails rather than doing periodical STATUS polls on them. No client should rely on such a behavior, though, and a lot of people would probably say that it's insane to open 100 concurrent connections. I'd agree with them :)

Another issue with this problem is that it should be totally hidden from the user. I've seen this happening with Thunderbird which, if I remember correctly, defaults to a maximum of five connections and even this often conflicts with ISP (and other) IMAP setups. The result is an error message which 99% of users can't understand and can't fix.

The MUA and the IMAP server should 'negotiate' a mutually acceptable number of ports.

-- Chris Green (chris@halon.org.uk)

On Fri, Aug 11, 2006 at 01:09:03PM +0200, Jan Kundrát wrote:

cl@isbd.net wrote:

...

...

Well, speaking from the client's perspective, it makes perfect sense to have five idling connections to five mailboxes that are expected to receive new mails rather than doing periodical STATUS polls on them. No client should rely on such a behavior, though, and a lot of people would probably say that it's insane to open 100 concurrent connections. I'd agree with them :)

Another issue with this problem is that it should be totally hidden from the user. I've seen this happening with Thunderbird which, if I remember correctly, defaults to a maximum of five connections and even this often conflicts with ISP (and other) IMAP setups. The result is an error message which 99% of users can't understand and can't fix.

The MUA and the IMAP server should 'negotiate' a mutually acceptable number of ports.

Any ideas about the proper negotiation algorithm? The easiest way would be to try opening as many connections as desired, until the server starts killing them. That won't be much robust, though, as the server can close the connection for variety of other reasons.

The best way that comes to my mind is limiting the number of parallel connections in client's config.

Except that there's no one value that would be right for all situations - so then how does the user know what value to set?

What I was suggesting probably isn't in the IMAP RFC (if that's what's driving all this). One needs the IMAP server to tell the MUA how many simultaneous connections it will allow.

-- Chris Green (chris@halon.org.uk)