Mail SMTP Relay - Reverse DNS Question
-
@Dashrender said:
From what I gather, the OP has a VM server running hosted in a DC. That VM server is running both his email server and his Artica server. Both of those are behind his firewall sharing the same outgoing IP.
And both of those solutions require a unique PTR record? Why?
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
I easily missed something in the description, but why does he want to have two different domains at that IP address?
Because he only has one IP from his host provider.
Well that explains why he only has one IP. But the question was why he wants it to identify as two different domains in a PTR record.
Because he wants a backup host to accept his email when his email server is offline.
of course, this only works assuming the ISP/DC/VM host are all still running. Once any of those die, the whole box is down, and your email appears down from the outside.
Oh.. and this is a learning thing.. not really production - stated in OP.
-
@Dashrender said:
Because he wants a backup host to accept his email when his email server is offline.
I continue to not understand. How does this relate to the issue at hand? PTRs have nothing to do with receiving emails.
-
PTRs are used to reduce other people seeing you as a spammer. So your PTR record needs to be set. You only need it for sending email. MX records are for receiving email.
Emails coming to this IP address have already arrived once they hit the outside and the PTR record, and DNS altogether, is already past the point of being used. Receiving emails are unaffected by any PTR settings anywhere.
-
@scottalanmiller said:
@Dashrender said:
Because he wants a backup host to accept his email when his email server is offline.
I continue to not understand. How does this relate to the issue at hand? PTRs have nothing to do with receiving emails.
His Artica box was trying to forward email that was sitting on it to his real email server and was failing due to a rDNS failure.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Because he wants a backup host to accept his email when his email server is offline.
I continue to not understand. How does this relate to the issue at hand? PTRs have nothing to do with receiving emails.
His Artica box was trying to forward email that was sitting on it to his real email server and was failing due to a rDNS failure.
That's fine. So set the PTR record. All outgoing email would be the same PTR. Why would you want it to change. None of this is getting me any closer to understanding why a single PTR record doesn't do the job equally well. Outgoing email will always come from the same system, so only one PTR is needed, right? What's the function of the second PTR?
-
If I have a network with a dozen outgoing SMTP servers all sending out, you don't go get more IP addresses or do weird PTR things. You just set the PTR and you are done.
-
@Sparkum said:
NOQUEUE: reject: RCPT from mail.example.ca[EXAMPLE IP]: 451 4.3.5 : Helo command rejected: Server configuration error; from= to= proto=ESMTP helo=
Which box are you seeing this error on? The Artica or your email server?
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Because he wants a backup host to accept his email when his email server is offline.
I continue to not understand. How does this relate to the issue at hand? PTRs have nothing to do with receiving emails.
His Artica box was trying to forward email that was sitting on it to his real email server and was failing due to a rDNS failure.
That's fine. So set the PTR record. All outgoing email would be the same PTR. Why would you want it to change. None of this is getting me any closer to understanding why a single PTR record doesn't do the job equally well. Outgoing email will always come from the same system, so only one PTR is needed, right? What's the function of the second PTR?
because his relay box is trying to act like a sender of his own domain, oddly enough, to his own domain.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Because he wants a backup host to accept his email when his email server is offline.
I continue to not understand. How does this relate to the issue at hand? PTRs have nothing to do with receiving emails.
His Artica box was trying to forward email that was sitting on it to his real email server and was failing due to a rDNS failure.
That's fine. So set the PTR record. All outgoing email would be the same PTR. Why would you want it to change. None of this is getting me any closer to understanding why a single PTR record doesn't do the job equally well. Outgoing email will always come from the same system, so only one PTR is needed, right? What's the function of the second PTR?
because his relay box is trying to act like a sender of his own domain, oddly enough, to his own domain.
Right... so clearly no overlap.
Just one PTR record it is. Domain isn't connected to the PTR record. You only get one PTR for hosts handling thousands of domains. You can't possibly have one IP per domain hosted on a server! -
We could continue this digging deeper and deeper or we could just assume that the idea that more than one IP and/or PTR is unnecessary because no one anywhere needs that and that the idea is just a mistake. One PTR and all is fixed.
-
For example, when NTG ran business email hosting we had more than thirty of our own domains on the server plus the domains for all of our customers. All behind a single IP address for sending. One IP, one PTR. That there are multiple domains is not a factor. Not for sending or for receiving.
For sending, there is one PTR per IP. For receiving there is one MX per domain.
-
Right.
So let's look at it like this.
Inside his network he has
email server - 10.0.0.100
Artica server - 10.0.0.105His external IP is 145.25.25.15
PTR on 145.25.25.15 for mail.domain.caemail comes in and ends up on the Artica server. When the Artica server tries to deliver it to the email server, the email server will as what the Artica's name is, it claims it's mail.domain.ca. When the email server does an rDNS lookup, it gets the IP of 145.25.25.15 (or nothing) and rejects the message because the IP does not match the 10.0.0.105 that the Artica is coming from (remember the Artica is local to the email server, same network)
-
@scottalanmiller said:
For sending, there is one PTR per IP. For receiving there is one MX per domain.
Is this because the sending email server always said it was the same email server regardless of what domain it was delivering for? let's assume one of the domains was acme.com, and the server was setup as mail.acme.com. Would the ELLO responses always be mail.acme.com even if sending emails for NTG.co?
-
Oh, so the issue is that the Artica does NOT have the same IP address. We have two IP addresses here, not one. And the issue is that the PTR for the Artica IP has not been set. Just set that, then. Like I said, one PTR for each IP.
Who is the ISP for the 10.x.x.x domain? He is, of course. Because that's not a routable range.
The information that has been wrong all this time, then, is that there are two IP addresses to send out on, one public and one private. All IPs need a PTR.
-
@Dashrender said:
@scottalanmiller said:
For sending, there is one PTR per IP. For receiving there is one MX per domain.
Is this because the sending email server always said it was the same email server regardless of what domain it was delivering for? let's assume one of the domains was acme.com, and the server was setup as mail.acme.com. Would the ELLO responses always be mail.acme.com even if sending emails for NTG.co?
Correct. Same as happens with Office 365, GMail, or anyone.
-
@scottalanmiller said:
Oh, so the issue is that the Artica does NOT have the same IP address. We have two IP addresses here, not one. And the issue is that the PTR for the Artica IP has not been set. Just set that, then. Like I said, one PTR for each IP.
Who is the ISP for the 10.x.x.x domain? He is, of course. Because that's not a routable range.
The information that has been wrong all this time, then, is that there are two IP addresses to send out on, one public and one private. All IPs need a PTR.
Ok, so assuming he's running his own DNS servers, he can setup a PTR record for the Artica and the problem should go away?
-
@Dashrender said:
Ok, so assuming he's running his own DNS servers, he can setup a PTR record for the Artica and the problem should go away?
Yup. Or, of course, he could just tell his email server to whitelist that IP, or to not use PTR records for SPAM detection. Lots of options.
But one of the basic tasks for setting up any email server is setting the PTR record. So when the Artica gets set up and runs purely internally, it would get one on the internal DNS server.
If he was using Windows DNS, I believe that the PTR is made by default. If not, it is as simple as a checkbox.
-
Hey.
Sorry late to the game on a couple replies here.
Alright so.
Yes, there is currently two IP's
Nothing is internal, all external
mail is on windows
relay in on DebianMy OVERALL point to this is to bring my mail into my house (which blocks port 25) so the relay will receive on 25 and sent to myself on 26. (dnsexit.com does but but I didnt wanna pay)
I found where to set the reverse DNS (Truly is that easy) and I actually already had it set, just doesn't seem like its listening to it, so ya...just need to resolve this 2 second issue tonight and I should be golden.
-
@Sparkum said:
Hey.
Sorry late to the game on a couple replies here.
Alright so.
Yes, there is currently two IP's
Nothing is internal, all external
mail is on windows
relay in on DebianMy OVERALL point to this is to bring my mail into my house (which blocks port 25) so the relay will receive on 25 and sent to myself on 26. (dnsexit.com does but but I didnt wanna pay)
I found where to set the reverse DNS (Truly is that easy) and I actually already had it set, just doesn't seem like its listening to it, so ya...just need to resolve this 2 second issue tonight and I should be golden.
So once the email is in your house.... you will be sending OUT through the public IP address (you should use a high port number, not 26.) Then you need the PTR record on the public IP from your ISP.
