550 5.7.1 Cannot relay

I have an exchange 2007 sp1 running on windows 2008. I am currently having the following problem:
1. There is 1 domain that is giving me a delay error with 550.5.7.1. I can send emails both internally and externally with no problems except to this 1 email domain.
2. The email eventually gets sent after a some hours.
3. I tried to telnet to the user and recieved the 550 error as well. However, whenever i try to send email to anybody using telnet it gives me the 550 error.

Any ideas? mx and ptr records are all correct and I am not grey or blacklisted.
jerrywalk1Asked:
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.

BAYCCSMSPCommented:
Have you tried sending an email from a free service like gmail or hotmail to this domain to see if the connection goes through?
0
jerrywalk1Author Commented:
Yes. They work fine.
0
jerrywalk1Author Commented:
Anybody?
0
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

jerrywalk1Author Commented:
I am still randomly having this problem. Right now it is just with 1 domain. I am getting the following. We changed IP addresses but all of our DNS is correct and checks out fine with our ptr record as well. Anys suggestions?

Diagnostic information for administrators:

Generating server: LEDA.FDS.ORG

user@specjan.com
mail.axcesspc.com #501 5.7.1 <user@fds.org>... Sender IP must resolve ##

Original message headers:

Received: from LEDA.FDS.ORG ([::1]) by LEDA.FDS.ORG ([::1]) with mapi; Thu, 16
 May 2013 19:42:49 -0400
From:User <user@fds.org>
To: "user@specjan.com" <user@specjan.com>
Date: Thu, 16 May 2013 19:42:47 -0400
Subject: testing for theresa
Thread-Topic: testing for theresa
Thread-Index: Ac5SjxAFewutnf2DTHSefu4tlicnmA==
Message-ID: <72B3B9E74A8BE34587AE380958FB1E6B518EB7D0@LEDA.FDS.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19872.002
x-tm-as-result: No--39.546300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative;
      boundary="_000_72B3B9E74A8BE34587AE380958FB1E6B518EB7D0LEDAFDSORG_"
MIME-Version: 1.0
0
Ryan McCauleyEnterprise Analytics ManagerCommented:
We had this problem with our mail server as well - in our case, it was a result of the public IP address of the server not resolving to the DNS address provided in the HELO/EHLO handshake. This should show you how to change the DNS name your server is providing to the remote SMTP server:

http://smtp25.blogspot.com/2007/08/change-fqdn-name-on-ehlohelo.html

It's spam protection, and only some servers take this step, but the remote server is doing a public reverse DNS lookup on your IP and it has to match the DNS name you're providing. If they don't match, the remote server sees you as a potential spoofer and refuses to accept the mail. This prevents another mail server, from a different IP address, from claiming to be mail.yourdomain.com, as the reverse DNS won't match.

This wouldn't explain why it's spontaneously delivered a few hours later - ours were never delivered and the 5.7.1 response terminated the connection. Maybe they have multiple servers in a load balance and some are configured to do reverse DNS lookup and some aren't, and you just have to wait until you happen to round-robin to one that doesn't care?
0

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
Craig BeckCommented:
It's an issue with the recipient's mail server.

The "Unable to relay" message usually appears when the receiving SMTP server is trying to deliver a mail to a domain it's not authoritative for.  If that's the case then it can't be your fault.
0
Scott KunauSr. Consultant/Managing PartnerCommented:
I would agree with craigbeck...the problem appears to be the recipient's mail server.  Have you tried to email into their server with a gmail account or some other account not related to your i-domain/email system?  If so what are the results?

Since the email eventually gets to the destination, there could be a problem with the target server itself simply not able to handle the volume.  Therefore SMTP traffic is delayed and deferred and can possibly take up to 4 days to reach the destination (default on some systems I work on).
0
Ryan McCauleyEnterprise Analytics ManagerCommented:
When I've seen 5.7.1 in the past, it's usually been in the context of mail relay - in this case, the OP has posted the whole message and it looks like it's a pretty common configuration problem. Searching for "5.7.1 Sender IP Must Resolve" returns many people who have the same issue, and it sounds like the reverse DNS lookup problem that I've had previously, and I discussed above.

It's misleading, but the "Unable to relay" message is "550 5.7.1" and this message is "501 5.7.1", so the error code is subtly different.
0
jerrywalk1Author Commented:
@ryanmccauly all of our DNS and ptr records are correct. They all resolve fine. When you do a test using mxtoolbox all of it comes back fine with everything pointing back to the correct ip address and dns.

@zenandemailguy and @craigbeck What i have found is that when I telnet into AOL from my server it acts as though it does not see the correct DNS. I telnet into others and run it fine. It is as though the DNS never updated on AOL side.
0
Craig BeckCommented:
So its fair to say the AOL DNS resolution isn't working properly.

Also, do you use an SPF record?  AOL use SPF verification.
0
Ryan McCauleyEnterprise Analytics ManagerCommented:
It looks like checking for banner mismatch is part of the mxtoolbox suite of tests, so it should have thrown an error if this was incorrect. I'm not sure how this would work, but is it possible Exchange is providing a different banner when sending (when you see this error) than it is when receiving (what it's doing when mxtoolbox checks your server)? I don't doubt your MX and the reverse DNS on your domain is set up properly, but what exchange reports as its DNS banner doesn't have to be your domain - it can be anything at all - and that configurable free-form field is what's causing the issue.

Is it possible to get a copy of the conversation with this one remote mail server that's causing you issues? That should show the EHLO, response, and then the 501 5.7.1 as the remote server refuses to accept the mail because of (what the error code says is) a banner mismatch.
0
Ryan McCauleyEnterprise Analytics ManagerCommented:
Though I'd admit that I'm a bit out of my element, it looks like a bad (or misconfigured) SPF record leads to:

550 5.7.1 SPF unauthorized mail is prohibited

Rather than the message he's seeing. It's likely either a reverse-dns problem at AOL with your IP address or a banner issue.
0
Craig BeckCommented:
@ryanmccauley - agreed, it's unlikely to be a SPF issue, however the sender's DNS zone is checked for the presence of an SPF record by AOL.  If one doesn't exist within the zone or the SPF record doesn't specify the sending mail server, the error you noted is displayed.  If the sender's domain can't be resolved by the receiving server this message won't ever be displayed as the SPF record can't be queried.

That goes back to DNS resolution on the AOL side.

I've just tested the domain mentioned in post 39176378 and its rDNS entry at MXToolbox - everything is fine.  So, again, it looks like an AOL issue.
0
jerrywalk1Author Commented:
We dont have an SPF at all. The only thing that changed was the public IP as we changed vendors. Everything was updated correctly as far as DNS and ptr records. We didnt have to change any of our FQDN as this did not change. Again...its looking like the DNS didnt not update on AOL side. We have 3 other domains having this same problem. It is not widespread at all. Comcast is the other one having the same issue. I am checking with AOL now...rather i have my ISP checking it with them. Let's see what happens.
0
Brian BEE Topic Advisor, Independant Technology ProfessionalCommented:
I would confirm with your service provider that your rDNS record is correct. Some mail server confirm against this to make sure your email server is actually who you say you are.

When I have seen this in the past, I was usually able to fix it by routing outbound mail through the service provider's smart host.

Worst case, speak to the operators at the recipient domain and get them to whitelist you.
0
SteveCommented:
the error you are getting is definately rDNS related.

> set type=mx
> fds.org

Non-authoritative answer:
fds.org MX preference = 10, mail exchanger = leda.fds.org

leda.fds.org    internet address = 209.19.116.247
> set type=ptr
> 209.19.116.247

Non-authoritative answer:
247.116.19.209.in-addr.arpa     name = leda.fds.org
>

Open in new window


I have checked your DNS & rDNS and it does appear to be right so the logical explanation is to check your IP is correct when sending.
I recommend checking the external IP your server is using to make sure it matches up.

try http://www.whatsmyip.org/ to confirm your IP is listed as
0
jerrywalk1Author Commented:
Ok So i figured it out. The ISP is using 2 different IPs. 1 is for email and 1 is for my firewall. Email going out on my firewall has a different IP than email that is coming in. So we had to do a ptr record for the outgoing email. ONce we created that it all worked. Weird earthlink set up with MPLS.
0
jerrywalk1Author Commented:
Thanks all. Your feedback helped me to track down the issue.
0
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.