A
@nebulon thank you, I thought so but wasn't sure. I've done that and it first glance it seems to have solved both the app install and email bounce issue!
I'll reactivate IPv6 and try those settings on the two other servers and see if all email delivery problem also disappear.
Do I need to also create a AAAA record for the bare domain?
Anyone else experiencing this?
One more thing. On the server where I'm still getting the straight bounce, I've tried to activate IPv6 in the Settings on Cloudron, it worked and the IP is corrected detected. However trying to install apps doesn't work anymore, it stays stuck on Waiting for DNS propagation. So it seems like something is up with the IPv6 set-up on that domain. Any clues on what I need to do? I use wildcard DNS on that domain, do I need to set-up anything manually DNS wise for that domain to work with IPv6?
@girish said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
To fix the situation, you simply have to set IPv6 PTR record .
For me at least this hasn't worked well. I have three servers. In all three I started to get the issues. I entered a PTR record on all three servers and it checks well with google toolbox https://toolbox.googleapps.com/apps/dig/#PTR/ and with https://www.whatsmydns.net/#PTR.
The IPv6 addresses set for the PTR record are the ones indicated in the email error messages which is the same (I've just checked) than the ones indicated by curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip (and the same detected in the Cloudron Network Setting if IPv6 is activated).
On one of the server I kept getting straight bounce after having set the PTR.
On the two other servers I thought the issue was solved as I wasn't getting bounce anymore but when giving a closer look I saw that some messages would still get errors like:
Delivery failure. Will retry in Xs. Upstream error: 421 4.7.23 [2a03:xxxx:xx:xxx:xxxx:7fff:fe49: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. 4fb4d7f45d1cf-5d807030e25si25472762a12.537 - gsmtp",
Most would get delivered after a couple of tries by the mail server while some would stay in the retry loop indefinitely.
@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
I read somewhere that one way to avoid issues with IPv6 stuff was to just have it completely disabled.
It needs to be disabled on the server, not on Cloudron (although it also needs to be disabled on cloudron to avoid issues): https://forum.cloudron.io/post/99661
For me setting the correct IPv6 PTR was not enough to completely resolve this.
It's interesting to see that this issue is happening for you since updating to Cloudron 8.2 as I thought it was a change in Google's end. I have spotted several issues with email delivery recently (which I have submitted in separate threads in the forum) so some changes in emails in Cloudron 8.2 might have created a bunch of problems.
@girish 
Never listen to those grumpy souls who complain about your choice of app packaging...we all (most I'm sure) admire and are grateful for your work!
On the topic: this app looks very cool indeed 
Should we amend this thread / move stuff to a new thread given 8.2 is out?
@NCKNE said in Email delivery issues with double forwarding to external addresses:
Not sure if this might be due to some SRS (https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) misinterpretation?
This is my feeling too...but I'm not sure.
@NCKNE said in Email delivery issues with double forwarding to external addresses:
I have set up similar scenarios on Cloudron, but switched to an external SMTP relay server
Does it work fine with your set-up?
Anyone got a clue at what might be causing this? Happy to send logs or anything else that might help debug.
@joseph Brill, that works, thank you!! All messages are now going through 
Is there any big drawbacks in disabling IPv6? Also since it only happens with Gmail, is there a way to tell the system with IPv6 to only use IPv4 for google MX?
Until this is solved, is it possible to disable IPv6 completely from the mail service? This is affecting basically all of my servers.
@avatar1024 said in Gmail - ipv6. Anyone else with this experience?:
on two of them, the emails do end up delivering after a couple of retry by the mail server (the retries are still because of the PTR record)
Actually in some rare case, the server retries indefinitely and emails are never delivered. From the email event log:
Delivery failure. Will retry in Xs. Upstream error: 421 4.7.23 [2a03:xxxx:xx:xxx:xxxx:7fff:fe49: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. 4fb4d7f45d1cf-5d807030e25si25472762a12.537 - gsmtp",
Using the exact IPv6 in the error message on https://toolbox.googleapps.com/apps/dig/#PTR/ gives the correct PTR.
To keep going with email delivery issues I have noticed the following started to happen recently:
domain1 and domain2 mentioned below are on two different servers managed as Cloudron instances (v8.2.3) and both use built-in SMTP.
mailbox@domain1.coop forwards to several people and to mailbox@domain2.coop.
mailbox@domain2.coop is monitored as a mailbox and also forwards to three people:
person1@gmail.com
person2@posteo.net
person3@domain2.coop (another mailbox on the same server)
When sending an email to mailbox@domain1.coop email get delivered to everyone except to:
person1@gmail.com with the following error:
"Syntax error, cannot decode response. For more information, go to https://support.google.com/a/answer/3221692 and review RFC 5321 specifications. a640c23a62f3a-ab2c9415805si80260366b.277 - gsmtp"
person2@posteo.net with the following error:
"521 5.5.2 mx01.posteo.de Error: bare <LF> received"
For person3@domain2.coop the email is "delivered" as just "Saved" according tot he Event Log.
However sending an email directly to mailbox@domain2.coop delivers fine to everyone.
I've also done other test an the same errors only appears when an email is forwarded twice (like in this example mailbox@domain1.coop > mailbox@domain2.coop > person outside of the server).
I've now also set a PTR record against the short IPv6, it has propagated but I'm still getting the straight bounce.
@andreasdueren said in Gmail - ipv6. Anyone else with this experience?:
Just to clarify: take the IPv6 that is written in the google mail and compare it to the PTR record. Are they identical?
Yes they are!
So the IP is much longer than yours:
As you can tell, I probably do not understand IPv6 very well...
From my provider my server IPv6 seem to be:
So a bit like yours and something much shorter that what Google write in the bounce error message. Bur I thought this was normal as elsewhere in the provider settings page for my server it says:
So putting top and bottom address together I get the long IP google is writing in the error message.
What I did is take the IPv6 google wrote in the bounce error message and added the mail serve name against that.
Also I spoke a bit too quickly I'm actually getting delivery issues on all domains, just on two of them, the emails do end up delivering after a couple of retry by the mail server (the retries are still because of the PTR record), whereas on the third one it's just a straight bounce.
@andreasdueren As far as I can tell yes.
For one of my domain, even though the DNS has propagated and checks all fine on https://www.whatsmydns.net/#PTR and https://toolbox.googleapps.com/apps/dig/#PTR/ I'm still getting the bounce error....damn google!
On two other domains it now works well 
Sorry posting here because I noticed in the image that the date is in DD/MM/YYYY format but in my Cloudron it's in MM/DD/YYYY format (also in event logs, etc.). Any idea how to change it??
PS: my Nextcloud install is from 23/11/18
