Forwarding to Gmail fails "does not meet IPv6 sending guidelines regarding PTR records"

Help! (Home for newbies)
1

|Operating system |CentOS Linux 7.9.2009|
|Webmin version |2.001|
|Usermin version |1.860|

Hi All,
Some of our users have reported that suddenly SOME emails being forwarded to Gmail are bouncing back to the sender saying "Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 ". Nothing has changed recently on this server as far as I am aware.

Spending a few hours searching I have been unable to find any solution but I did find this page

Best practices for forwarding email to Gmail - Gmail Help

where it says

#### Procmail forwarding
Procmail typically changes the envelope sender for forwarded messages.
To fix this issue, add the following to your Procmail configuration file:
`SENDER=`formail -c -x Return-Path``
`SENDMAILFLAGS="-oi -f $SENDER"`

Is this likely to be the issue?

Any suggestions welcome.

Thanks for reading.
Tim

Hmmmm!
Edited to add that I have just noticed that email originating from this server to Gmail may possibly be suffering the same issue. Can’t confirm that is certain at this stage.

2

Assuming you want to use IPV6:

  • Have you added relevant dns records for your IPv6?

Assuming you don’t want to use IPv6:

  • Make sure you have instructed postfix not to use IPv6 by setting inet_protocols in your Postfix’s main.cf file to ipv4 and not ipv4/ipv6, ipv6 or all.
3

Many thanks for your time and trouble.

IPV6 records are set in DNS and the issue seems to be only happening recently.

When searching the web I did see some suggestions similar to yours (disable IPv6) but they were all at least 6 years old so was not very comfortable to do that without some recent advice.

I have made that change so hopefully that will be an end to it.

Again, Many thanks.

4

you should really avoid forwarding and use gmail as email client instead. that would save a lot of trouble…

another solution to avoid ipv6 for gmail only, would be with postfix transport_maps . eg
gmail.com smtp-ipv4:
where smtp-ipv4 in master.cf:
smtp-ipv4 unix - - y - - smtp -o inet_protocols=ipv4

5

Thank you Dimitrist,

I would agree that it would be better to use Gmail as client but some users are too non-techy and simply have too much difficulty doing this.

I can see the benefit of your transport maps suggestion but I don’t feel confident enough to do that without some fairly explicit guidance.

As above, I have disabled IPv6 and early results suggest thet the problem has at least for now, gone away. Unless anyone can see that this will cause other problems I think I am happy with that.

Since this is obviously something that will happen to many if not all, maybe @staff could consider adding this to Virtualmin update at some stage.

Again, thank you for adding your very valid suggestion and time.

Tim

6

If the server has an IPv6 address that is bound to an interface, but has IPv6 disabled globally or on a given virtual server, that may cause problems getting / renewing SSL certs from Let’s Encrypt (and presumably other CA’s).

Google’s suggested solution seems a better bet to me.

Richard

7

Thank you Richard,
I value your (and everyone else’s) reply so I have just tried to renew the Let’s Encrypt cert which went through without issue. Phew!

I’m wondering if this issue will be the same for all running this distro/software combination? If so perhaps @staff could look at it.

Thanks again.

8

We could double check. I will spin up a new server today to test mail stack configured by Virtualmin specifically.

For that IPv6 issue – did you have a correct PTR record set for your IPv6 address?

9

Thanks Illia,

I would appreciate any help you can offer.

I did check the control panel for the server hosting (at the company that host the server) and that was set to a pattern like this “123456.HostingCompany.com” I updated that to the fully qualified domain name that is set on this server like this “ns1.MyServer.co.uk” two days ago.

That was followed by shillongserver’s suggestion above.

It looks like the problem is resolved but whether or not those are the best solutions I will leave you to decide.

Thanks for your ongoing efforts.

10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.