"Feature Requests" has a new home

Join the Axigen Product Community!

Influence Axigen's future product evolution – vote on existing feature requests or create your own.

Join our product community
See more
See less

Webmail should support https:<mydomain>/<mail>

  • Filter
  • Time
  • Show
Clear All
new posts

    Webmail should support https:<mydomain>/<mail>


    As part of my family website (but at is not at all different for commercial websites), I would like to have a secure mail page.

    Really strange enough that is not possible with the actual Axigen version.

    Axigen assumes it owns the domain for it self (then mail page equals the domain name), where it should own IMHO only a certain part of the domain e.g. <mydomain>/mail

    So for example that option would allow a website setup like



    I desperately need this option, since the only alternative would be a second domain, second pair of certificates and all not integrated.

    I would really appreciate this small but very important change.




    Please have a look at our online documentation listed below in order to define ssl settings:



      SSL is not the problem


      Perhaps I do not understand your hint, but SSL is not the problem. Note that:
      1) I can setup an axigen SSL site as long as the whole domain is dedicated to axigen
      2) I think I can also setup an Axigen SSL-site again as long as the whole domain is dedicated to axigen, ending the SSL on the apache server and forwarding every thing to
      3) I can use axigen aside from apache as long as I use some IP-poort not 80 / 443

      4) but what I can't and that is what I need is access my domain by https and partly use that for my website and partly use it for my mail !!!!!!!

      The problem is quite simple axigen has the stupid Idee it owns the domain. Not true apache / the site owns the domain and the mail page is part of it.

      So, that is my problem,



        The excellent answer



          Currently the webmail url does not support paths, as you have noticed. A feature request was already submitted in this regard, but at this time an implementation date is not set, unfortunately.



            Too Bad! 811 did not fix this problem!


            I really pleased to see that Axigen is supporting and updating the mail server.

            But it really is a pity this issue IHMO easy to fix for the developer and impossible to work around for a user has not been included.

            The only way I know to create a workable webserver is to claim another domain and another set of certificates next to my normal website. That's is a major action and a very strange one as well.

            I really, really hope that this feature (I hardly regard this as a feature, IMHO it is a must), will be included.

            Still not know what to do in the mean time.





              Unfortunately this functionality is not included in the current version. Regarding strictly the SSL certificates, wildcard certificates along with a subdomain may be an option although they may pose other inconveniences.



                Please make sure that this is fixed in Q4-release


                Could you please, please take care that this IHMO important issue will be fixed with the Q4-release.

                I really think that this technically small issue does bloc, all the webmail capability



                  Please know that at this moment we cannot tell you with exactitude what version of Axigen will contain this feature.



                    i think you can achieve this with apache's mod_proxy


                      This vital option still missing, I think


                      I was very glad to see that a new axigen release is available. I installed it and tried again to make my (secure)webmail working.

                      No way I think. Axigen is still asuming it owns the site, which is definitly not true.

                      The mail is just one of the functions the site offers. So webmail is / should have a base address like:
                      <mydomain>/<webmail> and definitly not <mydomain> !!

                      So unless I register a second domain and buy a second certificate I can not use the webmail.
                      And even then it will not be integrated part of my website

                      So, I really do not understand that the axigen still does not offer a <mydomain>/<webmail> under Axigen/webadmin/manage domains




                        Found a workarround / Bypassing the problem


                        As described long ago, IMHO the mail server GUI should be part of your normal website. And accessible via HTTP or as I prefer HTTPS.

                        That should (If you want so) be the case for both webmail and webadmin.

                        You also have to integrate it in the webserver in order to make the mail server gui remotely accessible via the normal http and https ports.

                        The workaround I am using now is based on the fact that Axigen allows you to use subdomains as aliases for your realdomain.

                        So suppose following:
                        - your mail addresses are like <username>@<mydomain>.<com>
                        - the domain is <mydomain>.<com> and the alias could be mail.<mydomain>.<com> and another alias could be mailadmin.<mydomain>.<com>

                        So given that possibility the next trick is assign those (sub)domains to different webservers. That can be done after assigning multiple IP's to your computer Ethernet port (NIC). So what you could do is
                        - IP-1:443 and or 80 is assigned to the normal apache server
                        - IP-2:443 is assigned to axigen webmail listener
                        - IP-3:443 is assigned to axigen mailadmin listener
                        So now you have to configure your DNS zone file to match this assignment

                        So you have some further issues to tackle:
                        - make redirects from within the apache vhost towards the new subdomains
                        eg www,mydomain,com/mail redirects to https:www,mail, etc.
                        - each domain needs its own certificate since the domain is different unless you are using an expensive wildcard certificate
                        - you do need to run your own DNS server
                        - you can only locally assign the multiple IP's to the NIC. You can not assign the NIC's mac to multiple IP in your DHCP server as far as I know. And probably the OS needs to be aware of the multiple IP's as well

                        Yeh ..... it is complicated and less elegant that I would prefer, but it works and for your user it will probably look more or less the way they expect it.

                        Hope this helps :>




                          Hello Louis,

                          The requested feature is still in the development backlog as it is not a simple task as it looks from outside.

                          Glad to know that you have find a workaround and post it here. I think that it will still work if you will not define the mentioned domain aliases into Axigen. Could you confirm?



                            Yep No Domain Alias needed, however big proxy problems


                            That is correct. It also works without alias.

                            However I do not yet have the webmail accessible from the internet because I am facing another problem. Being a interworking problem between the ssl proxy and the axigen server.

                            At the internet side I have one IP mapping on multiple domains, multiple virtual hosts at the inside network among them my domain and my mail domain.

                            To distinguish the servers, I am using SNI. Actual situation is:
                            - when accessing axigen without proxy. It works OK
                            - but with the proxy, I did not jet manage to get it working
                            All kind of strange effects perhaps related to cookies, encoding or compressing do not yet know but in the end ..... it does not work (different browsers IE / firefox / chrome) also react different but far from OK

                            So still investigating ....



                              Thinking about &quot;Not working but why?&quot;


                              Despite experimenting a lot, I do not yet manage to access the webmail in a working way, especially not if the webmail is behind a reverse proxy.

                              Lets do some thinking about why

                              To start with the server should support:
                              - the normal mail handling related to <myname>@<mydomain> using ssl certificate <mydomain> and in parallel
                              - it should support webmail via the workaround www.mail.<mydomail> using ssl workaround certificate<mail.mydomain>

                              So now it becomes interesting. What is / should determine which domain the webmail server use ......... It is clear of cause, it should use <mail.mydomain>

                              But I did not identify the configuration item within Axigen config which determine that! (not in the gui and not in the config)
                              So I assume it using the primary domain name which is of course <mydomain>

                              As a consequence
                              - I am accessing as webmail site via www.mal.<mydomain>
                              - where the site it self assuming it is serving www.<mydomain>

                              So locally on my network some browser types seems to accept that, but the reverse proxy is becoming crazy

                              Other issues which *seems* to spoil the party are:
                              - compressing (it might be ... that the proxy assumes compression is supported where that might in fact not be the case ...)
                              - the webmail site is advanced, and might be building urls and content dynamically, potentially conflicting with the reverse proxy cache. Especially in conjunction with the real problem, being the wrong site URL

                              What ever, not yet solved, and potentially not solvable at all


                              So the domain alias does have some role, but it is not as usable as I originally expected.



                              This is the legacy Axigen forum, which is no longer active.

                              To create new topics & posts, please visit the new Axigen community.

                              Axigen Community