From ben at electricembers.net Thu Mar 5 15:45:40 2009 From: ben at electricembers.net (ben at electricembers.net) Date: Thu, 5 Mar 2009 12:45:40 -0800 (PST) Subject: [imapproxy-info] make fails because my openssl was built without thread support Message-ID: even though i configured it --without-openssl. . . is this a bug? or am i simply forced to (re)build openssl with threads (slighly scarry on a production server.) From dave64 at andrew.cmu.edu Thu Mar 5 16:49:31 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Thu, 05 Mar 2009 16:49:31 -0500 Subject: [imapproxy-info] make fails because my openssl was built without thread support In-Reply-To: References: Message-ID: <49B048EB.8000305@andrew.cmu.edu> ben at electricembers.net wrote: > even though i configured it --without-openssl. . . > > is this a bug? or am i simply forced to (re)build openssl with threads > (slighly scarry on a production server.) A bug? Of course not!! :) Unfortunately, some time ago I made a decision to always require OpenSSL even if you don't plan to use TLS. imapproxy uses the base64 encoding/decoding routines from the OpenSSL libs. If you're truly terrified of throwing a new OpenSSL on your production machine, you can grab an older version of imapproxy that came with its own base64 routines (and didn't use the ones from OpenSSL) and use that to create a patch for the new version that should compile by changing a few lines of code. If you're interested in doing this and you need further assistance, let me know off-list. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From husmann at morningside.edu Wed Mar 11 14:55:49 2009 From: husmann at morningside.edu (Mike Husmann) Date: Wed, 11 Mar 2009 13:55:49 -0500 Subject: [imapproxy-info] imapproxy and tls Message-ID: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> Hello, I currently have imapproxy running on the same host as my mail server, so no tls has been required. However, now I'm moving the web server off, and tls is required. I have put entered the the entries for my ssl certs (same as my imap server) into the appropriate fields in imapproxy.conf, but I still can't get imapproxy to advertise STARTTLS when I telnet to it. I don't see any errors in the logs, and I'm wondering what I missed. If I purposefully break the name of the ssl cert in imapproxy.conf, I don't see any complaints - indicating to me that it's not even trying to use them? Any ideas as to where I can look for mistakes? Thanks in advance, Mike -- Mike Husmann Senior Systems Administrator Morningside College From dave64 at andrew.cmu.edu Wed Mar 11 15:20:02 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Wed, 11 Mar 2009 15:20:02 -0400 Subject: [imapproxy-info] imapproxy and tls In-Reply-To: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> References: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> Message-ID: <49B80EE2.9080609@andrew.cmu.edu> Mike Husmann wrote: > Hello, > I currently have imapproxy running on the same host as my mail > server, so no tls has been required. > > However, now I'm moving the web server off, and tls is required. > > I have put entered the the entries for my ssl certs (same as my imap > server) into the appropriate fields in imapproxy.conf, but I still > can't get imapproxy to advertise STARTTLS when I telnet to it. I > don't see any errors in the logs, and I'm wondering what I missed. Hi Mike, imapproxy will only ever do TLS between imapproxy and the imap server. It doesn't support TLS between a client (webmail, in your case) and imapproxy. Hence, it should never advertise STARTTLS. The theory is that you always keep imapproxy running on the same host as your webmail server. That way, no traffic from webmail to imapproxy has to traverse the network. If your mail server is on a different host, imapproxy can to TLS to your mail server. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From husmann at morningside.edu Wed Mar 11 15:21:38 2009 From: husmann at morningside.edu (Mike Husmann) Date: Wed, 11 Mar 2009 14:21:38 -0500 Subject: [imapproxy-info] imapproxy and tls In-Reply-To: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> References: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> Message-ID: <20090311142138.47587rh9zws40ev6@squirrelmail.morningside.edu> Quoting Mike Husmann : > Hello, > I currently have imapproxy running on the same host as my mail > server, so no tls has been required. > > However, now I'm moving the web server off, and tls is required. > > I have put entered the the entries for my ssl certs (same as my imap > server) into the appropriate fields in imapproxy.conf, but I still > can't get imapproxy to advertise STARTTLS when I telnet to it. I > don't see any errors in the logs, and I'm wondering what I missed. > > If I purposefully break the name of the ssl cert in imapproxy.conf, I > don't see any complaints - indicating to me that it's not even trying > to use them? I did find the error - in.imapproxyd[4876]: main(): Failed to load CA data. Exiting. So it doesn't like my ssl certs. I've got pem formatted certs. I take it that's not what imapproxy is looking for? Thanks, Mike From husmann at morningside.edu Wed Mar 11 15:44:50 2009 From: husmann at morningside.edu (Mike Husmann) Date: Wed, 11 Mar 2009 14:44:50 -0500 Subject: [imapproxy-info] imapproxy and tls In-Reply-To: <49B80EE2.9080609@andrew.cmu.edu> References: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> <49B80EE2.9080609@andrew.cmu.edu> Message-ID: <20090311144450.214425kft5z5ckoi@squirrelmail.morningside.edu> Quoting Dave McMurtrie : > Mike Husmann wrote: >> Hello, >> I currently have imapproxy running on the same host as my mail >> server, so no tls has been required. >> >> However, now I'm moving the web server off, and tls is required. >> >> I have put entered the the entries for my ssl certs (same as my imap >> server) into the appropriate fields in imapproxy.conf, but I still >> can't get imapproxy to advertise STARTTLS when I telnet to it. I >> don't see any errors in the logs, and I'm wondering what I missed. > > Hi Mike, > > imapproxy will only ever do TLS between imapproxy and the imap server. > It doesn't support TLS between a client (webmail, in your case) and > imapproxy. Hence, it should never advertise STARTTLS. > > The theory is that you always keep imapproxy running on the same host as > your webmail server. That way, no traffic from webmail to imapproxy has > to traverse the network. If your mail server is on a different host, > imapproxy can to TLS to your mail server. Thanks for the quick response. I did install imapproxy on the new box, and it works great for non-tls transactions. Our cyrus 2.3.7 mail server advertises this upon login: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS] However, it currently doesn't require tls connections (although that is coming in the future). Is force_tls the way to require imapproxy to use tls when talking to the imap server? When I turn that on, that's when imapproxy tells me: main(): Failed to load CA data. Exiting. and it bombs out. What ssl certs info do I need to make this work? Thanks so much, Mike From dave64 at andrew.cmu.edu Wed Mar 11 18:19:48 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Wed, 11 Mar 2009 18:19:48 -0400 Subject: [imapproxy-info] imapproxy and tls In-Reply-To: <20090311144450.214425kft5z5ckoi@squirrelmail.morningside.edu> References: <20090311135549.168263exhfx2uqt1@squirrelmail.morningside.edu> <49B80EE2.9080609@andrew.cmu.edu> <20090311144450.214425kft5z5ckoi@squirrelmail.morningside.edu> Message-ID: <49B83904.3080408@andrew.cmu.edu> Mike Husmann wrote: > Thanks for the quick response. I did install imapproxy on the new > box, and it works great for non-tls transactions. Our cyrus 2.3.7 > mail server advertises this upon login: > * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS] > > However, it currently doesn't require tls connections (although that > is coming in the future). Is force_tls the way to require imapproxy > to use tls when talking to the imap server? That's correct. By default, imapproxy will only attempt STARTTLS if your imap server advertises LOGINDISABLED. Setting force_tls in imapproxy.conf will cause imapproxy to always use STARTTLS. > When I turn that on, > that's when imapproxy tells me: > main(): Failed to load CA data. Exiting. > and it bombs out. That's less than ideal. > What ssl certs info do I need to make this work? The error indicates that the CA cert is either not being found or it cannot be verified. tls_ca_path should be set to the directory that contains your certificate authority cert in pem format. tls_ca_file should be set to the file that contains your certificate authority cert in pem format. There's an example using a self-signed cert in README.ssl that might be helpful to you. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services From japc at co.sapo.pt Wed Mar 11 21:09:37 2009 From: japc at co.sapo.pt (Jose Celestino) Date: Thu, 12 Mar 2009 01:09:37 +0000 Subject: [imapproxy-info] File descriptor leak issue Message-ID: <20090312010937.GA15592@co.sapo.pt> Hi. There's a file descriptor leak issue on not checking the pthread_create() return value on the main for(;;) loop. If there's a connection burst and pthreads stack allocation temporarily fails clientsd descriptors are not properly closed and will leak. Attached is a patch that fixes this. -- Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc ---------------------------------------------------------------- "One man?s theology is another man?s belly laugh." -- Robert A. Heinlein -------------- next part -------------- A non-text attachment was scrubbed... Name: imapproxy-1.2.7rc2-pthread_create_fd_leak.diff Type: text/x-diff Size: 575 bytes Desc: not available Url : http://lists.andrew.cmu.edu/pipermail/imapproxy-info/attachments/20090312/0e0840bb/attachment.bin From slusarz at curecanti.org Wed Mar 25 18:38:25 2009 From: slusarz at curecanti.org (Michael M. Slusarz) Date: Wed, 25 Mar 2009 16:38:25 -0600 Subject: [imapproxy-info] Discarding IDLE In-Reply-To: <20090302041855.GE6607@co.sapo.pt> References: <20090302041855.GE6607@co.sapo.pt> Message-ID: <20090325163825.0s80c40ggkkk8@bigworm.curecanti.org> Quoting Jose Celestino : > Hi. Anyone knowns what is the rationale for discarding IDLE from the server > capability ? Late (and lengthy) response to this question... IDLE is of limited/no use to a disconnected client because, in theory, the disconnected client shouldn't be idling. In the webmail case, an IMAP connection gets a burst of activity all at once and then returns to an inactive state. There is no reason to implement the IDLE command because the MUA will not need to track the change of the mailbox over the course of the limited amount of time it is connected (in webmail clients, less than a second). And IDLE is not currently useful during the inactive state either. First, the current imapproxy procedure. Let's say the MUA has selected the INBOX. On MUA logout imapproxy returns the IMAP connection to the AUTHENTICATED state (via either the UNSELECT or SELECT ). On the next successful login from the MUA, imapproxy will pass control to the IMAP server in the AUTHENTICATED state - which is *exactly* what the IMAP client exepects. IDLE was designed to be used only when a mailbox is selected. Let's use the same example as above with the INBOX. This time, on logout, imapproxy issues a IDLE command (thus, the active proxy connection is still connected to INBOX). Further more, let's assume imapproxy reads and stores all IDLE responses returned from the server. On successful login, imapproxy necessarily needs to cancel the IDLE operation. imapproxy can then do one of two things. 1. To remain transparent (and thus, by defintion, a proxy), imapproxy needs to revert back to the AUTHENTICATED state because that is what the IMAP client expects/requires. However, all the IDLE data becomes useless at this point - the various responses received by IDLE are useful only if the mailbox is selected. Thus, imapproxy can't replay those messages automatically at login because the IMAP client won't know what to do with it (there is no mailbox context). And we can't replay once we select the IDLE'd mailbox because the cache responses may no longer be correct and, regardless, much of that information is superfluous because SELECT/EXAMINE provides a lot of the information needed automatically. 2. Instead, imapproxy could theoretically remain in the mailbox and replay all cached responses to the client on login. However, this would require some sort of mechanism whereby the proxy server must inform the mail client which mailbox is currently selected. This is bit currently available and would need to be coded by someone. Theoretically this could be done via an imapproxy specific enabling command. Theoretically it could look something like this: 1. (1st connection) Client connects to imapproxy, issues the following UNAUTHENTICATED command: C: 1 XPROXY_USEIDLE S: 1 OK 2. Client login, SELECTs INBOX, and ends session. 2. Client stores state that he is SELECTed to INBOX 3. Server sends IDLE command in INBOX 4. Client connects to imapproxy and tells imapproxy its cached state information: S: * OK [CAPABILITY ...] C: 1 XPROXY_IDLE username SELECT INBOX S: 1 OK XPROXY_IDLE