Cloudron Forum

@humptydumpty Some of the apps in the wishlist are not trivial. For example, Zulip competes with Slack and I would consider that "Enterprise grade". If we could get an app like that professionally packaged and maintained, I would be willing to pay my fair share of 5K or 10K. I have only packaged a PHP app for fun and have no idea how many hours are required to do a serious app with database, Redis, etc. And parsing someone else's codebase is never easy.

What I think could also be helpful (suggested feature) is a separate "membership" called sponsor's club. It would require a small annual fee allowing even non-business Cloudron subscribers to benefit. Sponsor club members would get access to any "sponsored" app that others paid for via the 5K or 10K route. I don't know how many Cloudron subscribers there are, but even 50 per person/year adds up. It might even pay to package one or two commercial apps (or pay for a percentage of the 5K or 10K required).

@nebulon . Agreed. Also, additional cost for extended retention of logs (up to 1 year) is reasonable.

@girish I received an email. I believe the new pricing is on their website.

@ girish This is a great conversation. Do you think it would be practical to have a process where an initial "Sponsor" proposes a package. Cloudron looks at the app and decides 5K or 10K (small or large effort). Looking at some of the levels of interest on various apps (30/40/50 votes), perhaps a financial commitment of 0.5K would be required. On a small app 10 participants would meet the threshold. On a large app, 20 participants. Once the threshold is reached, the project would start, and the first step is getting everyone to pay. When the 5K or 10K has been collected, the packaging can begin. It's almost like a private Kickstarter only for Cloudron. In fact, if the fees aren't too high(think this is around 10% all-in), we might be able to use that platform since money is not charged until the threshold 5K or 10K is reached. It also has the benefit of spreading the Cloudron name all over Kickstarter. Thoughts?

@p44 And your point about the quality is really important. Their delivery information has helped me win many arguments about "never receiving your email". Now I can prove that it was delivered to your inbox provider, and if lucky, even if when the recipient opens it.

I have been a big proponent of Postmark as a transactional and marketing email service for Cloudronites (we are using Postmark to send 100% of outbound emails from our Cloudron email accounts). A recent communication about pricing changes caused a lot of stress, including big delays in receiving a response from customer service. But in the end, they did the right thing by a long-term customer and as a result, they will continue to remain a valued vendor for the foreseeable future.

If you need to contact support, please be aware that they are overwhelmed with tickets and doing their best to respond. They are usually very responsive and this is not a normal situation. I decided to post this so that other existing customers are aware of what is going on and prevent others from jumping to the wrong conclusion about a trusted vendor.

@luckow It is looking good! I wish I could help. It's been so many years with my beard that I can't remember if I experienced the itching at all when it was "sprouting". But since AI is wiser than me, beard oild seems to be the suggested remedy. Here are some suggestions available in the EU: https://www.perplexity.ai/search/what-are-the-best-beard-oils-a-WZ.FkWizSP2BpCNmbVoi1Q

@girish Seems I am the only lucky one here. Some more troubleshooting info: Enabling inbound on a new email domain seems to trigger the issue. I add a new domain, configured the DNS API keys and saw that new initial DNS records were created properly at my domain registrar. Next I switched from the default Cloudron SMTP server to Postmark, entering a token for the new "Postmark server". At this point all was OK. Outbound status showed "green". When I enabled inbound email on the domain, the MX record status shows "red" (expected while creating and propagating). Immediately I began receiving iOS error messages. I checked my domain registrar's portal and saw that the new MX record had been created, and shortly thereafter, the MX and DMARC status in Cloudron changed to "green". At that point, by "cancelling" each iOS error message, I was able to receive emails for that account (I have multiple). Error messages continued. It seems that the only way to end this string of error messages is to close the iOS mail app and reopen it. These errors appeared for multiple connected users running both iOS 17.7.1 and 18.2.1. I wonder if Cloudron (or SoGo EAS) is rejecting all connections from iOS until the mail configuration (addition of a new domain) is complete. Does the mail server restart to "enable" the new domain? More and more I am feeling like this is the root cause and also that there is nothing we can do to eliminate this annoying behavior.

@girish So I added another domain/email domain to my Cloudron over the weekend and again that triggered the iOS warning: "Cannot Verify Server Identity" The identity of <my mail domain> can not be verified. In viewing the details, the underlying certificate shows as "Not Trusted". Certificate was generated on 14Dec2024 and the domain was added on 18Jan2025. The certificate does not expire until 27Feb2027! Is the old certificate being deprecated by Cloudron before the new certificate is valid? My mail client is only trying to access existing mail domains, not the new domain.

I agree about using an external SMTP relay. In my case, Postmark has been flawless. Because they separate marketing from transactional messages, their deliverability seems better than their competition. I also set up a sub-account (in Postmark jargon, it's called a Server). By doing that, each domain's reputation is isolated. If someone behaves badly, it is easy to delete their server keeping the rest of your infrastructure intact. By adding a "domain-based" Sender Signature with DKIM and Return-Path, any email sender from that domain is permitted. It works really well!

@fbartels Much appreciated. After your explanation (and watching what is going on with SoGo workers and how many workers are needed), my next Cloudron will not use SoGo EAS simply because it consumes too many resources. For a limited set of users (< 30), I can afford the extra resources. But if I was providing email for 200+ users, I think Sogo EAS would crash and burn.

I also hadn't thought about the consequences of having 5 email accounts on 3 different devices. While all of them may not be "active" at the same time, the load is much greater than the number of email accounts.

@girish Now that you mention the Thunderbird calendar password issue, I experienced that once as well. I assume that in the migration to Cloudron/SoGo I had missed something, but seems not in this case. I am thinking there will be more of these messages in my future...

Also, I was also shocked about how resource intensive EAS is. When I realized how many workers were "needed" from viewing the Sogo log and doing some simple math: (# users) x (# mailboxes/user) x (# devices) with those mail accounts, I think I wound up with 150 workers to achieve the right balance of responsiveness. Fortunately I am running this on a server with big CPU and RAM. 1 user with 8 mailboxes on 3 devices (desktop, tablet, phone) could trigger 24 simultaneously requests! @fbartels Any advice based on your Kopano knowledge with EAS?

@ girish On the Solr question, thank you. If that is the case, then I am amazed at how quickly the indexing happened. On that server, I believe there are 200,000+ email messages. Of course 4 lightly-loaded AMD processors available to crunch helps:)

@girish I tried restarting the mail server twice. I did not see the strange iOS messages either time. In checking with 2 other users, they did not see the messages either. It could be also that SoGo is "sleeping" (this seems part of the EAS mechanism) at the moment I restarted the server. If the clients were told "don't bother me for 30 seconds" then perhaps they are not requesting anything during the timeout period.

BTW, this is not just a Cloudron/SoGo issue. I have seen this behavior on iOS whenever there is some connection issue between the device and the mail server. In some cases switching from cell to WiFi or vice versa can eliminate the issue. But if the server is at fault, nothing helps (obviously).

Two questions:

(1) So I enabled Solr on one of my Cloudrons and I was curious if there is any way to see if the initial indexing has completed? The Full Text Search field shows a status of Enabled/Running. After enabling Solr, I can see a small, "permanent" increase in RAM usage (this makes sense) and the email searching from the client side is very responsive. The mail service and SoGo have limits of 4GB with more RAM on the server, so there seems to be plenty of headspace for Solr. How can I know when the process is complete or run a command to verify?

(2) So on another server, I periodically need to add another mail domain. Domains could be added either with a supported DNS Provider or in other cases I need to select Manual. After adding the domain, it looks like the Let's Encrypt certificate needs to be regenerated to include the new domain. When that happens, my iOS users on other domains experience an invalid password window, prompting the user to enter the proper password or cancel. iOS is not discriminating on these errors, so even a networking error between the user and the server or an invalid SSL certificate triggers this unhelpful message. Besides the facat that it keeps popping up relentlessly, it often encourages users to enter a password thinking this will fix the problem (it won't) and they enter the wrong password by mistake - breaking their email installation. Is there any way in Cloudron to keep the old certificate in place until a new one can replace it? If there is another way to prevent current email users from receiving that ridiculous iOS message I am open to any idea.

Thanks. Any advice on either is appreciated...

Brad

@joseph Completed the migration to the new server, but I ran into several errors restoring apps. Roughly 70% of the apps were in an error state, with a message similar to this one for Listmonk: Docker Error: Unable to pull image cloudron/app.listmonk.cloudronapp:202411131609490000. Please check the network or if the image needs authentication. statusCode: 500

The event log shows a successful attempt to restore again: App was restored from version 1.9.0 to version 1.9.0 using backup at 2024-12-14-150347-189/app_

but multiple attempts at this have failed. In all but two apps (Listmonk and Mail), retrying (with an occasional app restart) has gotten this to work for each app. Services have plenty of resources. The server is large. I am unable to try Recovery Mode for this app as the error state locks me out of that option (and the restarting option as well). (Rebooted the server. Mail restored next time, but ListMonk took ~ 2 more times to work)

Two One questions:

(1) How can I resolve this?

(2) - Why did this happen in the first place?

I followed the backup, restore, dry run, sync DNS, update certificates process and all seemed to work fine.

@humptydumpty Thanks for saving me some testing time.

What if you configured other domains to send mail via an SMTP service like Postmark? Probably the server IP address would leak, but perhaps not the domain.

@nebulon Could the groups ACL currently built into Cloudron be extended into SoGo calendar? It is possible to limit apps to certain groups. Can multiple Sogo instances be added so that Group X has access to its own Sogo and Group Y has access to its own Sogo and the address book while global is confined to just the group?

@humptydumpty Nothing more difficult than getting family to accept your help and acknowledge that perhaps you know something that they don't:) To your point, perhaps during signup a warning about mail delivery to these inbox providers and a suggestion to use another email address. Caveat emptor.