0.0.11 -> 0.0.13 -- webmail no longer works

[ally9335]

I run this:

MOXDIR=/home/aaa/mox_email
MOXBACKUPDIR=${MOXDIR}/data/tmp/backup
rm -rf ${MOXBACKUPDIR}/**
/home/aaa/mox_email/mox backup ${MOXBACKUPDIR}/data
/home/aaa/mox_email/mox verifydata ${MOXBACKUPDIR}/data
cp -rp ${MOXDIR}/config/ ${MOXBACKUPDIR}/config

Then I downloaded the source code, compiled it and replaced the executable, only it (!), with the freshly compiled one. Restarted mox and nginx.

And I open webmail at my_email.m_domain.com and it returns "404 not found". Restarted nginx, mox -- to no avail.
No errors in the logs of mox.
IMAP, on desktop, did work properly. And webmail via port redirection too:

ssh -L <.....>

Then I restore the original executable, 0.0.11 and it, webmail, at my_email.m_domain.com has begun to work again.

What's the matter?

[mjl-]

The v0.0.12 release has some changes around serving the webmail/account/admin interfaces. See https://github.com/mjl-/mox/releases/tag/v0.0.12 and in particular this commit message that explains it in more detail: 614576e.

It sounds like you could be helped by setting my_email.m_domain.com as the "client settings domain" for your domain m_domain.com (and similar if you have more domains). That should make the webmail available again.

You can also add additional webserver routes/handlers for the internal servers, to make them available at more domains/paths.

Hope this helps.

[ally9335]

I see, yes.

Since the format of the config has been changed, how's one supposed to upgrade mox properly? An executable is upgraded by compilation and replacement of the original one.

How about mox.conf and domains.conf which are subject to change ocassionally too? Manually? By generating new mox.conf and domains.conf in /tmp, identifying the changes, if any, and then incorporating the changes into the original ones?

[mjl-]

The proper upgrade path is just replacing the binary. The goal is to not make any breaking changes. The release notes normally call out topics that may need your attention in the "Update instructions". I likely thought the change was only fixing something, but it broke your use-case...

I hope you got the web interfaces working again with the latest mox version in the mean time?

[ally9335]

But it's already there and has been:

Although, for the rest of the domains, ClientSettingDomain: is different, as mail.domainN.com for each

But for the main one, the mail.my_main_domain.com, at which webmain is run, is correct. What should get updated then? @mjl-

---

although, I may have found a mistake there

[ally9335]

My main email domain isn't mail.my_main_domain.com but that which is spelled slightly differently, let's say my_super_mail.my_main_domain.com . As you can see, in the domains.conf it's mail.my_main_domain.com

Now it's become to work as I've fixed the spelling.

What are Hostname for client settings? What kind of settings?
Should ClientSettingDomain be updated as well for the the rest of the domains in the file? Or least commented out?

[ally9335]

Is this related?

https://<mail_sub-domain>.my_email.com/admin

===>

403 - forbidden - no session

The same occurs in the incognito mode.

[mjl-]

What are Hostname for client settings? What kind of settings?
Should ClientSettingDomain be updated as well for the the rest of the domains in the file? Or least commented out?

ClientSettingsDomain is the hostname to configure in smtp and imap (and also where the mail & account web interfaces are served). Also see https://www.xmox.nl/config/#cfg-domains-conf-Domains-x-ClientSettingsDomain.

Consider this example setup with multiple domains:

• Hostname: mx.example.org
• Domains: example.org, dom1.example, dom2.example

We could tell users of accounts with an address at example.org, dom1.example, dom2.example to configure their email clients with an SMTP & IMAP server of mx.example.org. But if we want to migrate the domain away to another machine/mail server in the future, that means you would have to tell users to change the SMTP & IMAP servers in their email clients.
Instead, we have the "ClientSettingsDomain", mail.<domain>, which we initialize as a CNAME record to mx.example.org. If an admin wants to migrate the domain to another machine/mailserver in the future, they can do that without requiring changes to client settings. The mail.<domain> CNAME record can be updated to point to another machine as part of the migration, and mail clients will start connecting to the new machine. The mail.<domain> DNS name is also a sensible interface to serve the webmail/webaccount interface. The webmail/webaccount is also served at the hostname, so mx.example.org in this case.

The admin web interface is only served at the server hostname, mx.example.org in this example. Not at all the client setting domains. Only the one admin would need access to the admin interface, and the admin would know to go to mx.example.org/admin/. The error you are seeing 403 - forbidden - no session is because the request is handled by the account (or mail) web interface (because the admin endpoint isn't active on <mail_sub-domain>.my_email.com). If you would first go to https://<mail_sub-domain>.my_email.com/, do a login at the account/mail web interface, and load https://<mail_sub-domain>.my_email.com/admin, you would see a 404 not found: You have a valid session (for the interface), but nothing is served at that location.

Hope this helps.

[ally9335]

I see, thx.

. If you would first go to https://<mail_sub-domain>.my_email.com/, do a login at the account/mail web interface, and load https://<mail_sub-domain>.my_email.com/admin, you would see a 404 not found: You have a valid session (for the interface), but nothing is served at that location.

Yes, 404. Where has /admin gone to? It's on the main, MX, domain.

[mjl-]

The admin web interface is only served at the server hostname, mx.example.org in this example. Not at all the client setting domains.

So it should still be at /admin/ on your mx hostname.

[ally9335]

Nginx as a reverse proxy is how I've used it. And now /admin works, accessible, only when run by ssh -L <....>. Strange

[mjl-]

When using nginx (or any reverse proxy), make sure the hostname is forwarded in the request too. I think I've heard of situations where nginx would just make requests to eg http://127.0.0.1:.../. In that case, mox won't see the original hostname and won't serve the web interface. The http access logging may help diagnose that situation.

For completeness (and assuming you want to enable the admin interface on the public IP), you could check again that you have an AdminHTTP and/or AdminHTTPS section on the "public" Listener with Enabled: true in mox.conf. In the default quickstart config that won't get enabled.

At least, I think from your comment that the admin interface is not yet working as you intend. Or is it already all good?

[ally9335]

Nginx is how I've used it thus far. And it's worked well.