A
@jdaviescoates said in Who is selling hosted (and supported) Cloudron servers?:
https://autonomic.zone/ were offering it too, but I'm not sure they do anymore now that Cloudron is no longer open source.
They indeed stopped doing it when Cloudron changed the license.
At Catalyst Collective we provide some hosting services to several organisations using Cloudron but we don't advertise it at all or have the capacity to develop it as a proper business stream (I'm the only one doing it and already have too many other work streams). I'd love to see a UK offering and I'd be happy to help setting it up.
I've also tried to create a mailbox (test@mydomain.coop) and set-up a redirect with roundcube to three "external" email addressed (@gmail / @posteo), delivery fails with all of them. So it is not specifically with Cloudron mailing lists but a bigger issue with redirects in general. @staff any clues?
To add to this, I've tested it sending only to internal users, with then a subsequent forward with a sieve filter to the @gmail/@posteo adresses, it also fails.
It feels this makes Cloudron mailing lists unusable with external SMTP.
@mirotalk-57bab571 What @robi is talking about is a conflict when you have a OIDC user with the same username as a user in the .env file. In this case the user in the .env file (same username as the OIDC user but different password) cannot join the room.
@girish Hi Girish, I see the issue you mean (I also reported it a while ago, it was about double forward) but this one is different (although the cause might be same). Before switching to the external SMTP the mailing list was working fine for this use case, it's only after switching that it started happening.
While the other issue was a bit niche, this issue / use case seems more critical as it affects the basic functioning of mailing lists when using an external smtp.
@james sure it's catalystcollective.org
For clarity, sending/receiving emails works fine, it's only when someone with an external email address (i.e. not from this domain) sends an email through a cloudron list that delivery fails for recipients (list members) who also have external addresses.
Addition email server logs:
When sending from @mydomain.coop with successful delivery:
{
"ts": 1751965332978,
"type": "delivered",
"direction": "outbound",
"uuid": "425FB09B-28B2-4DFD-B19D-24763E77D8A5.1.1",
"messageId": "<bc8821b5-e1c3-422c-bce0-3be7ae6b974b@mydomain.coop>",
"mailFrom": "<someone@mydomain.coop>",
"spamStatus": null,
"mailbox": null,
"quotaPercent": null,
"rcptTo": [
"<some.person@gmail.com>"
],
"server": {
"host": "149.28.215.223",
"ip": "149.28.215.223",
"port": 587
},
"response": "OK: message queued"
}
When sending from an external address to the same list and failing on the same recipient:
{
"ts": 1751964710037,
"type": "bounce",
"direction": "outbound",
"uuid": "4C06313B-F1B3-460A-AC38-59402F3C3ACE.1.1",
"messageId": "<76622dc4-1d22-4fe3-a863-e5da6a39a0b8@posteo.net>",
"mailFrom": "<someone@posteo.net>",
"spamStatus": null,
"mailbox": null,
"quotaPercent": null,
"rcptTo": [
"<some.person@gmail.com>"
],
"message": "550 From header must end with @mydomain.coop",
"mx": {
"exchange": "149.28.215.223",
"priority": 0,
"port": 587,
"auth_user": "*@mydomain.coop",
"auth_pass": "c3b478557ae86e1b599aba64",
"auth_type": "plain",
"bind_helo": "my.domain.coop",
"from_dns": "smtp.forwardemail.net"
}
}
Hello all,
I've recently set-up an external SMTP relay using forwardemail. It works well, emails are going through etc.
However I have encountered a problem using Cloudron mailing lists:
When sending an email from en external email address (e.g. @posteo.net) to a Cloudron list which contains addresses @mydomain.coop (the domain on Cloudron) and some other adresses, e.g. @gmail.com or @posteo.net I am getting bounces for all recipients with those external addresses. Delivery works fine for the recipients @mydomain.coop and all works fine to ALL recipients (no bounces) if the sender is an address @mydomain.coop.
Bounces look like:
Hi. This is the Mailer program at mydomain.coop.
I'm afraid I wasn't able to deliver your message
"test email"
to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
Intended Recipients: <some.person@gmail.com>
Failure Reason: Error: 550 From header must end with @mydomain.coop
@nebulon wonderful, thank you for the clarification!
@nebulon Thanks for your response. I had read the documentation before. As far as I understand setting up the external SMTP server means that cloudron uses this (in the exemple smtp.forwardemail.net) to send emails instead of the internal SMTP server (my.domain.coop).
Before I setup the external server, my desktop clients were configured to send emails using my.domain.coop + my cloudron credentials for that particular mailbox.
Now it works either using:
My question is:
If I keep using the same config as before for sending emails from my client, i.e. my.domain.coop + cloudron credentials, does Cloudron still somehow pass that on to the external SMTP server, or is it sent by cloudron internal smtp server?
Or am I missing something?
Sorry for the probably stupid question but I've just set-up an external smtp server on Cloudron and I am puzzled by the SMTP config for email clients.
In my desktop email clients I can now send email using the smtp configs provided by the external service (Forwardemail), but it still also works using the old Cloudron config (i.e. using my.domain.coop + my Cloudron users credentials).
Does this mean that even when configuring Cloudron to use an external SMTP server for outbound email, the internal Cloudron smtp server still works and can still be used? Or is it the case that using the Cloudron smtp config still works but the email is somehow still routed through the external service?
@james said in Host Users not defined in env:
If so, OIDC will always be used even with that configuration.
I'm not sure this is correct.
You can disable IODC in the env config file: OIDC_ENABLED=false
Then "I guess" you can use the host user config.
@d19dotca said in issue with email delivery going through Cloudron mailing lists.:
I think they were using the workaround of creating a mailbox and logging into roundcube to setup mail forwarding, so it kind of acts like the Cloudron mailing list in a way, but seems to be more reliable and doesn’t trigger Gmail’s “mass mail” protections.
That's correct and also started using Lismonk for larger distribution lists.
I can't tell as I stopped using Cloudron mailing list a while ago because of this. But clearly others (e.g. @d19dotca) seem to still have the problem so looks like it hasn't been solved.
@MiroTalk said in reconnecting to the meeting randomly:
If you experience any disconnections, please let me know. It would be helpful if you could provide a screenshot of what you see on the device when it happens, and let me know whether you're reconnected to the room immediately or what exactly occurs.
Hello @mirotalk-57bab571 . So things are different since the updated version. In my first first meeting I had no disconnections so I had great hopes...which sadly got crushed in my second meeting where I had several disconnections. The behavior when the disconnections occur has changed.
Before, when the connection would drop, this message would appear briefly Lost Connection (Transport Closed), then the page would reload automatically immediately and I would get reconnected to the meeting with both camera and mic off. When turning on my camera back on, the background settings would be lost (say if I have blur before, then on reconnection I would have a clear background).
Since the new package, when the connection drops I see this (slightly different message):
...and that page lasts a bit longer before refreshing and reconnecting (on a couple of occasion I saw a count down appearing on the massage). Then it sometimes takes a couple of refresh before I actually get reconnected properly.
On one occasion I could not reconnect and the app itself became unresponsive. It was show as running on the Cloudron dashboard, when when clicking on it I had the Cloudron error page saying the app was unresponsive. I had to restart the app from the app settings on Cloudron.
On another occasion, right at the start when joining a meeting, I got disconnected right away and on reconnection my external webcam was not recognised anymore and I had to use my laptop one. This had never happened before.
So while clearly something has changed in the way connections are handled, currently the situation/UX has become, I'm afraid, a little worse, but I do not loose hope that this is just a sign of work having started to take place and it'll only get better from here to reach perfection 
.
Running MiroTalk 1.8.66 btw.
@MiroTalk Thank you, great to hear! I will report if I experience any more disconnections and will provide the info you've requested.
@overholt said in Nextcloud OIDC integration:
LDAP the default authentication protocol used when installing NextCloud on Cloudron and selecting "let application manage users?"
Just emphasis @james's point, when you select "let application manage users", then you're not using LDAP at all, you're using Nextcloud internal user registration which is not affected whatsoever by the migration from LDAP to OIDC.
@overholt said in Nextcloud OIDC integration:
My worry is having to manually reconfigure shares, etc inside NextCloud for users.
Even if you were using LDAP, the transition to OIDC only affects the login process (for NC itself and all external apps) but not anything internal like folder shares, groups, circles, etc.
@MiroTalk said in reconnecting to the meeting randomly:
Work in progress...
Really great to hear. And again thanks for all the work. Keep us updated if you can as for me it has become impossible to keep using it for work but I'm happy to do some testing whenever changes are being implemented.
@mirotalk-57bab571 I've been able to capture connection quality issues as I got disconnections on MiroTalk using https://test.vsee.com/network/index.html. The two drop in connections quality coincided with the disconnections/reconnections events in MiroTalk, which somewhat explain why those events happen randomly and support the idea it has to do with the quality / reliability of my connection (see below).
But there is something about MiroTalk that makes it particularly sensitive to it as does not happen with any other apps.
