PTR problem between Linode & Mastadon
-
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!
-
@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 forMX
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-dnsAnd still, please share your real domain so I can validate the DNS settings, this could save us all so much time and pain.
-
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.
-
@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.
-
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:
-
@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
- to go first to the right side Admin panel to bring up Email Settings and then
- click on Mail server location and the checkbox pencil.
- Make the change there in the Edit function ... removing my. and saving there.
- And then I had to go back out of the Owner admin window and
- 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!
-
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.
-
-