Email sending broken after updating to 8.2.x (due to IPv6 issues)
-
wrote 19 days ago last edited by
Just for the reference:
netplan try
is usually a better way, as it might save from end up getting locked out from the server. I also usually run a background cron task, that removes those temporary files from /etc/netplan, when messing with the network. -
-
wrote 12 days ago last edited by
-
Ok, its not working again (or maybe it never did.
These are my screens
From my understadning, it is set up correctly.wrote 12 days ago last edited by@privsec said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
its not working again
What exactly isn't working?
Have you set up the ipv6 reverse dns/ PTR /rDNS record too?
-
@privsec said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
its not working again
What exactly isn't working?
Have you set up the ipv6 reverse dns/ PTR /rDNS record too?
wrote 11 days ago last edited by@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
What exactly isn't working?
I imagine they are getting bounce to Gmail.
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
Have you set up the ipv6 reverse dns/ PTR /rDNS record too?
Looks like they have looking at screenshot 2....but possibly badly. I think it should say my.businessdoctorut.com
Though for me, after setting it all up properly I kept getting issues and random bounces with the same error message. Only completely disabling IPv6 from the network interface works (and even that turned out to be a struggle
)
-
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
What exactly isn't working?
I imagine they are getting bounce to Gmail.
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
Have you set up the ipv6 reverse dns/ PTR /rDNS record too?
Looks like they have looking at screenshot 2....but possibly badly. I think it should say my.businessdoctorut.com
Though for me, after setting it all up properly I kept getting issues and random bounces with the same error message. Only completely disabling IPv6 from the network interface works (and even that turned out to be a struggle
)
wrote 11 days ago last edited by@avatar1024 My mail server location is
I do keep getting bounced emails from Gmail.
-
wrote 11 days ago last edited by
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 asdhcp
instruction. Runnetplan try
andnetplan apply
if you are lucky.That seems to disable IPv6 on Linux.
<rant> Linux start looking more and more like Windows
</rant>
-
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 asdhcp
instruction. Runnetplan try
andnetplan apply
if you are lucky.That seems to disable IPv6 on Linux.
<rant> Linux start looking more and more like Windows
</rant>
wrote 9 days ago last edited by avatar1024 9 days ago@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 My mail server location is
I do keep getting bounced emails from Gmail.
wrote 9 days ago last edited by@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.
-
wrote 2 days ago last edited by Gengar about 24 hours ago
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!
-
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 -
@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.
-
wrote about 24 hours ago last edited by Gengar about 23 hours ago
@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).
-
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.
wrote about 10 hours ago last edited by@nebulon it seems the issue is simply that Cloudron keeps telling them the PTR record isn't correct, when seemingly actually it is.
-
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.
wrote 7 minutes ago last edited by@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.