NOTE: this is a followup to a thread that was started on the imapproxy-info mailing list just after I had announced the change of mailing list locations. You can see the original thread here:
http://lists.andrew.cmu.edu/pipermail/imapproxy-info/2010-August/thread.html#891 > > > $ ps aux | grep -i imap > > > root 6393 0.0 0.0 4404 892 ? S 21:50 0:00 > > > /usr/sbin/imapproxyd -f /etc/imapproxy.conf > > > > > > /etc/imapproxy.conf > > > listen_address 127.0.0.1 > > > listen_port 1143 > > > proc_username nobody > > > > > > $ sudo netstat --protocol=inet --extend --all --program | grep -i imap > > > tcp 0 0 192.168.1.6:46525 gw-in-f109.1e100.:imaps > > > ESTABLISHED root 2637125 25917/imapproxyd > > > > > > /var/log/syslog > > > Aug 7 21:50:28 veridian imapproxyd: main(): Using configuration file > > > '/etc/imapproxy.conf' > > > Aug 7 21:50:28 veridian imapproxyd: Using syslog facility 'LOG_MAIL' > > > for logging. > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: No syslog priority mask > > > specified. > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: main(): SELECT caching is > > > disabled > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: main(): Internal admin > > > commands are disabled > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: main(): Allocating 3072 > > > IMAP connection structures. > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: ServerInit(): Using > > > '/var/log/imapproxy_protocol.log' for global protocol logging file. > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: ServerInit(): proxying > > > to IMAP server 'imap.gmail.com'. > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: ServerInit(): Proxying > > > to IMAP port 993 > > > Aug 7 21:50:28 veridian in.imapproxyd[6391]: Daemonize(): Configured > > > to run in background mode. Well, it's baffling to me why you got the "Daemonize" message if it was hanging in SetBannerAndCapability() waiting to read something from the server that was never going to come. In any case, a couple clues are that you are missing some startup log entries. After the "Proxying to IMAP port..." message, you'll typically see log entries like this: Aug 13 16:08:00 veridian in.imapproxyd[8531]: main(): Binding to tcp *:144 Aug 13 16:08:00 veridian in.imapproxyd[8531]: main(): Using global statistics file '/var/run/pimpstats' Then you get the "Daemonize" entry: Aug 13 16:08:00 veridian in.imapproxyd[8531]: Daemonize(): Configured to run in background mode. And finally, you know all is well when it tells you about "normal server startup": Aug 13 16:08:00 veridian in.imapproxyd[8535]: BecomeNonRoot(): Process will run as uid 99 (nobody) and gid 99 (nobody). Aug 13 16:08:00 veridian in.imapproxyd[8535]: main(): Launched ICC recycle thread with id -1209218144 Aug 13 16:08:00 veridian in.imapproxyd[8535]: main(): squirrelmail-imap_proxy version 1.2.7 normal server startup. Of course, there's no way you could have known what log entries to look for, but for the sake of anyone else seeing this in the future, this may help diagnosis. The other hint that something is wrong is that the startup script should hang, waiting for IMAP Proxy to daemonize, but apparently, you found a way to make it return from that blocking read (waiting on the server to respond on port 993). My tests produce what I would expect: it never daemonizes, and the startup script hangs because function IMAP_Read() is sitting around waiting for something that will never happen. > > > You can see several problems. Mainly imapproxy does not bind to > > > 127.0.0.1:1143, as though it did not read the configuration file, but > > > also it fails to drop privileges. In fact, from "strace -f" I see no > > > mention of "1143" or "nobody". > > > > > > I've tried: > > > imapproxy (1.2.4-10.2) > > > - from ubuntu hardy, problems as above > > > imapproxy (1.2.6-5) > > > - from ubuntu lucid, additionally will not background > > > imapproxy 1.2.7 > > > - from source, cumulative problems from above (yep, it won't background) > > > > > > So, why is this program so drastically broken, and it seems, > > > especially for me only?? :) > > > > > > > Surprisingly all my issues are with the server side, not the local > > side, of the imapproxy configuration. > > > > server_hostname imap.gmail.com > > server_port 993 > > > > Since (iirc) imapproxy doesn't support directly encrypted connections > > but instead must use STARTTLS (usually port 143) to upgrade a > > plain-text channel, Right. This is made clear in the README.ssl file, where it states that imaps on port 993 is not supported. To help people who don't catch that in the future, I've added some more warnings to that file, the configuration file itself, AND added a syslog warning when server_port is set to 993. > > and since any attempt to communicate across an SSL > > channel requires client input before a server response is produced, > > imapproxy will just hang out in SetBannerAndCapability() waiting for a > > read that will never occur. > > > > Perhaps a timeout with select() in IMAP_Line_Read will make this > > simple mistake much less baffling. This would require changing the socket to be non-blocking, and I am not entirely sure what the consequences of doing that would be in all other cases where things work as they should. Patches are always welcome, but for now, the added warnings I have added might suffice. > > An case: anyone know how to use Gmail IMAP with STARTTLS ? If you figured it out, please follow up your questions for the edification of the list archives. > well, so I've successfully set up a [roundcubemail -> imapproxy -> > perdition -> gmail] proxy chain Please consider sharing anything from your setup that you think could be useful to the community and others who come looking for tips on how to do similar things. > but I have yet to notice any > performance gains? Is this because perdition drops the connections that > imapproxy caches? Should I be running [roundcubemail -> perdition -> > imapproxy -> gmail] instead? Or not? That could be the case. You might want to ask the perdition community - I'm sure they could answer this question quickly. On the other hand, maybe your hardware or network or server load is such that it would be hard to detect any performance gains. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ----- squirrelmail-imapproxy mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: [email protected] List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy
