Cloudron Forum

The first time this took place(update, notification/broken Cloudron services), was on a VPS hosted by SSDnodes - thus constituting my first experience with the infamous IPv6 bug, and as a result of a reboot request(notification), following a Cloudron update.

In this particular case, and though I did confirm the IPv6 issue, I chose not to repair, in-favor of rolling-back(snapshot), for the sake of brevity.

Fast-forward to this round - and on a rather fresh Cloudron installation, on Proxmox VM w/different provider, I'd add that both instances would constituted what I'd call vanilla, in-that they were both simple mail servers, with a single SOGo application for webmail.

Beyond that, there were no modifications made on either instances beyond the addition of nftables.

NB, the first instance was on a network with IPv6 support, whereas the second(more recent), is on an IPv4 only network.

PS, if you would like additional details on this particular incident, please don't hesitate to ask as the details remain fresh on my purview, and moreso, that I would really like to help in improving the Cloudron experience for others

Came into the Cloudron interface and found a reboot required message

Did the reboot, and then found ipv6 broken - I was able to address this using the following approach;

sudo sysctl -w net.ipv6.conf.ens18.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.tailscale0.disable_ipv6=1
sudo systemctl restart box

That said, and after a reboot, I then found the Mailserver service was completely down both internally and externally - a closer examination revealed a mail container corruption overlay filesystem reference, preventing the service from starting - ie, mail configuration directory at /home/yellowtent/platformdata/mail/ was missing, preventing automatic recreation by the box service

Would also add that standard recovery attempts(sudo systemctl restart box), was not successful, in-that the mail container would be automatically recreated

A closer look revealed the configuration was missing;
sudo ls -la /home/yellowtent/platformdata/mail/

no such file or directory

And that a forced rebuild was needed;
sudo rm /home/yellowtent/platformdata/INFRA_VERSION

BTW, this same thing happened in previous months with Cloudron, following an automated update - granted, snapshots can(and should), be made priior-to any type of update/OS or otherwise, though I can't help but feel that issues like this should not occur so frequently, even on a personal use level

• hope this helps someone out there

This is a problem that came-up before, and was deemed fixed(v 7.x), though I personally cannot confirm whether that was the case.

That said, I noticed an ongoing issue with Cloudron/Haraka mail, in-that it is not acknowledging SPF record entries, and thus detrimental to spam score;

X-Spam-Report: 
	* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
	*  1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	*  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
	*      valid
	* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
	*       domain
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	* -1.0 DKIMWL_WL_MED DKIMwl.org - Medium trust sender

Nevermind, I did a rollback and fixed it

Tried removing SoGo and getting;

Task Error

If a configuration, update, restore or backup action resulted in an error, you can retry the task.

An error occurred during the uninstall operation: External Error: [403] Invalid access token code:9109

Hi, no Netcup here

I run a tight ship and can confirm this is specific to latest Cloudron update, which is still in queue(awaiting restart). And though it on me, for enabling auto-update, I would say this constitutes a faulty update.

That said, and if this doesn't get fixed soon, I will have to migrate my mail service off Cloudron unfortunately

• saw IPv6 related issues in other posts, and would add that my server(Ubuntu) and rDNS(etc), is entirely IPv6 compliant, and so that is not likely the issue here.

NB, might take another stab at this to capture log data - been contemplating moving my mail/gateway to a Proxmox server, and so I guess this is as good a motivation as any

Holy crap Batman!

I logged-in Cloudron interface and found an update/reboot notification, did the deed, only to find email /SoGo completely unresponsive after the fact.

Luckily, I had snapshots to fall back-on, but wow, talk about a slap in the face.
No idea what went-wrong, though my current solution is to avoid the update to keep things up and running, which isn't good.

@fbartels

So sorry, but was short on time and opted to reinstall the cert. to get back to what seems like normal - and so, I have no information to share in-terms of troubleshooting.

That said, and if /or when this happens again, I'll take the time to properly investigate

NB, for what it's worth, I am using Cloudflare API key, of which has always worked without issue in Cloudron, though for some unknown reason, the cert appears to have expired and would no longer renew. And so I performed as roll-over oin the API/Key side of things, then reissued, and everything appears to be back to normal

Logged-into 'my.domain.com', and found SSL error.
Checked another site and found the same.

That said, these sites were fine for several months without issue., though for some unknown reason, it would appear though the certs are no longer being used properly.

PS, tried reissuing without success, not sure what is wrong though it would appear that there may be a discrepancy with Cloudflare issued Let's Encrypt certs

@girish said in Completely baffled with email forwarding /aliases:

@JohnBee ...I tried to look into mailcow docs as to what aliases mean but I didn't find any relevant docs. Do you have a link where we can read more?

Unfortunately, Mailcow isn't very good on documentation - though as I keep a staging server on tap, I can provide screenshots, or even access should you fancy a closer look at the interface etc.

PS, as much as I love Mailcow's creative approach to a turn-key mail server/service, I came to appreciate(the hard way), the inherent risks of using open source software in live environments

@girish said in Completely baffled with email forwarding /aliases:

@JohnBee ...When you edit mailbox -> Add Alias -> note the domain is a dropdown (I know it's a bit tricky to get this...)

This was the missing element in my dilemma!
Many thanks

@fbartels

Hi and thanks for sticking with me on this, and I would apologize here again, for the ongoing lack of clarity, as I reread my comment, and realized, it read as though the subsequent mailboxes were all part of the same domain.

And so, with that being said, I had to edit my comment to correct this, in-that these are not all part of the same domain, but rather, that these are all individual domains and mailboxes.

I see, and would agree that is likely the case with Mailcow.
That said, perhaps a bit more detail with regard to intent will prove helpful;

Central mailbox: john@mymainbox.com

Mailbox 1: john@otherdomain1.com
Mailbox 2: john@otherdomain2.com
Mailbox 3: john@otherdomain3.com

All incoming mail(mailboxes; 1,2, and 3), are forwarded to ..@mymainbox.com accordingly.
All responses to said mails(1,2 or 3), invokes the respective respondent(email), as a result of alias.

This way, many email addresses can be managed in one single mailbox.
And moreso, that responding to any of said emails as the respective receiving mailbox owner, would consist of clicking reply on the respective emails.

• hope this helps

I am somewhat perplexed as to how to setup email forwarding and aliasing in Cloudron.

Coming from Mailcow, alias accounts are created within the user mailbox itself, for which, user credentials are then passed-on, or inherited accordingly.

Though as it stands, I cannot accomplish a similar setup in Cloudron, as the options seem to be that of creating the mailboxes with shared ownership, though I can't seem to figure out how to setup forwarding?

Likewise, I'm having difficulty with webmail, in that SoGo doesn't seem to want to allow the addition of identities in my main account - and so, I'm having to create all of the accounts via IMAP with separate identities - though here again, without a mailbox, taggging, aliasing etc?

• sorry if this is confusing, I'm very new to Cloudron, and having a tough time wrapping my head around the methodology that comes with the software

Hi, and thanks so much for the replies - much appreciated

I just installed Cloudron on a fresh VPS(Ubuntu 22.04), and though I'd take a peek at the logs(sys.info), and found what looks like an endless amount of warnings.

That said, does anyone know what this is, and moreso, if I need to do anything about it?