Email sending broken after updating to 8.2.x (due to IPv6 issues)

[potemkin_ai]

Just in case - I've just found that IPv6 might be enabled at the NetPlan level, despite all of the sysctl and other configs.

To disable - add to the appropriate yaml file in /etc/netplan - link-local: [ ipv4 ] - on the same level as dhcp instruction. Run netplan try and netplan apply if you are lucky.

That seems to disable IPv6 on Linux.

<rant> Linux start looking more and more like Windows </rant>

[avatar1024]

@potemkin_ai said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

I've just found that IPv6 might be enabled at the NetPlan level

Yep this has been discussed above in this thread...from post #52 onward. The solution provided by @joseph worked on my end. I had originally tried something along the line you mentioned (adding link-local: [ ipv4 ] to the yaml file but that didn't work...although I might have done it wrong).

[avatar1024]

@privsec said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

I do keep getting bounced emails from Gmail.

In that case I would just disable IPv6 altogether from your server network interface. That's the only only thing that worked for me.

[Gengar]

Hello everyone,

I'm new to this forum (and to Cloudron) and wanted to share that I'm also having issues with IPv6, specifically the PTR6 record.

For some reason, my PTR6 record is in a non-working state (red) and shows a null value.
BUT, I found a workaround.: Rebooting the server.
It temporarily fixes the issue, but after approximatly 12 to 48 hours, the PTR6 record turns red again.

I’m not sure why this happens, but I think it might be linked to the IPv6 issues discussed in this thread. My PTR6 record is correctly set on my VPN provider’s side, so the issue seems to come from either Cloudron or Ubuntu 24.04.

Interestingly, when I check with MXToolbox, the PTR6 record has the correct value, even though Cloudron reports it as null.

My VPS provider has two name servers, and I noticed that MXToolbox retrieves the PTR4 record from the first NS and the PTR6 record from the second NS. This shouldn't normally cause any issues, but I’m mentioning it just in case it’s relevant.

After rebooting my server, everything is green again and working as expected. Both Cloudron and MXToolbox now show the correct PTR6 record. Interestingly, this time, the PTR6 response is coming from the first NS instead of the second (in MXToolBox). No idea if there could be a link with cloudron getting a null value maybe when ptr4 and ptr6 answers are note coming from the same NS server ? … ‍️ Yeahh naaah it seems too weird. Shouldn't be the case.

Has anyone else experienced this? Any ideas for a more permanent solution?

Thanks!

[joseph]

Cloudron uses unbound to do DNS lookups .Can you try host -t PTR <ip6> 127.0.0.150 ? 127.0.0.150 is the address where unbound listens

[Gengar]

@joseph When I have the issue ? Or when I don't ? As I already rebooted my server a few hours ago, atm I don't have the issue. But I guess it will come tomorrow or the day after.

[joseph]

@Gengar when you have the issue. hopefully, the output gives us a good error code to analyze.

[Gengar]

@joseph I'm having the issue right now. And I think I've found a pattern.

It seems to be nearly each time an app updates. And then it breaks my PTR6 record in Cloudron only.
Works fine with MxToolbox (but it switched back to the second nameserver as the last time when it wasn't working on cloudron side for the PTR6 record and the first NS reported the PTR4 record => I still don't think there may be a link but just writing it here in case it could be a lead ) .

Below you will find the output of the following command :

host -t PTR <ip6> 127.0.0.150

Edit : As a workaround I've rebooted my server and now it works again in Cloudron and MxToolBox. But we know it's just a temporary fix... (In mx toolbox the PTR6 is reported by the first NS now. And the PTR4 by the second NS).

[nebulon]

The PTR record is actually set by your server provider, not through Cloudron. Somehow I can't see how this would be connected to an app update, since Cloudron cannot programmatically set the PTR in any way.

[jdaviescoates]

@nebulon it seems the issue is simply that Cloudron keeps telling them the PTR record isn't correct, when seemingly actually it is.

[Gengar]

@nebulon Yeah, I’m aware the PTR6 record is set by my VPS provider, and I’ve double-checked that it’s configured correctly on their end. MXToolBox confirms everything looks good.

The issue seems to be on Cloudron’s side: it occasionally shows the PTR6 record as “null”. But this only happens after some time — for example, right after a full reboot, everything works fine. Then, 24 to 48 hours later, Cloudron throws an error saying the email setup isn’t correct, and it shows the PTR6 value as “null”.

What’s strange is that MXToolBox still shows the correct PTR6 value, exactly as set on my VPS provider’s side. So the record itself is definitely working.

I’ve noticed this often happens after an app update. I’m not 100% sure it’s the cause, but every time the issue appears, it’s usually right after an update.

Not sure if this is a Cloudron issue or something with Ubuntu, but for some reason, only my server fails to resolve the PTR6 correctly after a while.

Edit @ 9:00 PM CET: MiroTalk P2P has been updated automatically at 9PM CET. And atm (9:05PM CET) my PTR6 record is still resolved correctly by Cloudron. I will monitor.

@joseph => fyi

Edit @ 9:40 PM CET : Cloudron doesn't resolve my PTR6 record anymore...

But on MXToolBox Side it's still working fine :

It's only cloudron that returns a "null" value for PTR6.

And I guess the value is null because when I do :

host -t PTR <ip6> 127.0.0.150

I have a time out ...

BTW, I use Uptime Kuma to notify me on Telegram each time there is a notification in Cloudron. And usually notifications are about automatic app updates and my Cloudron will fail to resolve my PTR6 record after this. In this example it was about 40 minutes after the update / the notification. Could also be linked to notifications, idk. But there is something with updates or notifications and PTR6 record resolving on Cloudron/Ubuntu side.

[robi]

@Gengar How did you end up connecting Cloudron notifications to Uptime Kuma?

[Gengar]

@robi said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

How did you end up connecting Cloudron notifications to Uptime Kuma?

I’m using Uptime Kuma to monitor the Cloudron notifications using Cloudron API.

The API endpoint I monitor is:

https://my.domain.tld/api/v1/notifications?acknowledged=false&page=1&per_page=2

This returns a list of unacknowledged notifications. In Uptime Kuma, I use the “Keyword exists” monitor type and set the keyword to:

"notifications":[]

When this keyword is not found, it means there are new notifications waiting to be read. Uptime Kuma then considers the service as “down” and sends me an alert to a Telegram channel. Once I acknowledge the notification in the Cloudron UI, the keyword is present again, and Kuma marks the monitor as “up”.

To authenticate the API call, you need to add a custom header in Uptime Kuma:

{
  "authorization": "Bearer YOUR_CLOUDRON_API_TOKEN"
}

You can generate the API token from your Cloudron account (Account > API Tokens).

I saw this solution somewhere on the forum a while ago, but I don’t remember exactly where or who shared it.

[robi]

@Gengar Oh amazing, thanks for sharing the detail.

That's an interesting choice to keep on top of all the notifications.