Yep, some time ago I had it running here as test. Not used it in real live. On Tuesday 23/04/2013 at 13:54, Chris Ferebee wrote: Those are some good points, and I'll give Apache another look for my next SurgeMail server installation. IIS, I'm afraid, will remain beyond me. :-)
Are you using the CalDAV features in your setup?
Best, Chris
Am 23.04.2013 um 13:30 schrieb Steffen <HIDDEN@n@land10.nl>:
Sure you get it running with SSL with help of Marijn. But for me, using Apache in front of Surge has advantages, think about Compression(deflate), SSL Beast Attack, mod_security, SNI, expire headers, IP deny etc. In fact I am using IIS (Proxy only) in front of Apache, so I have: IIS ==> Apache ==> Surge. IIS has the best native network handling. So the best of the tree worlds. Steffen On Tuesday 23/04/2013 at 12:56, Chris Ferebee wrote:
Thanks, Steffen, I guess that might be something to try if we can't get the SurgeMail native SSL setup figured out. It's not clear to me, though, how it would interact with the calendar web interface. OTOH, I'd rather eliminate Apache completely from the mail server, just to keep things simple. Best, Chris Am 23.04.2013 um 12:10 schrieb Steffen <HIDDEN@n@land10.nl>: When you have Apache already running with SSL you can disable HTTPS in surgeweb and use ReverseProxy. For example: ProxyPass /surgeweb http://127.0.0.1:7080/surgeweb ProxyPassReverse /surgeweb http://127.0.0.1:7080/surgeweb ProxyPass /cgi http://127.0.0.1:7080/cgi ProxyPassReverse /cgi http://127.0.0.1:7080/cgi ProxyPass /web http://127.0.0.1:7080/web ProxyPassReverse /web http://127.0.0.1:7080/web ProxyPass /cm http://127.0.0.1:7080/cm ProxyPassReverse /cm http://127.0.0.1:7080/cm For Surge web management you you can use above, but with port 7026 Steffen http://www.apachelounge.com/ On Tuesday 23/04/2013 at 11:45, Chris Ferebee wrote: Hi Marijn, https_required is enabled. Specifically, in /usr/local/surgemail/surgeweb/custom/config_global.dat I have https_required true as set through the SurgeWeb Customisation page ("Editing global customisation"). g_ssl_require_web is also set via the Security web page. I have restarted SurgeMail after Perhaps I should mention that I have Apache running on port 80 on the SurgeMail server. Its only purpose is to redirect most URLs to the webmail login page on port 443 and another URL to the management web interface on port 7025. SurgeMail is listening on port 443 for webmail as well as other ports such as 7995. What else can I check? Thanks, Chris Am 23.04.2013 um 10:47 schrieb Surgemail Support (Marijn) <surgemailHIDDEN@t@netwinsite.com>: I just ran some tests, and yes there is definitely some slightly odd interaction going on between the various ways of enforcing ssl and surgeweb calendaring. You actually do not need to put any port numbers in g_url_alias, but doing so does change the behaviour / reported errors as you have found. There is a surgeweb level setting to enforce ssl on surgeweb web requests: https_required true If this is set surgeweb will detect the need for ssl and connect to caldav / user.cgi etc using ssl. This can be set on surgeweb customisation page or any of the surgeweb config_*.dat files. As it stands if this is not set and just g_ssl_require_web is used then surgeweb tries to connect to caldav on the non ssl port and it fails with a variety of ssl related and seemingly unrelated error messages. If you use just https_required and do not use g_ssl_require_web at the surgeweb level any incoming requests on the http port will be automatically redirected to the https port. This configuration would mean that you do not have strict ssl enforcement on the other surgemail web interfaces. Anyway, let me know if the addition of "https_required true" does the trick in solving your calendaring issues. Marijn On Tuesday 23/04/2013 at 8:14 am, surgemailHIDDEN@etwinsite.com wrote: I've gotten past the first error message now (550 Secure https: link required for webmail) when trying to access the CalDAV calendars in SurgeWeb. Previously, the "Ports" field was empty for all the alias entries on the g_url_alias page. I never thought to change that, as SurgeWeb webmail has been working fine AFAICS. I changed various settings, but it was after I put "443" (my secure SurgeWeb port) in all of the fields that the original error (Secure https: link required) went away. Now I get a different error when I click on the "Calendar" link in the left column in SurgeWeb, or the "Configure" button in the left Calendar pane: Cal Request Failed: Error downloading /usr/local/surgemail/surgeweb/work/ferebee.net/c/f/cf/tmp_xxx_xxxxxxxxx_20270873 0/4096 (1) Again, the right pane shows "CalDAV calendars" and an empty list of "Your Calendars" and "Shared Calendars". My primary need at this point is to be able to configure the sharing. Best, Chris Ferebee Am 22.04.2013 um 15:58 schrieb Chris Ferebee <HIDDEN@ebee.net>: I'm trying to set up CalDAV for Mac and iOS users on SurgeMail 6.3d72. To grant shared access to calendars, I understand that we need to use the Calendars pane in SurgeWeb. However, it doesn't display any calendars. Instead, it shows the error message Cal Request Failed: 550 Secure https: link required for webmail - change http to https in url This is undoubtedly caused by the fact that I have set up my server to redirect all HTTP requests to the webserver domain to the HTTPS login page. Calendar sync for a single user between OS X 10.8.3 and iOS 6.1.3 seems to work fine with automatic setup. Access to webmail also works as expected. Where can I change the URL for calendar access from SurgeWeb, as suggested in the error message?
|