Darkpaw
asked on
Exchange 2010 - unable to relay (error 550 - 5.7.1) from Linux systems
After migrating from Exchange 2003 to Exchange 2010, we found anonymous relaying to be blocked by default. This impacts Linux systems that aren't authenticating to Active Directory. After some digging, I found that you needed to make a receive connector in the hub transport, and enable anonymous authentication for that. This worked, until the IP address of one of the systems (Linux, not Exchange) changed. Now I am getting:
user@remotedomain.com
SMTP error from remote mail server after RCPT TO:<user@remotedomain.com> :
host mail.localdomain.com [10.100.50.241]: 550 5.7.1 Unable to relay
(hostnames changed in the message shown here - mail.localdomain.com is my hub transport server for Exchange, and user@remotedomain.com is the destination email address)
I checked the receive connector in "Server Configuration / Hub Transport" and it is updated to the correct new IP and has anonymous authentication, bound to port 25.
I also checked "Organization Configuration / Hub Transport / Global Settings / Transport Settings / Message Delivery" and the IP of the Linux system is in the allowed mail server list.
What am I missing?
This is running Exchange 2010 SP1.
user@remotedomain.com
SMTP error from remote mail server after RCPT TO:<user@remotedomain.com>
host mail.localdomain.com [10.100.50.241]: 550 5.7.1 Unable to relay
(hostnames changed in the message shown here - mail.localdomain.com is my hub transport server for Exchange, and user@remotedomain.com is the destination email address)
I checked the receive connector in "Server Configuration / Hub Transport" and it is updated to the correct new IP and has anonymous authentication, bound to port 25.
I also checked "Organization Configuration / Hub Transport / Global Settings / Transport Settings / Message Delivery" and the IP of the Linux system is in the allowed mail server list.
What am I missing?
This is running Exchange 2010 SP1.
ASKER
It isn't even making it to the edge server (which is a different server than the hub transport). It's not leaving the hub transport.
Only thing that sticks out is that I needed to add the IP to the Transport Settings / Message Delivery, as it was a new IP. Does a service need to be bounced to pick up a change to that setting?
Only thing that sticks out is that I needed to add the IP to the Transport Settings / Message Delivery, as it was a new IP. Does a service need to be bounced to pick up a change to that setting?
is this a linux computer or server and is it on your network? It never hurts to reboot the server after a change to the config, I would always do it after work hours
ASKER
It's a linux server that's trying to send the outbound messages. I can't see how rebooting that would matter, as it's communicating with the Exchange server.
I'm not rebooting the Exchange server to troubleshoot this....in the worst case it should be an individual service that needs to be bounced to pick up a change.
I'm not rebooting the Exchange server to troubleshoot this....in the worst case it should be an individual service that needs to be bounced to pick up a change.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start a Telnet session on the Linux box and type in the following: (each line ends with the ENTER key)
telnet cas.domain.local smtp
mail from:anyone@domain.local
rcpt to:anyone@domain.local (if checking internally) or
rcpt to:anyone@external.domain
data
subject: Test
Test
. ( <-- a final period and ENTER to send)
If the message is delivered, you are successfully able to use this server to relay through Exchange. If yes, check your application for issues.
telnet cas.domain.local smtp
mail from:anyone@domain.local
rcpt to:anyone@domain.local (if checking internally) or
rcpt to:anyone@external.domain
data
subject: Test
Test
. ( <-- a final period and ENTER to send)
If the message is delivered, you are successfully able to use this server to relay through Exchange. If yes, check your application for issues.
ASKER
Restarting the transport service resolved the issue.
check the send connector settings on your server and check the edge subscription for your edge server, I think one of these may help.