Mail SMTP Relay - Reverse DNS Question
-
@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.
-
@Dashrender tons of people can send from home on port 25. It's very common.
-
@scottalanmiller I realized that once I wrote it.. and hence deleted it
-
@scottalanmiller
I'll send through Mandrill, just cause thats what I've always done. Always being like...slightly over a year -
In that case any issue would be from MailChimp, right?
-
@scottalanmiller said:
@Dashrender tons of people can send from home on port 25. It's very common.
Actually, no it is not. Many providers have blocked outbound port 25 for years on their residential services. AT&T implemented the block in like 2004 or 2005.
-
@Sparkum PTR should never be a problem. If you setup an SPF record allowing your IP, assuming you have a static IP, that should handle it.
But if I followed all this right, the entire thing is moot as you are wanting all mail delivered to your holding service and then it will send it on to your house?
That should mean nothing needs to be involved with sending because the mail relay/holder should just be trusted by your local mail server and sending it directly.
-
@JaredBusch said:
@scottalanmiller said:
@Dashrender tons of people can send from home on port 25. It's very common.
Actually, no it is not. Many providers have blocked outbound port 25 for years on their residential services. AT&T implemented the block in like 2004 or 2005.
Many providers have blocked, but many have not. While it is not surprising to be blocked, it is not surprising at all to not be blocked.
-
@scottalanmiller said:
@JaredBusch said:
@scottalanmiller said:
@Dashrender tons of people can send from home on port 25. It's very common.
Actually, no it is not. Many providers have blocked outbound port 25 for years on their residential services. AT&T implemented the block in like 2004 or 2005.
Many providers have blocked, but many have not. While it is not surprising to be blocked, it is not surprising at all to not be blocked.
Only provider I can think of off the top of my head would be Frontier, on their original network. Not the ones they bought up recently, because their networks are still integrated into the rest of the original ones. And I'm not even sure on that, as I don't touch Frontier home circuits often.
Every cable provider from Comcast down to Mediacom block 25. AT&T and Verizon did it years ago. Hell, CenturyLink and Windstream do it. If you got an ISP that opens 25 outbound to the world, it's a very, very, very small minority.
-
I'm on a random cheap connection down here in Texas. Just tested here at the condo and port 25 is definitely open: Xfinity
