This appears to be a case of https://forum.cloudron.io/post/6533 . Applying the linked setting change fixed the issue.

Rocketchat group calls are also using Jitsi, so including that would be a big plus for us.

For some of our users, their SMTP connections are being denied, with:

902 Host names have more than one DNS label

This error appears to come from https://codeclimate.com/github/msimerson/Haraka/plugins/helo.checks.js/source

I don't know how to walk them through finding out what HELO their device is sending to validate it, but it seems related to the plugin.cfg.reject.valid_hostname setting. Did this change in 5.0.3 ?

This appears to be a case of https://forum.cloudron.io/post/6533 . Applying the linked setting change fixed the issue.

For some of our users, their SMTP connections are being denied, with:

902 Host names have more than one DNS label

This error appears to come from https://codeclimate.com/github/msimerson/Haraka/plugins/helo.checks.js/source

I don't know how to walk them through finding out what HELO their device is sending to validate it, but it seems related to the plugin.cfg.reject.valid_hostname setting. Did this change in 5.0.3 ?

@girish As far as I know, it's correct - unless DKIM has the IP included, since that did change during the migration. Unfortunately, the Email section of Cloudron wasn't properly giving the needed information - previously it was saying DKIM was incorrect, but the display just said something like "expected null to equal null". DKIM isn't showing in the Email status page at all with the workaround I added here.

I'll put that in as a separate issue, though, once the update comes out and I see the proper message.

Last night our Cloudron updated to 4.4.0, and got stuck in a restart loop.
The error in box.log was:

/home/yellowtent/box/src/mail.js:524
                    if (!record.status) message.push(`${type.toUpperCase()} DNS record (${record.type}) did not match.\n    * Hostname: \`${record.name}\`\n
   * Expected: \`${record.expected}\`\n    * Actual: \`${record.value}\``);
                                ^

TypeError: Cannot read property 'status' of undefined
    at Object.keys.forEach (/home/yellowtent/box/src/mail.js:524:33)
    at Array.forEach (<anonymous>)
    at /home/yellowtent/box/src/mail.js:522:41
    at /home/yellowtent/box/src/mail.js:503:13
    at /home/yellowtent/box/node_modules/async/dist/async.js:3888:9
    at /home/yellowtent/box/node_modules/async/dist/async.js:473:16
    at iteratorCallback (/home/yellowtent/box/node_modules/async/dist/async.js:1064:13)
    at /home/yellowtent/box/node_modules/async/dist/async.js:969:16
    at /home/yellowtent/box/node_modules/async/dist/async.js:3885:13
    at /home/yellowtent/box/src/mail.js:471:17

I patched around this by editing that file and adding a

if (!record) return;

into the forEach callback.

We've been having issues with Cloudron not correctly reading the mail config (reporting DNS misconfiguration, with error messages about expecting null to equal null), since we migrated to a new host a few weeks ago. This may be related, but I haven't had time to report the issues that happening in that migration yet.

Rocketchat group calls are also using Jitsi, so including that would be a big plus for us.

We are attempting to use a wildcard cert for one of our domains.

I attempted using the key and cert as provided (no ca chain), which the UI accepted, but then on restart, all subdomains were using self-signed certs.

After working around HSTS, I was able to get back into the system and switch back to Lets Encrypt.

Next, I tried including the ca bundle in the cert file. When I did it the wrong way around (ca certs before the wildcard cert), the UI reported an error. When done the other way (as per NGINX documentation), the UI accepted the cert. However, all subdomains were using a self-signed cert again.

The renewcerts log showed an error along the lines of "null certificate, falling back to self-signed". Unfortunately, I didn't capture the logs at the time, and the available history doesn't go back that far.

I've tried various certificate inspection tools, that have reported the certificate as valid. This is the same provider we use for providing wildcard certs for non-Cloudron domains, that we SSL-terminate with NGINX, which is why I thought to try the ca-bundle inclusion.

Can anyone provide any insight into why this would have failed in this manner?

We have a SoGo setup from before Cloudron supported multiple domains, and SMTP supported authenticating with just the account name.

Since the full email address is now a requirement, SoGo has been failing to send emails.

I fixed/worked around this by adding the following setting to the /app/data/sogo.conf file (instead of migrating all the data to a new SoGo instance).

SOGoForceExternalLoginWithEmail = YES;

Thought I'd share this in case anyone else runs into the same issue.