Outbound NAT for SMTP
Mail does go out from my exchange server using the default any to any rule and is received just fine.
Now, a number of major ISPs (Comcast, AOL, Yahoo) are not accepting my email.
The default WAN IP address is 188.8.131.52
Mail comes in on 184.108.40.206, a VIP
The MX record is for 220.127.116.11
I examined the header of an email I sent out that works and it is coming from the .98 address. So I thought that perhaps I should change the outbound mail to .99.
I setup an outbound NAT and chose automatic rule generation. Because the exchange server performs other duties, I also chose to specify SMTP.
NAT looks like this.
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port WAN exchange tcp/udp/* * tcp/udp/25 18.104.22.168 25 NO
No rule was created by this that I could move to above the current "Default allow LAN to any" rule. So I assume that I should choose manual rule creation?
If so, I get a little lost. Do I set the Gateway to be the VIP or is that the job of the NAT? The destination will be which ever SMTP server the mail needs to go to.
Your MX record has NOTHING to do with sending mail to another domain. MX is only used for someone to send mail to that domain. Your outgoing and incoming mail servers could be in completely different parts of the world, on completely different netblocks, etc..
As to why major players are not accepting mail from you, lots of different reasons. Is your IP listed as home IP, or dynamically assigned? Do you have a correctly responding PTR setup for your IP that is sending mail?
For example if I try and send mail to aol.com
554- (RTR:DU) http://postmaster.info.aol.com/errors/554rtrdu.html
554 Connecting IP: 24.13.x.x
now if you read that help they post, upon just making the connection
AOL uses the Spamhaus PBL to block mail from dynamic and residential IP addresses. Per our E-mail Guidelines, we do not accept mail from such addresses. If you believe your IP is listed in error, please contact your ISP directly and have them update their listing with the PBL. If…
your ISP reports that the IP is correctly listed in the PBL, and that you should be able to send mail from it, or
you were recently assigned IPs, have changed the rDNS on them, and allowed 48-72 hours for propagation time...and you are still getting the error, please open a support request.
I highly doubt you changing your source IP when sending to these domains from .98 to .99 is going to do anything. Do a simple telnet to aol mx servers on 25, do you get denied message like above?
I had checked for RBL listings yesterday, and again this AM and we are clear.
Thanks for the troubleshooting tip. The response was revealing.
421 4.7.1 : (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html
This is a very recent cutover from a T1 circuit to fiber. We got a brand new block of 16 as we held both lines active simultaneously. It was when the T1 circuit failed again, that we decided to go all in, move to the fiber and drop the T1 service altogether.
Is there any way that I can expedite getting this resolved. Mail is not being delivered, but isn't failing. Somewhere around 5 PM today, we will have gotten to the point where the message will have exceeded it TTL and Exchange will not attempt to deliver it anymore.
I know that Verizon is receiving it. AOL, Yahoo, Erols, Comcast all are not. Revealing, no?
I've contacted the ISP that provided the fiber and requested that they assign rDNS records for all of the ip addresses we are assigned, to: ourcompany.com.
Hope this gets us out of the woods. Does anyone know what the timing will be like on this one?
Yeah the major players are not going to accept mail from a IP without a valid PTR (rDNS). Need to get with your ISP to rush that along.
One thing I could think of to do to get your mail delivered until that is valid, is use a smarthost to deliver your mail. Once the PTR is up and working you can switch back to sending mail directly.
So is your IP returning "rDNS containing in-addr.arpa are not acceptable" or nothing at all? If they don't have any ptr's in place it might take them a bit longer, then just updating their already existing records.
If you don't have smarthost you can use, one thing you could do that would be very quick is fire up a VPS somewhere that the host allows you to update your own PTR. For example I have a $15 a year VPS running on http://buyvm.net/ for play and testing and I pointed a simple no-ip.info domain to its IP, and right from the control panel of the vps I could update the PTR for this IP and it was available in minutes.
Now as long as that IP is not on any blacklist you should be able to use it as a smarthost until your true connections rDNS is up and working. I snipped out the details of the IP and hostname for privacy concerns.
That site I listed had my vps up and running in couple of minutes once I placed my order. So I would think this is something you could have running in less than 30 minutes if you wanted to go that route.