Solved

550 5.7.1 Cannot relay

Posted on 2012-03-16
20
574 Views
Last Modified: 2013-05-24
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.
0
Comment
Question by:jerrywalk1
  • 7
  • 4
  • 3
  • +4
20 Comments
 
LVL 5

Expert Comment

by:BAYCCS
Comment Utility
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
 

Author Comment

by:jerrywalk1
Comment Utility
Yes. They work fine.
0
 

Author Comment

by:jerrywalk1
Comment Utility
Anybody?
0
 

Author Comment

by:jerrywalk1
Comment Utility
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
 
LVL 28

Accepted Solution

by:
Ryan McCauley earned 167 total points
Comment Utility
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
 
LVL 45

Expert Comment

by:Craig Beck
Comment Utility
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
 
LVL 18

Expert Comment

by:ZENandEmailguy
Comment Utility
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
 
LVL 28

Expert Comment

by:Ryan McCauley
Comment Utility
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
 

Author Comment

by:jerrywalk1
Comment Utility
@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
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 45

Expert Comment

by:Craig Beck
Comment Utility
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
 
LVL 28

Expert Comment

by:Ryan McCauley
Comment Utility
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
 
LVL 28

Expert Comment

by:Ryan McCauley
Comment Utility
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
 
LVL 45

Expert Comment

by:Craig Beck
Comment Utility
@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
 

Author Comment

by:jerrywalk1
Comment Utility
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
 
LVL 23

Assisted Solution

by:Brian B
Brian B earned 167 total points
Comment Utility
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
 
LVL 27

Assisted Solution

by:Steve
Steve earned 166 total points
Comment Utility
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
 

Author Comment

by:jerrywalk1
Comment Utility
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
 

Author Closing Comment

by:jerrywalk1
Comment Utility
Thanks all. Your feedback helped me to track down the issue.
0

Featured Post

Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

Join & Write a Comment

OfficeMate Freezes on login or does not load after login credentials are input.
Marketers need statistics and metrics like everybody else needs oxygen. In this article we explain how to enable marketing campaign statistics for Microsoft Exchange mail.
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
This video discusses moving either the default database or any database to a new volume.

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now