• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 296
  • Last Modified:

Why would exchange allow outlook to send correctly, but block telnet from internal to external?

I have been trying to troubleshoot an ERP issue where we cannot send an alert outside of the network.  Outlook works fine (in house Exchange server), and we are sending and receiving email fine.  The ERP has a domain user and password to connect to exchange with (The server rejected one or more recipient addresses. The server response was: 550 5.7.1 Unable to relay).   When I connect with Telnet, it accepts my domain username, but fails when I try to send to anyone outside the internet for the recipient with Unable to Relay.

We have not had any issues with email via OWA or Outlook, so this is new for me to troubleshoot.  

We are not running TLS.

Any suggestions would be helpful!  Thanks
1 Solution
AmitIT ArchitectCommented:
Create a separate relay connector and add the ERP server IP in the relay list. Enable anonymous check box.
CrimsonwingzAuthor Commented:
Tried that already, but no luck.  Same errors.
Outlook and OWA do not communicate with Exchange Server via SMTP.

An "unable to relay" error usually means the  Send Connector that Exchange is using requires authentication, and you didn't authenticate. I'm guessing in the Telnet test you didn't send an AUTH LOGIN command, so as soon as you specify the RCPT TO line, it drops you.

Can you test with Outlook or Thunderbird or some other email client that is configured NOT to connect to Exchange, but simply to send a message via SMTP? Or does the ERP software not have a way to test the SMTP credentials by sending a test message?
Adam FarageEnterprise ArchCommented:
Frosty is spot on. Outlook uses RPC calls (either MAPI.NET, which is TCP / MAPI or RPC / HTTPS, RPC encapsulated MAPI packets over HTTPS) to make its calls to Exchange, and mail pickup is not through "SMTP" but instead the Mail Submission Service from Outlook or OWA.

In this case, it is most likely one of two things:

1) You are setting something incorrectly within the Receive connector
2) There is a boundry (spam) device that requires the email address to have an accepted domain, or valid email. IronPort requires this, and so does EOP (Exchange Online Protection) by default.

First off, make the receive connector. These direction will work for Exchange 2007 and 2010. I would select "Anonymous" just so it doesn't have to authenticate, but make sure in the accepted networks tab you select ONLY the ERP servers.

The big piece people forget is to actually granting the Anonymous logon permissions for the connector, which are shown below:

Get-ReceiveConnector "CRM Application" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Open in new window

With that said, this should be pretty cut straight, forward and easy to setup. If you do have a boundry device, just make sure its a valid SMTP address for your organization (for instance, if the accepted domain is "company.com" the email should be in the format of address@company.com)
CrimsonwingzAuthor Commented:
The issue was actually being caused by the ERP wanting to authenticate via TLS (it operates as an Outlook client but isnt configurable).  However, with the way I phrased the question, this is the closest to being the correct answer.  Thank you.

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now