Front End Mail Server

[TommyTheKid]

We use a multi-tiered server infrastructure like...

(Internet)
==============
(load balancer)
[fe-1] [fe-2] [fe-3] [fe-4] ... [fe-n]
[mta-in-1] [mta-in-2] ... [mta-in-n]
[mta-out-1] [mta-out-2] ... [mta-out-n]
==============
[[be-1-a][be-1-b]] [[be-2-a][be-2-b]] ... [be-m-a][be-m-b]]
[ldap-master-1] <-MMR-> [ldap-master-2]

-----------

So, there are "n" front-end hosts behind a firewall and load balancer, then another firewall between the frontends and the "m" clusters of back-ends, and LDAP servers (and other various "data tier" machines). When a user logs in, they authenticate via LDAP and the front-end "server" proxies them to the proper "backend" host (be-2 for example) .. The system "be-2" is normally a cluster (a and b nodes), but for now, we are not clustering the backend to keep things simple, also we don't have (the need for) web based power switches that RHCS seems to require?

Anyhow,
I cannot figure out the proper set of options to configure the front-end servers. Creating an MTA-only is fairly easy, but I want an MTA, webmail interface (to include mobile sync capability), and imap proxy on one host, but not a store.

I have found that perdition doesn't seem to install unless you choose a store, but now I am in the configuration and its having me create all this unnecessary stuff (domains/users/etc).. How should I configure this screen for a simple front-end proxy? I have already pointed it at our LDAP master (does openldap not support multi-master?)..

I tried going through by just enabling the proxy, but lots of stuff was failing cause it wanted to contact mysql (?) and was also trying to contact the admin port on the backend host. I also note that the backend is attempting to contact the front-end admin port (and maybe others?)..

So, questions are...

1. is there a way to install a front-end mail server that is similar in function to the mta-only host, but also has perdition and whatever is necessary to make webmail work (assuming it can run on the front end and connect to the backend via (???))

2. what port opening are necessary in the firewall besides the basic 25/80/143/443/993 ?

Thanks in advance,
~tommy

[dkarp]

With the AJAX client, lots of stuff that'd normally happen in a middle tier server now happens directly in the browser. So the server-side tier that'd normally be providing the webmail service is unnecessary. All that's left is a SOAP interface to the store, and there's not much (if anything) to be gained from taking that out-of-process.

[TommyTheKid]

We have these rules/policies/etc that essentially say that we can't put "data" (mailstore) on an Internet facing server. The only way we have been able to make in accessible from the Internet (for users) is to use a proxy interface on the Interet facing servers. I don't know that this really solves anything security wise, but I don't make the rules, I just bend them

Our current system runs an IMAP/POP proxy, MTA and essentially a "web proxy" (tho its all built into the mailserver product) on the front-end. As you login to "webmail" it looks your account up in LDAP and proxies your connection to the proper backend which accesses the mailstore directly. Of course if you were logged into your backend directly (not possible in our config), it would just process your webmail directly.

We could probably configure the front end systems as "stores" but never provision a user there, and perdition would probably proxy IMAP connections to the proper backend (if I understand that), however it looks like webmail tries to send a referral/redirect, which wouldn't work. We could fabricate a simple apache rProxy, but that wouldn't scale.

Anyone can do IMAP, the main reason we are looking at Zimbra is the web interface (mobility specifically) so its probably the most important.

Any hints?

~tommy

[dkarp]

Originally Posted by TommyTheKid

We could probably configure the front end systems as "stores" but never provision a user there, and perdition would probably proxy IMAP connections to the proper backend (if I understand that), however it looks like webmail tries to send a referral/redirect, which wouldn't work. We could fabricate a simple apache rProxy, but that wouldn't scale.

Anyone can do IMAP, the main reason we are looking at Zimbra is the web interface (mobility specifically) so its probably the most important.

In general, you can get away with a Zimbra server with no provisioned accounts as a proxy -- virtually everything will be properly proxied to the appropriate host. The exception is that the Zimbra Mobile traffic is not proxied appropriately. I'll chat with the developer in charge of that and see if there's a workaround.

[jjzhuang]

There's a ticket #9469 open to get mobile proxy done as enhancement, but according to current release planning that feature is not in 5.0. If this feature is important to you, please either open a support case or vote for the bug in bugzilla. Or do both.

J.J.

[Klug]

For "tinier" setup, is there a problem with using an apache as reverse-proxy with Zimbra Mobile ?

[jjzhuang]

No mod_proxy will work just fine. If the only requirement is to add another hop to satisfy policy rules, mod_proxy is perfect. #9469 is more for scalability. Sorry I didn't point that out.

J.J.

[ryan.d]

Sorry to bring an old thread back from the dead here, but I am looking at putting together an identical setup to what the original post explained. Is this a viable setup for offloading connection management and letting storage-attached servers get on with the business of mailbox management?

If this is viable, what zimbra components need to be installed on the front end in order to proxy webmail?