Mail SMTP Relay - Reverse DNS Question
-
@Dashrender said:
Also, as for your Reverse DNS issue, can you have more than one PTR record on an IP? If you can great, but if not, you'll be forced to get a second IP address for the Artica.
If you had more than one PTR to an IP it would return results in round robin. Under what scenario would you want that to happen?
-
@scottalanmiller said:
@Dashrender said:
Also, as for your Reverse DNS issue, can you have more than one PTR record on an IP? If you can great, but if not, you'll be forced to get a second IP address for the Artica.
If you had more than one PTR to an IP it would return results in round robin. Under what scenario would you want that to happen?
I don't think you would - so because the OP wants to different domains here mail.domain.ca and mail-store1.domain.ca, he will be required to get a second IP to get what he wants - right?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Also, as for your Reverse DNS issue, can you have more than one PTR record on an IP? If you can great, but if not, you'll be forced to get a second IP address for the Artica.
If you had more than one PTR to an IP it would return results in round robin. Under what scenario would you want that to happen?
I don't think you would - so because the OP wants to different domains here mail.domain.ca and mail-store1.domain.ca, he will be required to get a second IP to get what he wants - right?
Yes, because when you do a PTR lookup, it would not know which one to return so you'd either have to pick one or have it return at random. Not sure which is worse
-
I easily missed something in the description, but why does he want to have two different domains at that IP address?
-
@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.
-
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.
-
@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.
-
@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)
