Exchange possibly forged hostname IP address

I have one customer that we cannot send emails to. I get the 451 4.1.8 Possibly forged hostname for **.**.***.130 error. Here is the problem, I have no idea why it is getting the ip address it is getting. I have internal DNS set correctly. I have external DNS setup, all of my ptr, a records, spf, etc. are all setup and correct. For some reason though this email is getting the IP address of my VPN. My email is **.**.***.134 and my VPN is **.**.***.130. There is nothing that points my VPN to my email.

But when a user tries to send to this one email address it returns this error. Like I said I have checked internal DNS, I have checked my external DNS, I have checked my firewall, etc. I am not sure where else to look. I am not even sure this is on my end.

Any suggestions?
JenniferIT DirectorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

JenniferIT DirectorAuthor Commented:
I ran a helo test using helocheck. This is what I get back...
rsync.spamhaus.org gave this error:
*** The HELO for IP address **.**.***.130 was 'mail.skywalker.com' (valid syntax) ***

Why is it using ip *.130, I can't find it?
JenniferIT DirectorAuthor Commented:
Another note, it seems to be any @sbcglobal.net email address. Another user just tried to send an email to that domain and the same thing happened.
Bruno PACIIT ConsultantCommented:
Hi,

I supposed that your Exchange server is not directly on the Internet, right ?

So between Internet and your Exchange server there's at least a router, or most probably some firewall.

The IP address that is mentioned in the error message is the IP address seen by the remote server of the recipient SMTP domain. This IP is then the public IP address that the firewall (or routeur) used to let the SMTP traffic get out.
This is probably a matter of firewall configuration and not an Exchange problem.

When you talk about *.134 IP I presume you talk about le IP address that is declared in the MX external record that permits you to receive emails !? Your problem is about outgoing emails so it's differents things.
Your firewall configuration is done so that outgoing SMTP traffic is emitted from *.130 IP address. It's probably some Static NAT rule that is missing or misconfigured in your firewall.

The remote SMTP server is just doing some checking to compare the external public IP address associated to the DNS name your Exchange server shows in the HELO command (this external IP address is obtained from external DNS servers) with the IP address from which the SMTP traffic comes from.
As the external DNS server says that the DNS of your server is resolve as *.134 and as the incoming SMTP traffic comes from *.130 the remote SMTP server thinks it's a forged spam email.

You have 2 paths of resolution :

1) Change your firewall configuration so that SMTP traffic from your Exchange server goes out using the *.134 IP address.
2) Or modify the external DNS records for your Exchange server DNS name to associate it with the *.130 IP address, but you may also have to modify the MX record for your smtp domain so that incoming emails still arrive on *.134.

Have a good day
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

JenniferIT DirectorAuthor Commented:
I don't see anything in my firewall that would be causing these emails to look at 130 instead of 134

My nat rule for smtp is inside/outside 24/any 134/original (smaller number is my internal ip) and then
outside/inside any/134 original/24

My mail server and ip also have http and https nat rules. Then my three websites have http and https nat rules, they are 34/131, 35/133, 38/132

My smtp public server is 24/134, then my https are 24/134, 34/131, 35/133, 38/132

no 130 net objects

my outside gateway is 129

my Ethernet outside is 130

my site to sites are not using any of these

My external DNS has mail.*.com as 134, yes my MX has 134, my spf has 134, the only 130 I have on my external is vpn.*.com

Why is it only sbcglobal.net that is trying to use this 130?
JenniferIT DirectorAuthor Commented:
Any why now, I have had this exact setup for over a year.
jrhelgesonCommented:
From your exchange server, browse to cmyip.com (or whatismyip.com or similar) and see what your outbound traffic is being NATed out as.

Your issue is that inbound NAT rules follow from .134 inbound to your email server, but it is only a 1-way NAT rule.  Outbound traffic from your mail server is going out through .130 along with all your other outbound traffic.

Why this would become an issue now?  Chances are the spam filtering of your client is now checking the reverse DNS/SPF/whatever records and you've now risen to the level where outbound is being  blocked.

The solution is to
1) Make your Exchange NAT rule a 2-way NAT rule, so both inbound and outbound traffic use .134.
and/or
2) Have your ISP create a reverse DNS entry for .130 that also resolves to mail.domain.com
3) Update your PTR/SPF records to include the .130 address.

Also, What firewall are you using? I might be able to help with commands.
JenniferIT DirectorAuthor Commented:
I have nat rules...

inside/outside - 24/any - 134/original
outside/inside - any/134 - original/24

If I do a DNS lookup for my domain I get the following.
Results found: 2

Domain Type Class TTL Response Time Answer

Answer section:      
skywalker.com. MX IN 3600 33ms mail.skywalker.com. [Preference = 10]
Additional section:      
mail.skywalker.com. A IN 1800 33ms 71.14.224.134

Neither 130 nor 134 are on a block list.

My firewall is a Cisco ASA5510
jrhelgesonCommented:
Could you try the suggestions in my previous post?  Browse out to see what your IP address is?

For the Cisco configuration - I'd also need to know what version of software you're using. Cisco changed things quite a bit.  What version of firmware is running on the firewall, and what version of ASDM are you using?
Bruno PACIIT ConsultantCommented:
Hi,

It seems like you listened to jrhelgeson and it's a good thing. I can see your SPF record is containing both IP addresses .134 and .130 :

skywalker.com      text = "v=spf1 ip4:71.14.224.134 ip4:71.14.224.130 mx ~all"

This should permit you to send emails from .134 or .130 to target domains that make SPF checking.

But I can not find any matching reverse DNS record for your IP:

134.224.14.71.in-addr.arpa      name = 71-14-224-134.static.stls.mo.charter.com
130.224.14.71.in-addr.arpa      name = 71-14-224-130.static.stls.mo.charter.com

As you can see just above, the PTR DND records for your IP addresses are returning DNS names that do not match with the DNS names of your SMTP server !
Any SMTP domain that do some reverse DNS antispam checking may refuse your emails.

jrhelgeson proposed good things to do but you have to do it all :)

Have a good day
JenniferIT DirectorAuthor Commented:
I have already done everything that jrhelgeson said. I had all of it except the SPF record done before he mentioned. The reverse DNS is coming back with my fiber providers IP address. The IP addresses I have supplied here are the IP addresses provided to me by my fiber provider. I do not know why they are coming up or when it changed. As I said before this setup has been in place without problem for over a year.
JenniferIT DirectorAuthor Commented:
There were messages still stuck this morning, just for sbcglobal.net. I suspended then resumed, then restarted the queue. All is working as of now.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JenniferIT DirectorAuthor Commented:
The SPF update helped. The Reverse DNS going back to my fiber provider helped. But otherwise I figured it out on my own.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.