[Suggestion] [Web forwarding] Limit mox's listener on web path

[TragicLifeHu]

Currently mox's behavior is to listen for all subdomains for /admin/, / (Account page) and /webmail/ (If enabled) web path.

This caused issues when using Web forwarding function. For example, I want to use Roundcube Mail as Webmail client, I setup a docker image and use mox as reverse proxy to serve it.

First, I host the Webmail at webmail.example.com, but any access just results in 404 not found, and when I checked the log, all request is redirected to account panel because the default path is mapped to /. So, I map the account panel path to /account/, this resolved the problem.

But there's still issues. On the subdomain webmail.example.com or default mail domain mail.example.com or just any other subdomains, accessing path like /admin/ will always be redirected to mox's page, not the one belongs to that application. For Roundcube, there's no /admin/ page so it's just fine though.

In my case, I just give up using that server for hosting anything else but the mail server, and cancelled any other subdomain, and map my Roundcube Webmail to mail.example.com, as a root path. This perfectly solved any potential issues.

I suggest only to listen for path like /admin/ within the main mail domain, so the web forwarding won't conflict with other web applications. This will greatly improve mox's usability.

Also, it seems that proxy pass is not fully supported by mox, so PHP FastCGI and some common tools are unable to work. Though this is not the point of this issue, I add it here.

[mjl-]

Hi @TragicLifeHu, thanks for the report, much appreciated.

I suggest only to listen for path like /admin/ within the main mail domain, so the web forwarding won't conflict with other web applications. This will greatly improve mox's usability.

Agreed, the current behaviour isn't great. I currently run these interfaces on my internal listeners, so didn't run into this yet.

A config can have multiple listeners (IPs to enable mox services on). The quickstart makes a "public" and "internal" listener. The internal listener sets "localhost" as its domain name by default. The public listener doesn't set one and inherits the globally configured hostname (of the host itself). Configured domains now also get a "client settings domain", default to mail.<domain>. Used for IMAP/SMTP settings, but also useful for the webaccount/webmail interfaces. Mox could serve the admin interface only on its listener domain name, and the webaccount/webmail interfaces on its listener domain name and on all "client settings domains". And we could allow configuring additional domains to serve these services on, in the listener. And we would serve the web interfaces if the http request doesn't have a hostname. This should keep behaviour mostly the same.

We could make this new behaviour opt-in (for existing configurations, for which we don't want to break existing behaviour), and change quickstart to use it for new configurations. It could be a boolean field in the listener. But if we can avoid introducing a new field, that would be better. I can imagine some reverse proxy setups, that forward requests for hostnames mox doesn't know about, would stop working.

Another option: Evaluate the webserver routes before the routes of the mox webservices. Then your own configured routes take precedence. Presumably you would only configure additional domains if you're going to serve something and add routes, and you'll probably often match all paths within the domain in the routes. But it's probably unwanted that an admin/webmail interface can unexpectedly popup on /admin/ or /webmail/.

It's not currently possible to create a webserver route that passes requests to the admin/account/webmail services. So if you would configure a route for path /, you wouldn't (easily) be able to also service the admin/account/webmail interface on that domain with changed evaluation order. Unless we add config options to the webserver routes to send requests to these services...

Also, it seems that proxy pass is not fully supported by mox, so PHP FastCGI and some common tools are unable to work. Though this is not the point of this issue, I add it here.

Mox doesn't implement fastcgi for forwarding at the moment, only HTTP. It could be a new feature. I haven't needed it yet, the webapps I write are usually written in Go and they have their own webserver to forward to. If something isn't working with HTTP forwarding, that would be good to investigate.

[mjl-]

@TragicLifeHu i think the situation is improved with the commit just now. the commit message has all the details. if you're able to give this a test drive, that would be nice. see https://www.xmox.nl/b/#614576e409a6e2f115bc6c11bd03a50b9b45ddec for a binary.

i had to make a config change to mox.conf: i normally access my webmail through an internal domain name. i had to change the Hostname in the "internal" listener in mox.conf from the default "localhost" (as generated by quickstart) to my internal domain name. otherwise the webmail interface wouldn't be served anymore.