IMAP proxy recommendations.
d.banschikov at hostcomm.ru
Thu Dec 12 14:06:20 EST 2013
On Thu, Dec 12, 2013 at 12:25:45PM -0600, ktm at rice.edu wrote:
> On Thu, Dec 12, 2013 at 01:11:19PM -0500, sofkam wrote:
> > I am in the process of replacing our Cyrus Front-End servers with a
> > proxy server that can front both Exchange and Cyrus IMAP, as well as
> > future IMAP hosts as we move and migrate users. The two that stand out
> > are: Perdition, and NGinX. I'm looking for recommendations, or
> > experience with either, or additional suggestions to examine.
> > Initially it will replace the old (and back-leveled) Cyrus Front-End
> > servers in our murder aggregate, and I would like that process to be
> > smooth and transparent. But the proxy will then be switching back-ends
> > based on Exchange vs Cyrus hosted IMAP (Currently Exchange users are
> > told to configure their clients with a different server, a practice we
> > would like to discontinue.) We will also be migrating users (usually
> > from Cyrus to Exchange, but the other direction happens as well), and we
> > would like this process to be as transparent as possible. Finally, our
> > Webmail server will also be using the proxy, so a proxy that maintains
> > state-full connections would be a plus, but this takes second place to
> > location transparency.
> > Because of the need to host multiple back-ends based on account, I have
> > not so far been considering imapproxy, even though this provides the
> > state-full connections.
> > Any thoughts or suggestions welcome.
> > Thank You,
> > Mike
> > --
> > Michael D. Sofka sofkam at rpi.edu
> > C&MT Sr. Systems Programmer, Email, TeX, Epistemology
> > Rensselaer Polytechnic Institute, Troy, NY.
> > http://www.rpi.edu/~sofkam/
> Hi Mike,
> We started with the perdition IMAP proxy and while it worked well, its
> process-based architecture resulted in a very heavy resource footprint --
> a process per connection. When we upgraded our frontends we moved to
> nginx as the IMAP proxy, and it had a much lower resource footprint, a
> thread per connection, and better high load performance. We also use
> imapproxy to provide a stateful connection for our webmail system to
> our IMAP proxy. We can definitely recommend this setup. In fact, when
> we moved our student to Google mail, the transition was made without
> the need to reconfigure any end user clients and our webmail worked
> as well. Please let me know if you have any questions about our use.
JFYI Nginx doesn't use threads at all. Nginx worker is
asynchronous single threaded process, which utilize UNIX async IO
operations on the sockets and uses some event notification
mechanisms like select/poll/epoll/kqueue/sigio.
Problems with Nginx:
1) Nginx doesn't support SSL/StartTLS on the connections to mail backends.
It means that you authentication data will go in plain mode over
the network to backends.
2) Nginx doesn't support proxing of Sieve protocol.
Dovecot proxy support it.
3) You must ensure, that Nginx presents to the user the same list
of capabilities, like your backends for POP and IMAP.
Otherwise MUA can become crazy.
4) Shared folders will not work between multiple backends
5) Nginx for SMTP doesn't pass user authentication data to the
backends. Optionally you can use xclient extension.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4573 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20131212/eca9b626/attachment-0001.bin
More information about the Info-cyrus