PTR problem between Linode & Mastadon
-
@jdaviescoates Yes, I have read this. Thank you.
But it resolves to just saving the prefix my even when I enter my.currentdomain.de
It seems that my Cloudron function, the actual value it is checking for, would have to be changed in the script itself to remove the PTR error. It is looking for a literal my.currentdomain.de string and can not resolve simply seeing a my by itself.
@DeBossNow
Cloudron can not set a PTR/rDNS record since its on the provider / server side.You can check your PTR record manually with the following command:
dig -x YOUR_SERVER_IP_GOES_HERE +shortYou can also optionally add a DNS Server to check against with e.g.
@1.1.1.1
Example:dig -x YOUR_SERVER_IP_GOES_HERE +short @1.1.1.1If you have in https://my.YOUR.DOMAIN/#/email =>
Mail server location my.YOUR.DOMAINthen thediglookup should return exactly that.
If not, set the value correctly in your provider panel. -
@DeBossNow
Cloudron can not set a PTR/rDNS record since its on the provider / server side.You can check your PTR record manually with the following command:
dig -x YOUR_SERVER_IP_GOES_HERE +shortYou can also optionally add a DNS Server to check against with e.g.
@1.1.1.1
Example:dig -x YOUR_SERVER_IP_GOES_HERE +short @1.1.1.1If you have in https://my.YOUR.DOMAIN/#/email =>
Mail server location my.YOUR.DOMAINthen thediglookup should return exactly that.
If not, set the value correctly in your provider panel.@BrutalBirdie Thank you.
But, as I have written -- I showed and described what I can do on my server side. I KNOW that the PTR is set on my server side.But, as I wrote --- the Linode UI tools for the A/AAAA adminstration will write that value as -- my
NOT my.currentdomain.deAnd this apparently works fine for thousands and thousands of sites set up for hundreds of thousands of Linode users with all kinds of apps.
Only Cloudron, that I have run across, demands to see this record as -- my.currentdomain.de
The setup which it only does once -- in the MX record -- but NOT in the records the Cloudron PTR check is looking for -- in the A/AAAA records.Cloudron PTR check is the anomoly here unless someone has ACTUAL EXPERIENCE WITH LINODE and found a work around.
-
@BrutalBirdie Thank you.
But, as I have written -- I showed and described what I can do on my server side. I KNOW that the PTR is set on my server side.But, as I wrote --- the Linode UI tools for the A/AAAA adminstration will write that value as -- my
NOT my.currentdomain.deAnd this apparently works fine for thousands and thousands of sites set up for hundreds of thousands of Linode users with all kinds of apps.
Only Cloudron, that I have run across, demands to see this record as -- my.currentdomain.de
The setup which it only does once -- in the MX record -- but NOT in the records the Cloudron PTR check is looking for -- in the A/AAAA records.Cloudron PTR check is the anomoly here unless someone has ACTUAL EXPERIENCE WITH LINODE and found a work around.
@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 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.
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.
-
@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!
