PTR problem between Linode & Mastadon
-
@DeBossNow It seems obvious that the PTR check should recognize that the Linode server environment is Different from, say, Hetzner, etc. and knowing that important fact it will adjust its expectations for that PTR string and give it a green light.
A simple if/or/then check to handle the query back to the Linode environment where Cloudron is installed.
@DeBossNow, where are you configuring your rDNS settings? I don't have that issue. I can set
sub.domain.tldin the Networking tab of the Linode that Cloudron is installed on... -
I am not really understanding your problem. In Cloudron you can set the mail server location to be whatever you want. It will default to my.domain.xx after installation but you can change it to domain.xx so that it matches the PTR record.
The MX and A/AAA records have nothing to do with this. Cloudron just checks that there is a PTR record that matches the mailserver hostname. Also the server environment is irrelevant.
@ccfu
"Cloudron just checks that there is a PTR record that matches the mailserver hostname. Also the server environment is irrelevant."If this was happening as you say then the Cloudron check would be happy with the MX record. NO Error.
As I showed -- the reason I INCLUDED IT Twice now --
is that the MX record, while set up BY Cloudron when I elected to use the default SMTP server for outgoing mail -- then set by Cloudron as my.currentdomain.de -- does NOT SATISFY the PTR checkObviously, the PTR check keeps referring to the A/AAAA Records. It SCANS NOT the MX record which IS my.currentdomain.de ---
but focuses on looking for another kind of record.I did not install a separate email server app. I am just using the vanilla Cloudron email server setup which GENERATED the MX Record on my Linode server.
i do NOT WANT TO CHANGE anything more.
But the PTR check is reporting that is it finding
my standard DNS reverse currentdomain.de linked to my public IP. And it is demanding that to be happy that it finds a PTR record that literally contains this string --
my.currentdomain.deThis is just plainly NOT HAPPENING as you describe:
"you can change it to domain.xx so that it matches the PTR record."
I WANT THE PTR TO JUST LOOK AT MY MX RECORD AT MY SERVER AND STOP REPORTING AN ERROR.How many times can I repeat this and still confuse you?
IF the PTR Check in Cloudron was simply referring to the MX Record my.currentdomain.de then NO ERROR.
All I can do is REPORT what Cloudron's PTR Check is showing me. ERROR. -
@ccfu
"Cloudron just checks that there is a PTR record that matches the mailserver hostname. Also the server environment is irrelevant."If this was happening as you say then the Cloudron check would be happy with the MX record. NO Error.
As I showed -- the reason I INCLUDED IT Twice now --
is that the MX record, while set up BY Cloudron when I elected to use the default SMTP server for outgoing mail -- then set by Cloudron as my.currentdomain.de -- does NOT SATISFY the PTR checkObviously, the PTR check keeps referring to the A/AAAA Records. It SCANS NOT the MX record which IS my.currentdomain.de ---
but focuses on looking for another kind of record.I did not install a separate email server app. I am just using the vanilla Cloudron email server setup which GENERATED the MX Record on my Linode server.
i do NOT WANT TO CHANGE anything more.
But the PTR check is reporting that is it finding
my standard DNS reverse currentdomain.de linked to my public IP. And it is demanding that to be happy that it finds a PTR record that literally contains this string --
my.currentdomain.deThis is just plainly NOT HAPPENING as you describe:
"you can change it to domain.xx so that it matches the PTR record."
I WANT THE PTR TO JUST LOOK AT MY MX RECORD AT MY SERVER AND STOP REPORTING AN ERROR.How many times can I repeat this and still confuse you?
IF the PTR Check in Cloudron was simply referring to the MX Record my.currentdomain.de then NO ERROR.
All I can do is REPORT what Cloudron's PTR Check is showing me. ERROR.@DeBossNow can you please share your domain name so I can have a look?
-
@ccfu
"Cloudron just checks that there is a PTR record that matches the mailserver hostname. Also the server environment is irrelevant."If this was happening as you say then the Cloudron check would be happy with the MX record. NO Error.
As I showed -- the reason I INCLUDED IT Twice now --
is that the MX record, while set up BY Cloudron when I elected to use the default SMTP server for outgoing mail -- then set by Cloudron as my.currentdomain.de -- does NOT SATISFY the PTR checkObviously, the PTR check keeps referring to the A/AAAA Records. It SCANS NOT the MX record which IS my.currentdomain.de ---
but focuses on looking for another kind of record.I did not install a separate email server app. I am just using the vanilla Cloudron email server setup which GENERATED the MX Record on my Linode server.
i do NOT WANT TO CHANGE anything more.
But the PTR check is reporting that is it finding
my standard DNS reverse currentdomain.de linked to my public IP. And it is demanding that to be happy that it finds a PTR record that literally contains this string --
my.currentdomain.deThis is just plainly NOT HAPPENING as you describe:
"you can change it to domain.xx so that it matches the PTR record."
I WANT THE PTR TO JUST LOOK AT MY MX RECORD AT MY SERVER AND STOP REPORTING AN ERROR.How many times can I repeat this and still confuse you?
IF the PTR Check in Cloudron was simply referring to the MX Record my.currentdomain.de then NO ERROR.
All I can do is REPORT what Cloudron's PTR Check is showing me. ERROR.The MX record has nothing to do with outgoing mail. Cloudron doesn't care what the MX record is and does not even look at it!
Does the PTR record of your server match the mailserver location on the page
/#/email? Is there an A record for this (sub-)domain? If you can answer both these questions with YES, then the checks will pass. -
@DeBossNow, where are you configuring your rDNS settings? I don't have that issue. I can set
sub.domain.tldin the Networking tab of the Linode that Cloudron is installed on...@colonelpanic Thank you for trying to help.
I REALLY DO KNOW BACKWARDS AND FORWARDS WHAT I CAN SET IN MY LINODES ACCOUNT.
I HAVE SET UP 6 WEBSITES, ALL NODE.JS ETC AT LINODES.
I HAVE MADE MANY MORE VOLUME SETUPS FOR DIFFERENCT SCENARIOS
THERE IS JUST NO WAY THAT USING THE LINODE TOOLS I CAN ADD A SEPARATE DNS ENTRY IN THE A/AAAA Records that assigns my public IP address to an entry that reads the following string --- my.currentdomain.de
If I could literally save that value then, presumably, the Cloudron PTR would be satisfied.LITERALLY the Linode DNS tools, once the main domain name is entered, the Sub domains such as MY or WHATEVER.currentdomain.de will NOT SAVE AS SUCH.
The base domain name is STRIPPED out ... leaving only the PREFIX of the sub domain.
-
@colonelpanic Thank you for trying to help.
I REALLY DO KNOW BACKWARDS AND FORWARDS WHAT I CAN SET IN MY LINODES ACCOUNT.
I HAVE SET UP 6 WEBSITES, ALL NODE.JS ETC AT LINODES.
I HAVE MADE MANY MORE VOLUME SETUPS FOR DIFFERENCT SCENARIOS
THERE IS JUST NO WAY THAT USING THE LINODE TOOLS I CAN ADD A SEPARATE DNS ENTRY IN THE A/AAAA Records that assigns my public IP address to an entry that reads the following string --- my.currentdomain.de
If I could literally save that value then, presumably, the Cloudron PTR would be satisfied.LITERALLY the Linode DNS tools, once the main domain name is entered, the Sub domains such as MY or WHATEVER.currentdomain.de will NOT SAVE AS SUCH.
The base domain name is STRIPPED out ... leaving only the PREFIX of the sub domain.
@DeBossNow WHY ARE YOU SHOUTING?
The base domain is not stripped out, it is just not showing because it is clear what the domain is. If the domain were being stripped out, nothing would work!
This is NOT the problem. The problem is a mismatch between the mailserver location in Cloudron and your server's PTR record.
Again:
@ccfu said in PTR problem between Linode & Mastadon:
Does the PTR record of your server match the mailserver location on the page /#/email? Is there an A record for this (sub-)domain? If you can answer both these questions with YES, then the checks will pass.
-
@colonelpanic Thank you for trying to help.
I REALLY DO KNOW BACKWARDS AND FORWARDS WHAT I CAN SET IN MY LINODES ACCOUNT.
I HAVE SET UP 6 WEBSITES, ALL NODE.JS ETC AT LINODES.
I HAVE MADE MANY MORE VOLUME SETUPS FOR DIFFERENCT SCENARIOS
THERE IS JUST NO WAY THAT USING THE LINODE TOOLS I CAN ADD A SEPARATE DNS ENTRY IN THE A/AAAA Records that assigns my public IP address to an entry that reads the following string --- my.currentdomain.de
If I could literally save that value then, presumably, the Cloudron PTR would be satisfied.LITERALLY the Linode DNS tools, once the main domain name is entered, the Sub domains such as MY or WHATEVER.currentdomain.de will NOT SAVE AS SUCH.
The base domain name is STRIPPED out ... leaving only the PREFIX of the sub domain.
@DeBossNow
If I had an account at Hetzner, for instance, I could do what I am used to doing for years and years --currentdomain.de -- IP xx.xxx.xxx.xx
my.currentdomain.de -- IP xx.xxx.xxx.xxbut when I write and save at Linodes the subdomain prefix my. or any other prefix mail. or whoopee. etc is STRIPPED from its base domain and gets saved, no matter what as --
my -- IP xx.xxx.xxx.xx
-
@DeBossNow
If I had an account at Hetzner, for instance, I could do what I am used to doing for years and years --currentdomain.de -- IP xx.xxx.xxx.xx
my.currentdomain.de -- IP xx.xxx.xxx.xxbut when I write and save at Linodes the subdomain prefix my. or any other prefix mail. or whoopee. etc is STRIPPED from its base domain and gets saved, no matter what as --
my -- IP xx.xxx.xxx.xx
@DeBossNow It is just an interface issue. Linode appears to not show the domain part, whereas other providers do. I use two different DNS providers - one shows the domain, the other one does not. The DNS zone is the domain part so EVERYTHING that is saved is .domain.xx
-
@DeBossNow WHY ARE YOU SHOUTING?
The base domain is not stripped out, it is just not showing because it is clear what the domain is. If the domain were being stripped out, nothing would work!
This is NOT the problem. The problem is a mismatch between the mailserver location in Cloudron and your server's PTR record.
Again:
@ccfu said in PTR problem between Linode & Mastadon:
Does the PTR record of your server match the mailserver location on the page /#/email? Is there an A record for this (sub-)domain? If you can answer both these questions with YES, then the checks will pass.
@ccfu I know that it is not really stripped out.
I know that.
What I am saying is that the Cloudron PTR checking script does NOT include this value.
It is reporting back that it wants to find the literal string "my.currentdomain" but all it finds is "currentdomain.de" and that it is expecting to find "my.currentdomain.de".I am incredibly frustrated by now. I cannot report it more clearly than I have. About 3 years ago I read about the SAME PROBLEM on this PTR check with Linode. I never saw a solution. Emails worked. Move on. Ignore it seemed to be the consensus.
I was hoping in 2023 this would be resolved.
-
@colonelpanic Thank you for trying to help.
I REALLY DO KNOW BACKWARDS AND FORWARDS WHAT I CAN SET IN MY LINODES ACCOUNT.
I HAVE SET UP 6 WEBSITES, ALL NODE.JS ETC AT LINODES.
I HAVE MADE MANY MORE VOLUME SETUPS FOR DIFFERENCT SCENARIOS
THERE IS JUST NO WAY THAT USING THE LINODE TOOLS I CAN ADD A SEPARATE DNS ENTRY IN THE A/AAAA Records that assigns my public IP address to an entry that reads the following string --- my.currentdomain.de
If I could literally save that value then, presumably, the Cloudron PTR would be satisfied.LITERALLY the Linode DNS tools, once the main domain name is entered, the Sub domains such as MY or WHATEVER.currentdomain.de will NOT SAVE AS SUCH.
The base domain name is STRIPPED out ... leaving only the PREFIX of the sub domain.
@DeBossNow please be more respectful with everyone in this forum.
Everyone here is helping out of there good heart and using their free time to respond to you.
Do not take this for granted!Since you ignored my request to share your domain so I can not confirm your DNS settings.
I have set up 100x more Cloudron servers on almost any provider out there and can not relate to your issue.
Right now for me it simply reads like you have no clue where to set the PTR record since it's not the same interface as the normal A/AAAA DNS settings. (My view, must not be true!)So once again, can you share your domain so I can have a look?
And again, be more respectful with the people here. Last warning.
No matter your frustration level you are writing with real humans here. -
@ccfu I know that it is not really stripped out.
I know that.
What I am saying is that the Cloudron PTR checking script does NOT include this value.
It is reporting back that it wants to find the literal string "my.currentdomain" but all it finds is "currentdomain.de" and that it is expecting to find "my.currentdomain.de".I am incredibly frustrated by now. I cannot report it more clearly than I have. About 3 years ago I read about the SAME PROBLEM on this PTR check with Linode. I never saw a solution. Emails worked. Move on. Ignore it seemed to be the consensus.
I was hoping in 2023 this would be resolved.
@DeBossNow Leave Linode. Why hit your head against a wall you know is there???
And apologize.
-
@DeBossNow It is just an interface issue. Linode appears to not show the domain part, whereas other providers do. I use two different DNS providers - one shows the domain, the other one does not. The DNS zone is the domain part so EVERYTHING that is saved is .domain.xx
@ccfu l understand the interface problem.
I did not start in this stuff a week ago.I am telling you that the PTR check is what does not understand, so to speak, the "Interface problem".
I do not have access to the Cloudron PTR check script to modify it for what it finds when it checks the server configuration at linodes.
It is an inteface mismatch not with ME but with the internals of the script. It does not find the literal string "my.currentdomain.de" -- it obviously ONLY finds "currentdomain.de". There is an adjacent record at Linode that should contain the value "my.currentdomain.de" just as the MX record contains.
But I cannot edit, I cannot add that DNS reverse lookup value as "my.currentdomain.de". And, obviously Linode does not read out that full prefix with base domain name to the Cloudron PTR script.
I thought this would be simple. I am done. I thank you for all your help, everyone.
-
@DeBossNow Leave Linode. Why hit your head against a wall you know is there???
And apologize.
@scooke This is such a minor problem.
The solution is easier to leave Cloudron, proportionately, than leave the Linode hosting over such a minuscule problem.Just the PTR check. It bothers me to see it when it could be resolved by revising the PTR script at Cloudron to understand that it must append the base domain to the subdomain DNS entries it finds. Because Linode JUST saves the naked prefix in that field.
The Cloudron PTR check a couple of years ago was reported by more than me in the forum as persisting in this error that could not be changed at Linode. They just do not save anything but the individual prefix for each subdomain DNS reverse entry.
All subdomains in the A/AAAA records at linode are saved by prefix only --
my (not my.currentdomain.de)mail (not mail.currentdomain.de)
-
@ccfu l understand the interface problem.
I did not start in this stuff a week ago.I am telling you that the PTR check is what does not understand, so to speak, the "Interface problem".
I do not have access to the Cloudron PTR check script to modify it for what it finds when it checks the server configuration at linodes.
It is an inteface mismatch not with ME but with the internals of the script. It does not find the literal string "my.currentdomain.de" -- it obviously ONLY finds "currentdomain.de". There is an adjacent record at Linode that should contain the value "my.currentdomain.de" just as the MX record contains.
But I cannot edit, I cannot add that DNS reverse lookup value as "my.currentdomain.de". And, obviously Linode does not read out that full prefix with base domain name to the Cloudron PTR script.
I thought this would be simple. I am done. I thank you for all your help, everyone.
It is simple, but unfortunately you don't seem to be willing to understand the way certain things work and where you need to set what. Also, you ignore what people tell you and just repeat the same incorrect information (for example that Linode just saves a prefix (sic), but you say you understand the interface problem).
The PTR check does exactly that - it checks the PTR record for the domain that is set as the mailserver location and if this doesn't match then the check will logically fail. There is nothing wrong with the check script.
What domain is set as the mailserver location in Cloudron?
What domain is set in your PTR record? -
It doesn't even make sense - OP wants Cloudron's script to check for a SINGLE WORD PTR record, "my".
I am blocking this user. Even though they've been here a fair amount of time, this is just nonsense posting which is wasting everyone's time who tries to help.
bye!
-
It is simple, but unfortunately you don't seem to be willing to understand the way certain things work and where you need to set what. Also, you ignore what people tell you and just repeat the same incorrect information (for example that Linode just saves a prefix (sic), but you say you understand the interface problem).
The PTR check does exactly that - it checks the PTR record for the domain that is set as the mailserver location and if this doesn't match then the check will logically fail. There is nothing wrong with the check script.
What domain is set as the mailserver location in Cloudron?
What domain is set in your PTR record?@ccfu Thank you for your help.
I understand that you have a lot on your plate, so I appreciate your expertise.But, my willingness to help or cooperate is not necessarily reflected by failing to understand you.
What you have just asked me I have included as Copy and Paste directly from both my Linode server and from my Cloudron dashboard -- only obscuring IP and Domain name.
My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.de**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10But i literally can not get this same value saved as a PTR record.
Linode server Configuration --
A/AAAA Record
Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxCloudron PTR check says that it wants to find a DNS record that reads as
my.currentdomain.de IP Public xx.xx.xxx.xxx
But all Cloudron reports is finding my base domain name. currentdomain.de
The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxxbut when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just asmy IP xx.xx.xxx.xxx
Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.
The Edit function after the fact does not make any difference either.
-
@ccfu Thank you for your help.
I understand that you have a lot on your plate, so I appreciate your expertise.But, my willingness to help or cooperate is not necessarily reflected by failing to understand you.
What you have just asked me I have included as Copy and Paste directly from both my Linode server and from my Cloudron dashboard -- only obscuring IP and Domain name.
My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.de**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10But i literally can not get this same value saved as a PTR record.
Linode server Configuration --
A/AAAA Record
Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxCloudron PTR check says that it wants to find a DNS record that reads as
my.currentdomain.de IP Public xx.xx.xxx.xxx
But all Cloudron reports is finding my base domain name. currentdomain.de
The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxxbut when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just asmy IP xx.xx.xxx.xxx
Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.
The Edit function after the fact does not make any difference either.
@DeBossNow
The PTR record can not be set in the same web interface as the normal DNS settings forMXAAAAATXT@records.
It really, really, REALLY reads like you are in the wrong management web interface!Please read and follow the official Linode guide and set the correct value.
https://www.linode.com/docs/products/compute/compute-instances/guides/configure-rdns/#setting-reverse-dnsAnd still, please share your real domain so I can validate the DNS settings, this could save us all so much time and pain.
-
@ccfu Thank you for your help.
I understand that you have a lot on your plate, so I appreciate your expertise.But, my willingness to help or cooperate is not necessarily reflected by failing to understand you.
What you have just asked me I have included as Copy and Paste directly from both my Linode server and from my Cloudron dashboard -- only obscuring IP and Domain name.
My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.de**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10But i literally can not get this same value saved as a PTR record.
Linode server Configuration --
A/AAAA Record
Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxCloudron PTR check says that it wants to find a DNS record that reads as
my.currentdomain.de IP Public xx.xx.xxx.xxx
But all Cloudron reports is finding my base domain name. currentdomain.de
The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxxbut when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just asmy IP xx.xx.xxx.xxx
Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.
The Edit function after the fact does not make any difference either.
OK, let's try one last time to get this resolved for you:
@DeBossNow said in PTR problem between Linode & Mastadon:
My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.deThis means that your server's PTR record is currentdomain.de but the mailserver location is my.currentdomain.de. That is a mismatch, so the check fails.
@DeBossNow said in PTR problem between Linode & Mastadon:
**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10This is irrelvant and has nothing to do with outgoping mail or the PTR check. I also doubt that it was set by Cloudron, more likely by Linode.
@DeBossNow said in PTR problem between Linode & Mastadon:
But i literally can not get this same value saved as a PTR record.
Why not? I suspect because you are trying to do it in the wrong place.
@DeBossNow said in PTR problem between Linode & Mastadon:
A/AAAA Record
Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxThat's fine, but you also need the PTR record to be set to this.
@DeBossNow said in PTR problem between Linode & Mastadon:
Cloudron PTR check says that it wants to find a DNS record that reads as
my.currentdomain.de IP Public xx.xx.xxx.xxx
But all Cloudron reports is finding my base domain name. currentdomain.de
The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxxNo, that is not how it works. There is only one PTR entry for the server.
@DeBossNow said in PTR problem between Linode & Mastadon:
but when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just as
my IP xx.xx.xxx.xxx
Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.That is correct and not the problem here.
What domain is set as the mailserver location in Cloudron on the mail settings page? If it is my.currentdomain.de change it to currentdomain.de.
-
OK, let's try one last time to get this resolved for you:
@DeBossNow said in PTR problem between Linode & Mastadon:
My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.deThis means that your server's PTR record is currentdomain.de but the mailserver location is my.currentdomain.de. That is a mismatch, so the check fails.
@DeBossNow said in PTR problem between Linode & Mastadon:
**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10This is irrelvant and has nothing to do with outgoping mail or the PTR check. I also doubt that it was set by Cloudron, more likely by Linode.
@DeBossNow said in PTR problem between Linode & Mastadon:
But i literally can not get this same value saved as a PTR record.
Why not? I suspect because you are trying to do it in the wrong place.
@DeBossNow said in PTR problem between Linode & Mastadon:
A/AAAA Record
Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxThat's fine, but you also need the PTR record to be set to this.
@DeBossNow said in PTR problem between Linode & Mastadon:
Cloudron PTR check says that it wants to find a DNS record that reads as
my.currentdomain.de IP Public xx.xx.xxx.xxx
But all Cloudron reports is finding my base domain name. currentdomain.de
The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxxNo, that is not how it works. There is only one PTR entry for the server.
@DeBossNow said in PTR problem between Linode & Mastadon:
but when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just as
my IP xx.xx.xxx.xxx
Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.That is correct and not the problem here.
What domain is set as the mailserver location in Cloudron on the mail settings page? If it is my.currentdomain.de change it to currentdomain.de.
@ccfu I had no MX record when I set up the new server at Linode yesterday.
After I chose to use the Default Cloudron smtp server THEN Cloudron asked for permission to go setup the MX Server.When I returned to the linode dashboard i saw the updates that Cloudron did. The MX Email server was set to the same address as the Default Cloudron Login Panel url for this domain.
Hence, the MX Server said ... my.currentdomain.de was the address for my Email server. I did not choose the my. prefix for this.
Nevertheless, I CHANGED THE MX server at Linode from "my.currentdomain.de" to the base domain url "mycurrentdomain.de" for my Mastadon installed website.
I waited now for 10 minutes, refreshing my Email status report every minute. PTR error still showed that it was expecting "my.curentdomain.de".But then I re-enabled the Cloudron email server to RECEIVE Emails at my domain instead of just being able to Send emails from his domain.
Then up popped this --
When I clicked the Enable button within a minute back at Linode Cloudron had RESET my MX Record to --
my.currentdomain.de This is the Cloudron Email setup default.
So, the PTR record error at cloudron persists
RESETTING the MX Record as you suggest does not get rid of this error.I CAN go back to Linode and OVERWRITE what the Cloudron Email (enabled Incoming email reception, too) MX Server has saved ... my.currentdomain.de .... but it seems like that will mess up this Incoming email service, since it is Cloudron that specified this.
