URLs in .well-known responses have incorrect values when Stalwart is behind an Nginx reverse proxy

[afontenot]

This is probably a bug, but since I'm new to working with Stalwart and I'm using it in a configuration other than the recommended one (see below), I'm posting it as a question. We can move this to an issue if need be.

I have the following configuration:

• Stalwart listening on public ports for IMAP, SMTP; HTTP listening only on localhost:8443, and HTTPS is disabled. Sending and receiving mail via SMTP and IMAP have been tested and work as expected.
• My server has a single public IPv4 address. Nginx is listening at this address on ports 80 and 443.
• Nginx has an active server {} block for my mail domain mail.mydomain.tld, and is terminating TLS for the mail domain and reverse proxying the connection to localhost:8443. Port 80 is not proxied to Stalwart. Accessing the Stalwart web interface from the web works great.
• No networks have been marked as "trusted" in my Stalwart configuration, and Nginx has been configured to set the X-Forwarded-For header. Stalwart appears to pick up the forwarded IP correctly although I do also observe the logging issue described here.

JMAP doesn't work. The issue appears to be the following:

"$ curl -s https://mail.maildomain.tld/.well-known/oauth-authorization-server | jq"
{
  "issuer": "http://mail.mydomain.tld:8443",
  "token_endpoint": "http://mail.mydomain.tld:8443/auth/token",
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "device_authorization_endpoint": "http://mail.mydomain.tld:8443/auth/device",
  "response_types_supported": [
    "code",
    "code token"
  ],
  "scopes_supported": [
    "offline_access"
  ],
  "authorization_endpoint": "http://mail.mydomain.tld:8443/authorize/code"
}

As you can see, these URLs have the correct domain and path, but use the internal port and protocol (http) rather than the correct external address outside of the proxy: https://mail.mydomain.tld:443.

I'm guessing (but I have no way to know for sure) that using the proxy protocol would provide Stalwart with the information it needs about the external interface of the reverse proxy, and that's why no one else (I could find) has reported this issue. Maybe, despite the presence of the X-Forwarded-For header, Stalwart is assuming it's not behind a proxy because there are no "trusted" networks. I know similar applications that run behind proxies often provide a configuration option to manually set the public URL of the server, but I didn't see anything like this in the documentation.

Side note: why I'm setting up Stalwart like this

Nginx's support for the proxy protocol is a lot more limited than I initially hoped. Nginx supports multiple server blocks all listening on the same port and selects the correct server blocks automatically (using SNI). It's common to have a bunch of different sites all hosted at the same IP:PORT combination.

Unfortunately, Nginx does not support the proxy protocol in the context of these server blocks, e.g. like proxy_pass, but instead requires you to use it with the stream module, which is far more limited. In particular, it's not possible with the stream module to have multiple virtual hosts on the same port and let Nginx sort out connections with SNI. A server within a stream cannot overlap with the port of any other server - instead you're supposed to use the module exclusively to proxy connections to other servers. There are ugly hacks that work around the issue by proxying Nginx to itself, but that's the only method I've seen.

So I've decided to stick to the approach I'm used to, and handle the TLS and proxy settings in Nginx explicitly. It works great other than the issue I've described here.

[mdecimus]

Have you updated your URL expression?

[afontenot]

Aha, server.http.url = "'https://' + key_get('default', 'hostname')" fixed the issue. Is this the intended way to set the external URL of Stalwart? If so, maybe a note about the importance of setting it should be added to the documentation under the "reverse proxy" section. Do you have to change this setting if you're using the proxy protocol as well?

[afontenot]

Also, while this fixes the specific issue with well-known URLs, it doesn't seem to activate the autodiscover URLs:

"$ curl -s https://autodiscover.mydomain.tld/autodiscover/autodiscover.xml | jq"
{
  "type": "about:blank",
  "status": 404,
  "title": "Not Found",
  "detail": "The requested resource does not exist on this server."
}

It also doesn't generate the DNS records for autodiscover or MTA-STS for me in the Domains configuration.

Edit: in case it's unclear, I'm bringing this issue up here because of the documentation which says

ensure that the server is configured to listen on port 443 and that the necessary DNS records are set up to point to the server's IP address. Once these prerequisites are met, the server will automatically generate the required XML files for Autoconfig and Autodiscover

So I assume the issue is that the server isn't configured to listen on port 443 - and in fact it can't be, since this is a reverse proxy configuration.

[mdecimus]

Is this the intended way to set the external URL of Stalwart?

Yes.

Do you have to change this setting if you're using the proxy protocol as well?

Only if the port differs.

Also, while this fixes the specific issue with well-known URLs, it doesn't seem to activate the autodiscover URLs

The audodiscover endpoint expects a POST request.

[afontenot]

Great! So that's actually another documentation issue, since configuring the server to listen on port 443 is not actually a prerequisite for Stalwart to generate the autoconfig XML files.

I do still see the issue of the DNS records for autoconfig and MTA-STS not being generated for me, however. Obviously I've created them myself at this point so this isn't a major issue.

Thanks for your help! Marking your initial comment as the answer here.

[xenadmin]

Have the mentioned documentation issues here been fixed in the meantime?
And are the DNS records now created correctly, or is this still an open issue?