Email sending broken after updating to 8.2.x (due to IPv6 issues)
-
I set this up and it worked on netcup for about a week.
Itβs giving me Al the error again about gmails ipv6 not being set up correctly.
Is there an in-depth how to guide to correcting this on netcup?
wrote on Feb 6, 2025, 4:06 PM last edited by@privsec not netcup specific but the most in depth guide is this post by @avatar1024 :
https://forum.cloudron.io/topic/13072/gmail-ipv6-anyone-else-with-this-experience/22?_=1738857946551
-
wrote on Feb 8, 2025, 11:10 PM last edited by
Also got massive problems sending mails for 2 days now. Possible that 8.2.4 was released that day?
-
Also got massive problems sending mails for 2 days now. Possible that 8.2.4 was released that day?
wrote on Feb 8, 2025, 11:13 PM last edited by@sponch have you sorted out your IPv6 stuff?
-
wrote on Feb 9, 2025, 4:13 AM last edited by sponch Feb 9, 2025, 4:14 AM
Yes. Worked well after doing so for some days. Then βout of the blueβ sending not possible anymore on both of my instances.
βEmail not configured properlyβ errors in notifications when I go to email-overview page it takes 30-40 seconds until the domains get green. All values are set correctly for every single domainβ¦
Log says: Delivery failure, will retry in 65536s.. DNS lookup failure: Error: queryMx ESERVFAIL -
-
wrote on Feb 9, 2025, 9:58 AM last edited by
will try that.
Just found that issue on Hetzner: can that be the reason??
Due to a missing DKIM signature (DomainKey), external mail servers reject your e-mails as spam. For this reason, we have activated DKIM for your domains.If you use our DNS servers for these domains, the DKIM record has been automatically set in the DNS. If you use external DNS servers for these domains, you must also store the displayed DNS record there accordingly. To do this, open the βProductsβ tab, select the domain in question and click on βAdvanced settingsβ under the menu items βE-Mail; DKIM / SPF / DMARCβ.
-
@sponch they might be old emails. You can just delete the old mail queue (to check if these are fresh failures) from
/home/yellowtent/boxdata/mail/haraka-queue/
(files inside it). Restart mail container after deleting files. -
will try that.
Just found that issue on Hetzner: can that be the reason??
Due to a missing DKIM signature (DomainKey), external mail servers reject your e-mails as spam. For this reason, we have activated DKIM for your domains.If you use our DNS servers for these domains, the DKIM record has been automatically set in the DNS. If you use external DNS servers for these domains, you must also store the displayed DNS record there accordingly. To do this, open the βProductsβ tab, select the domain in question and click on βAdvanced settingsβ under the menu items βE-Mail; DKIM / SPF / DMARCβ.
wrote on Feb 9, 2025, 8:07 PM last edited by@sponch said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
Just found that issue on Hetzner: can that be the reason??
Could be. Have you hit resync dns after enabling and doing all the ipv6 stuff? I think that should auto generate this stuff for you (presuming you're using a supported DNS provider)
-
wrote on Feb 11, 2025, 12:49 PM last edited by avatar1024 Feb 11, 2025, 12:52 PM
I've started to have this issue again randomly (emails only sometimes bounce...helpful I know) despite having IPv6 is disabled on both Cloudron and on the Network interface for that server.
-
I've started to have this issue again randomly (emails only sometimes bounce...helpful I know) despite having IPv6 is disabled on both Cloudron and on the Network interface for that server.
wrote on Feb 11, 2025, 1:21 PM last edited by@avatar1024 said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
having IPv6 is disabled on both Cloudron and on the Network interface for that server.
I think the solution is not to disable IPv6 but to fully set it all up. Seems to me this has basically become a requirement Big Tech is forcing on us all.
-
@avatar1024 said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
having IPv6 is disabled on both Cloudron and on the Network interface for that server.
I think the solution is not to disable IPv6 but to fully set it all up. Seems to me this has basically become a requirement Big Tech is forcing on us all.
wrote on Feb 12, 2025, 11:17 AM last edited by@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
I think the solution is not to disable IPv6 but to fully set it all up.
I'm afraid this is still not working, I keep getting weird intermittent bounce even though it's all set-up...
-
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
I think the solution is not to disable IPv6 but to fully set it all up.
I'm afraid this is still not working, I keep getting weird intermittent bounce even though it's all set-up...
wrote on Feb 12, 2025, 1:29 PM last edited by@avatar1024 said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
I think the solution is not to disable IPv6 but to fully set it all up.
I'm afraid this is still not working, I keep getting weird intermittent bounce even though it's all set-up...
-
wrote on Feb 12, 2025, 7:44 PM last edited by
So with a self hosted install I would need to ask the ISP to set up the ipv6 PTR like they ip4 record ?
-
wrote on Feb 12, 2025, 7:59 PM last edited by
Ok so I've now noticed that the bounce are only when someone with a Gmail address email say user1@mydomain (mailbox hosted on Cloudron) which then forwards to user1@gmail (redirect through roundcube).
- anyuser@mydomain > user1@gmail works
(
- anyuser@posteo > user1@mydomain > user1@gmail works
- anyuser@gmail > user1@mydomain > user1@gmail fails
So something seem to be up with redirect specifically when the sender is a Gmail user and the recipient of the redirect is Gmail user.
Error is the usual IPv6 Google BS:
"Upstream error: 421 4.7.23 [2a03:xxxx:xx:xxx:xxxx:xxxx:xxxx:51af] The IP address sending this 4.7.23 message does not have a PTR record, or the corresponding forward DNS 4.7.23 entry does not match the sending IP. To protect our users from spam, 4.7.23 mail has been temporarily rate limited. To learn more about IP 4.7.23 address requirements for sending to Gmail, visit 4.7.23 https://support.google.com/a?p=sender-guidelines-ip 4.7.23 To learn more about Gmail requirements for bulk senders, visit 4.7.23 https://support.google.com/a?p=sender-guidelines. a640c23a62f3a-ab7d06caa39si398649666b.93 - gsmtp", "delay": 128
- anyuser@mydomain > user1@gmail works
-
Ok so I've now noticed that the bounce are only when someone with a Gmail address email say user1@mydomain (mailbox hosted on Cloudron) which then forwards to user1@gmail (redirect through roundcube).
- anyuser@mydomain > user1@gmail works
(
- anyuser@posteo > user1@mydomain > user1@gmail works
- anyuser@gmail > user1@mydomain > user1@gmail fails
So something seem to be up with redirect specifically when the sender is a Gmail user and the recipient of the redirect is Gmail user.
Error is the usual IPv6 Google BS:
"Upstream error: 421 4.7.23 [2a03:xxxx:xx:xxx:xxxx:xxxx:xxxx:51af] The IP address sending this 4.7.23 message does not have a PTR record, or the corresponding forward DNS 4.7.23 entry does not match the sending IP. To protect our users from spam, 4.7.23 mail has been temporarily rate limited. To learn more about IP 4.7.23 address requirements for sending to Gmail, visit 4.7.23 https://support.google.com/a?p=sender-guidelines-ip 4.7.23 To learn more about Gmail requirements for bulk senders, visit 4.7.23 https://support.google.com/a?p=sender-guidelines. a640c23a62f3a-ab7d06caa39si398649666b.93 - gsmtp", "delay": 128
wrote on Feb 12, 2025, 9:19 PM last edited by@avatar1024 said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
Ok so I've now noticed that the bounce are only when someone with a Gmail address email say user1@mydomain (mailbox hosted on Cloudron) which then forwards to user1@gmail (redirect through roundcube).
anyuser@mydomain > user1@gmail works β ( anyuser@posteo > user1@mydomain > user1@gmail works β anyuser@gmail > user1@mydomain > user1@gmail fails β
So something seem to be up with redirect specifically when the sender is a Gmail user and the recipient of the redirect is Gmail user.
This sounds like the same or very similar problem as @fengchang is having too https://forum.cloudron.io/topic/13277/forward-email-with-ses-got-554-message-rejected-email-address-is-not-verified?_=1739395101471
- anyuser@mydomain > user1@gmail works
-
@avatar1024 said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
Ok so I've now noticed that the bounce are only when someone with a Gmail address email say user1@mydomain (mailbox hosted on Cloudron) which then forwards to user1@gmail (redirect through roundcube).
anyuser@mydomain > user1@gmail works β ( anyuser@posteo > user1@mydomain > user1@gmail works β anyuser@gmail > user1@mydomain > user1@gmail fails β
So something seem to be up with redirect specifically when the sender is a Gmail user and the recipient of the redirect is Gmail user.
This sounds like the same or very similar problem as @fengchang is having too https://forum.cloudron.io/topic/13277/forward-email-with-ses-got-554-message-rejected-email-address-is-not-verified?_=1739395101471
wrote on Feb 12, 2025, 10:03 PM last edited by avatar1024 Feb 12, 2025, 10:07 PM@jdaviescoates Indeed that looks very similar...thanks I'll post there. In my case I'm using the Cloudron built SMTP server
I wonder if it is also linked to this: https://forum.cloudron.io/post/99711
-
wrote on Feb 13, 2025, 9:58 AM last edited by
@avatar1024 Is 421 4.7.23 your VPS IP?
-
@avatar1024 Is 421 4.7.23 your VPS IP?
wrote on Feb 13, 2025, 10:41 AM last edited by avatar1024 Feb 13, 2025, 10:43 AM@scooke nope 421 4.7.23 is the Google error code I believe, see https://support.google.com/a/answer/81126?visit_id=638750398959602051-541616874&p=sender-guidelines&rd=1 .
The IP(v6) of the server is the one in the error message right after 421 4.7.23 in [] which I've hidden with xxx.
-
wrote on Feb 13, 2025, 11:41 AM last edited by
Given this only happens with forwards it seems it might have to do with the SRS rewrite. The weird thing is why does it only happens if the original sender is Gmail?