Cloudron Forum

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.

@nebulon Thank you for the explanation. Is there any way to implement a "company directory" by domain as opposed to a "Cloudron directory"? Clearly this method would not work since all CLoudron users would be exposed and their calendar availability as well(:

@guyds Thank you for posting your test results. I am wondering if email addresses from certain domains should be "blocked" by software developers for account registration. If a user tried to sign up using {hotmail, live, outlook, Yahoo? AOL? etc?} then registration is rejected with a message: "due to unreliable delivery practices at these domains, we can not accept your registration since we can not properly service you. Please choose another inbox provider and we will gladly accept your registraion"

@nebulon Thank you posting this information. If you enable the Cloudron user directory, is it all users on that Cloudron or only the users defined for that domain? For example, if I have 10 users on mail.domain1.com and 10 users on mail.domain2.com, will every user see 20 users or just the 10 resident in their domain?

@ joseph Thank you. I will try this process. @jdaviescoates Much appreciated tip about "dry run". I will combine your collective wisdom and go forth and conquer!

@ joseph I think I've got it. In checking my DNS, all of my domains are managed at Porkbun, one of the integrated domain/DNS providers. Does that mean that upon restoring the backup, the new Cloudron will detect the change in IP address of the server and request updates @ Porkbun using the API credentials enrolled in my Cloudron?

@joseph Interesting. Hadn't considered that. Can you please provide a link to the recommended procedure? Would I start by adding another Cloudron to my account (say a free version), restore the backup, and then move the paid license to the newly created Cloudron?

@joseph Yes. My appsdata and boxdata folders are symlinked to the external mount point. If you could help provide the correct sequence of commands to stop the Cloudron, copy the folders back to the default location, and restart the Cloudron, I would be very grateful. I get the general idea of what is needed, but I don't want to make a mistake and break my installation. Of course the first step is an extra complete backup!

@joseph Any advice on how to move the core Cloudron data folders back to the main mounted drive? I need to move my Cloudron to a different host.

@d19dotca Interesting. Do you think this might happen even if you were using Mailgun 100% of the time? Did one of your users misbehave and that's why they blocked your IP? I was operating under the assumption that "pay to play" with a large SMTP service would avoid all this hassle. And to avoid unhappy users I was willing to incur the added cost. But perhaps my logic is flawed. Under those circumstances it might be wise to have multiple SMTP paths, with a simple dropdown to select {Cloudron Native, Mailgun, Postmark, etc.} Then we can all go on vacation!