From brad at comstyle.com Sat Jan 10 02:25:58 2009 From: brad at comstyle.com (Brad) Date: Sat, 10 Jan 2009 02:25:58 -0500 Subject: [imapproxy-info] 1.2.7rc2? Message-ID: <200901100225.58384.brad@comstyle.com> Looks like 1.2.7rc2 is about 2 months overdue. Any chance of seeing the rc2 release soon? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dave64 at andrew.cmu.edu Mon Jan 12 14:19:19 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Mon, 12 Jan 2009 14:19:19 -0500 Subject: [imapproxy-info] 1.2.7rc2? In-Reply-To: <200901100225.58384.brad@comstyle.com> References: <200901100225.58384.brad@comstyle.com> Message-ID: <496B97B7.6050705@andrew.cmu.edu> Brad wrote: > Looks like 1.2.7rc2 is about 2 months overdue. Any chance of seeing > the rc2 release soon? > It's coming very soon (within a couple days). I apologize for the delay. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From 29e8c6f5 at mail.ru Tue Jan 20 11:12:29 2009 From: 29e8c6f5 at mail.ru (Zohan) Date: Tue, 20 Jan 2009 19:12:29 +0300 Subject: [imapproxy-info] Limit connections on a per-user basis Message-ID: Hi, First of all, thanks for an excellent job. up-imapproxy seems to be the final missing chain in my puzzle. We are trying to set up a webmail service (RoundCube or IMP) with OTP (one-time password) authentication. OTP is implemented on IMAP server level (Dovecot+checkpassword in our case), so each time IMAP connection is established, the password is different. RoundCube (and probably IMP) tries to open new IMAP connection for each operation (with cached password), so it does not work at all. Switching to imapproxy helps, but until it tries to establish another connection (and cache it). The question is, do we have a mechanism to limit per-user connection usage? This limit should be 1 in our case. Thanks in advance! Zohan From dave64 at andrew.cmu.edu Tue Jan 20 11:24:01 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Tue, 20 Jan 2009 11:24:01 -0500 Subject: [imapproxy-info] Limit connections on a per-user basis In-Reply-To: References: Message-ID: <4975FAA1.2070601@andrew.cmu.edu> Zohan wrote: > Hi, > > First of all, thanks for an excellent job. up-imapproxy seems to be the final missing chain in my puzzle. > > We are trying to set up a webmail service (RoundCube or IMP) with OTP (one-time password) authentication. > OTP is implemented on IMAP server level (Dovecot+checkpassword in our case), so each time IMAP connection is established, the password is different. > RoundCube (and probably IMP) tries to open new IMAP connection for each operation (with cached password), so it does not work at all. > Switching to imapproxy helps, but until it tries to establish another connection (and cache it). > The question is, do we have a mechanism to limit per-user connection usage? This limit should be 1 in our case. Have you tried imapproxy in your OTP setup yet? I'm not saying that it does something that's ideal for your situation, but at the very least (if I understand your setup) it should still work. There's already logic in imapproxy to deal with the password changing while a connection is still cached. This logic was never intended to be used in an OTP environment, so I can't say anything about what kind of a performance hit you'd end up taking. I don't fully understand your question, though. When you say "limit per-user connection usage to 1", do you mean that any given user should only be allowed to have a single active connection at any given time? Or do you mean a connection should only be allowed to be re-used 1 time? or something else? Once I know what you're asking for, I may be able to offer further assistance. Thank you, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From 29e8c6f5 at mail.ru Wed Jan 21 13:02:37 2009 From: 29e8c6f5 at mail.ru (Zohan) Date: Wed, 21 Jan 2009 21:02:37 +0300 Subject: [imapproxy-info] =?koi8-r?b?TGltaXQgY29ubmVjdGlvbnMgb24gYSBwZXIt?= =?koi8-r?b?dXNlciBiYXNpcw==?= In-Reply-To: <4975FAA1.2070601@andrew.cmu.edu> References: <4975FAA1.2070601@andrew.cmu.edu> Message-ID: Hi Dave, Thank you for your rapid response. I'm sorry for being obscure; seems like now I've figured out what was the cause of misbehaviour. It's known that RoundCube initiates IMAP connection for each operation, and then closes it. Everything would work quite OK if there were only one per-client RoundCube->imapproxy connection open for any moment of time. But sometimes RoundCube tries to open second connection, with the previous one not being closed. I suppose this to be a RoundCube bug/feature, and seems like imapproxy can't offer suitable workaround, at least unless it implements connection multiplexing (2 or more RoundCube->imapproxy connections -> one persistent imapproxy->server connection); I seriously doubt practical possibility of such multiplexing. Thus, RoundCube forces imapproxy to open second connection to server (using password cached by RoundCube), and this fails due to password invalidation by OTP. I kindly ask you please to share your opinion about what could I do to solve this problem. Right now I tend to try fixing RoundCube's (mis)behaviour. From dave64 at andrew.cmu.edu Wed Jan 21 13:36:25 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Wed, 21 Jan 2009 13:36:25 -0500 Subject: [imapproxy-info] Limit connections on a per-user basis In-Reply-To: References: <4975FAA1.2070601@andrew.cmu.edu> Message-ID: <49776B29.5080105@andrew.cmu.edu> Zohan wrote: > It's known that RoundCube initiates IMAP connection for each operation, and then closes it. > Everything would work quite OK if there were only one per-client RoundCube->imapproxy connection open for any moment of time. > But sometimes RoundCube tries to open second connection, with the previous one not being closed. > I suppose this to be a RoundCube bug/feature, and seems like imapproxy can't offer suitable workaround, at least unless it implements connection multiplexing (2 or more RoundCube->imapproxy connections -> one persistent imapproxy->server connection); I seriously doubt practical possibility of such multiplexing. imapproxy can't multiplex more than one client connection over a single server connection. Attempting to do so would create chaos. This is the reason that imapproxy keeps track of connection state and doesn't try to reuse a server connection unless the client has already logged out. It will create a new connection if the existing connection is still active. > Thus, RoundCube forces imapproxy to open second connection to server (using password cached by RoundCube) ...snipped... It sounds like your problem is that RoundCube is caching the password. If this is the case, imapproxy is not causing your problem and it cannot do anything to fix your problem. Thank you, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From peter.schober at univie.ac.at Wed Jan 21 16:19:54 2009 From: peter.schober at univie.ac.at (Peter Schober) Date: Wed, 21 Jan 2009 22:19:54 +0100 Subject: [imapproxy-info] Limit connections on a per-user basis In-Reply-To: References: <4975FAA1.2070601@andrew.cmu.edu> Message-ID: <20090121211954.GY9824@wssp.cc.univie.ac.at> * Zohan <29e8c6f5 at mail.ru> [2009-01-21 19:03]: > It's known that RoundCube initiates IMAP connection for each > operation, and then closes it. Are your sure? Actually RoundCube took parts from IlohaMail ("The project includes open-source classes/libraries like PEAR and the IMAP wrapper from IlohaMail.org"[1]) which is one of the very few pieces of Webmail software which makes use of persistent IMAP connections, IIRC. Now, the lack of persistent IMAP connections in Webmail packages is the sole reason for the existence of imapproxy. So unless I'm completely off base here imapproxy will not give you anything you don't have already. cheers, -peter [1] http://roundcube.net/about -- peter.schober at univie.ac.at - vienna university computer center Universitaetsstrasse 7, A-1010 Wien, Austria/Europe Tel. +43-1-4277-14155, Fax. +43-1-4277-9140 From slusarz at curecanti.org Wed Jan 21 17:02:14 2009 From: slusarz at curecanti.org (Michael M. Slusarz) Date: Wed, 21 Jan 2009 15:02:14 -0700 Subject: [imapproxy-info] Limit connections on a per-user basis In-Reply-To: <20090121211954.GY9824@wssp.cc.univie.ac.at> References: <4975FAA1.2070601@andrew.cmu.edu> <20090121211954.GY9824@wssp.cc.univie.ac.at> Message-ID: <20090121150214.owswo4osog8s@bigworm.curecanti.org> Quoting Peter Schober : > * Zohan <29e8c6f5 at mail.ru> [2009-01-21 19:03]: >> It's known that RoundCube initiates IMAP connection for each >> operation, and then closes it. > > Are your sure? Actually RoundCube took parts from IlohaMail ("The > project includes open-source classes/libraries like PEAR and the IMAP > wrapper from IlohaMail.org"[1]) which is one of the very few pieces of > Webmail software which makes use of persistent IMAP connections, IIRC. > > Now, the lack of persistent IMAP connections in Webmail packages is > the sole reason for the existence of imapproxy. > > So unless I'm completely off base here imapproxy will not give you > anything you don't have already. > cheers, > -peter > > [1] http://roundcube.net/about Neither ilohamail nor roundcube uses persistent connections (at least they didn't when I was perusing through the code before writing the new Horde IMAP lib several months ago). They both initialize the connection w/fsockopen(), which is not persistent (pfsockopen() creates a persistent connection). This makes sense because in real world usage, PHP persistent connections are worthless. A persistent connection would be cached without regard to the user who is logged in. Obviously, this is totally unacceptable. This doesn't even begin to describe the crushing overhead that would occur if you were serving a webmail site via something like FastCGI, with potentially 10s or 100s of backend PHP servers. With each server keeping a persistent connection open to the IMAP server... yikes. That is why you need a centralized, network-accessible IMAP cache store (thus, imapproxy). A previous disadvantage to using imapproxy was that, even though the connection was cached, there was no way of knowing whether a cached connection was being used or not - thus, the need to potentially do IMAP init stuff on every PHP page load. This was the basis for addition of the XPROXYREUSE status response added in v1.2.7, and used by IMP 5. michael From brad at comstyle.com Sat Jan 24 04:54:15 2009 From: brad at comstyle.com (Brad) Date: Sat, 24 Jan 2009 04:54:15 -0500 Subject: [imapproxy-info] background mode regression Message-ID: <200901240454.15411.brad@comstyle.com> After upgrading from imapproxy 1.2.5 to anything newer it has resulted in a regression with the background mode. If running in the foreground it still works fine. I still haven't quite figured out why but adding some additional syslog messages to the code I can see that when the client connects to the socket that the connection is accept()ed, pthread_create() is called but HandleRequest() is not being called as expected. OS in use is OpenBSD -current. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From brad at comstyle.com Sat Jan 24 04:57:24 2009 From: brad at comstyle.com (Brad) Date: Sat, 24 Jan 2009 04:57:24 -0500 Subject: [imapproxy-info] imapproxy's IPv6 support is broken. Message-ID: <200901240457.24244.brad@comstyle.com> Trying out the IPv6 support in imapproxy I see that imapproxy does not properly bind to the appropriate sockets if you specify a hostname to listen on which resolves to both a IPv4 and IPv6 address which results in only an IPv6 socket meaning the IPv4 support is broken. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dave64 at andrew.cmu.edu Tue Jan 27 15:08:40 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Tue, 27 Jan 2009 15:08:40 -0500 Subject: [imapproxy-info] imapproxy-1.2.7rc2 available for download Message-ID: <497F69C8.2020502@andrew.cmu.edu> Good afternoon, up-imapproxy-1.2.7rc2 is now available for download at: http://www.imapproxy.org/downloads/up-imapproxy-1.2.7rc2.tar.gz This release candidate is identical to the 1.2.7rc1 candidate, but includes a patch by Michael Slusarz to fix an issue that came up with CAPABILITY response strings in 1.2.7rc1. Thank you, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services