PTR problem between Linode & Mastadon

[ccfu]

@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

[scooke]

Have you apologized for your false and wild slanderous accusations in the other thread yet? And here you are, still demanding help, being obstinate, argumentative. You should make things right.

[DeBossNow]

@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.

[BrutalBirdie]

@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.

[scooke]

@DeBossNow Leave Linode. Why hit your head against a wall you know is there???

And apologize.

[DeBossNow]

@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]

@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]

@DeBossNow

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?

[scooke]

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!

[DeBossNow]

@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 10

But 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.xx

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.xxx

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.

The Edit function after the fact does not make any difference either.

[BrutalBirdie]

@DeBossNow
The PTR record can not be set in the same web interface as the normal DNS settings for MX A AAAA TXT @ 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-dns

And still, please share your real domain so I can validate the DNS settings, this could save us all so much time and pain.

[ccfu]

@DeBossNow

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.de

This 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 10

This 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.xx

That'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.xxx

No, 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.

[DeBossNow]

@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.

[DeBossNow]

@DeBossNow said in PTR problem between Linode & Mastadon:

I mistyped this ... I changed the MX Server at linode to the base domain "currentdomain.de"

Nevertheless, I CHANGED THE MX server at Linode from "my.currentdomain.de" to the base domain url "mycurrentdomain.de" for my Mastadon installed website.

[ccfu]

@DeBossNow

Please ignore the MX record. As I have written several times now, this has absolutely nothing to do with the PTR check which only concerns outgoing email.

Once again: Go to the email settings page in your Cloudron dashboard and check the domain that is entered as the mailserver location:

[DeBossNow]

@ccfu I have CHANGED the Email Server domain that Cloudron set when I enabled Incoming Email reception.
I changed it Back to my base domain, removing the my prefix.
And then I Reset the DNS to update my Linode server.
At first the only error was an SPF but it resolved a few minutes later.

I have Green Lights again.
Thank you for your help.

I am trying to resolve the communication frustration, though. I went through all the standard steps of Install.
Setting the Email server to enable Incoming email at my domain DID set the MX server at Linode to use "my.currentdomain.de" I never chose this prefix and never entered it either at my Linode server configuration or in my Cloudron panel.

Several times the responses I have gotten was that I must have made up this configuration. I also read several times in our communications that it "has nothing to do with your MX Server", yet also saying that it was the COMPARISON between the mismatching MX Server value and the base url. So, both things can not be true. The PTR errror DID have everything to do with the MX Server value.

In our communications I made it clear that for me to change or modify the MX Server value I was going to my Linode Server account dashboard. Especially with the caveat that the PTR value had to be set at my Linode account.

Yet, you were evidently referring to going to the Cloudron dashboard and

1. to go first to the right side Admin panel to bring up Email Settings and then
2. click on Mail server location and the checkbox pencil.
3. Make the change there in the Edit function ... removing my. and saving there.
4. And then I had to go back out of the Owner admin window and
5. to the other Cloudron Email Configuration Status control and hit REDO DNS SETUP.

So now I know by trial and error that to fix the PTR error I reported that I must REJECT the default Cloudron setup which installed the MX Server setting at my Linodes volume with a prefix my.

That I must go through the above steps in my Cloudron Admin panel to finally fix the error.

RESOLVED. Thank you for putting up with all of this!

[ccfu]

@DeBossNow

I am glad you got it resolved, but just to clarify:

The MX record is for incoming email. It needs to be set to any domain name that resolves to your server, i.e. has a valid A record. If both my.currentdoain.de and currentdomain.de resolve then you can use either for incoming mail. The mismatch was not with the MX record but between the mailserver domain set in Cloudron and the PTR record of the server. At no point did I or anyone else tell you to change the MX record, and no, the PTR error had nothing to with the MX record. I can therefore only assume that you interpreted MX as being something it is not.

For outgoing mail you need a valid PTR record that matches the mailserver domain. You also need a valid SPF record and a valid DKIM entry.

Because you set up Cloudron via the Linode app you have presumably told Cloudron to use Linode DNS, which is why it is updating / overriding certain settings. If you do not want it to do that you need to set DNS to manual for the resepctive domain(s).

The bottom line is: The PTR record and mailserver domain have to match. Where you make the changes depends solely on the domain you want to use for email, i.e. where the entry needed updating to match.

Btw, I stated every time that you needed to check / update the mail domain in Cloudron, not in the Linode dashboard.