[SOLVED] Create E-Mail Form & Host on Zimbra Jetty

Hello everyone,

I am trying to create a public-facing web form that will allow users to fill out the form and submit it securely through the web server and directly to the mail server (since it's being hosted on our mail server). The mail server currently requires https connections so when pulling up the page under the /opt/zimbra/jetty/webapps/zimbra/* (https://mail.server.com/*) folder it is secured between the browser and server. My logic is that since that part is secure...I can get around the insecurity of e-mail because the recipient is on the local mail server...so when the public user submits the form...it would get sent internally without worry of the data being intercepted.

However, my problem is this...I wrote the form originally in PHP and not realizing that JSP is the only language supported. However, I also tried an example JSP mail form and that didn't work, either. Are there any special procedure calls or anything that I am missing to make this work? If anyone has a sample of a web form that works on the Zimbra web server, that would be great! I will also want to incorporate reCaptcha but I believe I can just add the code on the API page and it will work. Of course, if someone has all of this already done and working, it would be much appreciated.

By the way, I know the aspell apache instance works fine with PHP but it doesn't support encryption plus it uses a non-standard port. I'd prefer to use 443 so end-users won't have to battle their firewalls (potentially).

Thanks for any help you can provide!

Last edited by cyberdeath; 08-27-2012 at 03:48 PM.
Reason: Marked as [SOLVED]

I realize it has been some time since I have said anything on here in reference to my dilemma. However, I was able to get this working on my own and I wanted to share my solution with others in case someone could benefit.

As you might know, the aspell instance of apache supports PHP (after all, aspell *is* PHP). However, my hurdle was that I did not want to use that non-standard port (7780) NOR did I want to do it insecurely. I also did not want to have to run a second apache instance (which would require another IP address or another, different, non-standard port on an existing one).

Hence where my workaround/solution came into play...using nginx. I have used nginx in other scenarios (non-traditional) and this one worked out just fine, too. NOTE: You need nginx installed in order to do this. The Zimbra Wiki explains how to accomplish this for fresh/new installs as well as current installs...but basically you run the current version installer and select to install nginx.

Workaround instructions:

First off, you must navigate to /opt/zimbra/conf/nginx and look at your includes (the folder & content inside). Since I only want to use HTTPS, the only one I need to be concerned with is nginx.conf.web.https. NOTE: You will also need to modify the corresponding template under ../templates/

Inside nginx.conf.web.https, you will notice at the top it mentions "server" and open {...right after the SSL information, you will see:

Code:

location /

This is where the trick comes in. Copy and paste the entire location block all the way down to the corresponding close bracket } . As of the current version of Zimbra NE (7.2.0 P1), this is right above the note about long polling of Microsoft ActiveSync.

After copying that code, you will want to throw in a couple carriage returns below the } and paste the location / again. However, you will want to change:

Code:

location /

to something else...like:

Code:

location /secureform/

Inside of this location, you will need to change the following lines of code from 8080 (or whatever it was originally) to:

The rest of this you should be able to leave the same as it were on the original.

Once you complete this, you will need to restart your nginx instance using zmnginxctl restart. However, you might want to hold off on this until you actually get some content for that secureform page. Also, if you do this and it does not come back up, hopefully you made a backup copy of the config file before you modified it so you can place it back. You can also read through the log files to see exactly what happened...usually it's something simple like a syntax error (missing a ; or a }).

Now that we have that all taken care of you will want to go back into /opt/zimbra/httpd/htdocs and create a folder called secureform (or whatever you called it). Note that root may be owner of this folder. You will then put whatever content is necessary including an index.html or modifying the /opt/zimbra/conf/httpd.conf file accordingly to point to another default location (such as index.php). Once you have all your code cleaned and ready, you might want to go ahead and zmnginxctl restart and maybe even zmspellctl restart just for good measure (especially if you modified httpd.conf).

Once you have finished all of this, you should now be able to visit https://subdomain.domain.tld/secureform and access it using HTTPS while using the php backend that is not available using normal jetty. So, now you have an SSL authenticated page that is hosted like it's part of jetty without having to run a second apache instance and/or a non-standard port. This is *excellent* for use with web e-mail forms as the server connection will be secure and the submission will be secure so long as you ONLY send e-mail to users on the server as a result of said e-mail form submission (AND they are not using forwarding to an outside e-mail address).

IMPORTANT NOTE: You will need to back up all of your files in the folder under /opt/zimbra/httpd/htdocs as it will be overwritten or no longer usable after each upgrade to Zimbra. Further, you will need to re-add the code in the nginx includes file (& template) after each upgrade as well.

Hopefully this helps! If anyone has any questions, comments, or would like to make a suggestion, please do not hesitate to do so. I ask/encourage you to ask any and all questions in the forums so that others may help answer and/or it will at least serve as an "FAQ" for others who may have the same questions.

DISCLAIMER: I take no responsibility whatsoever as to what you end up doing or not doing after reading this, especially to your production server. As with most changes like these, I would suggest using a dev box if at all possible. If none is available, you might want to do this when users are least active (at the very least)... or build a dev box!