Link to home
Start Free TrialLog in
Avatar of rkarnosh
rkarnosh

asked on

Unable to get external SMTP relay to work in Exchange 2010

Hello,

Since migrating to Exchange 2010 a few days ago, I have been unable to get outside SMTP access to work for my smart phone users.  I know it's probably related to the rc've connectors and/ or port forward settings on my firewall.  I have tried a number of things, but have been unsuccessful.  Pop works fine and I have been able to get an outside Outlook client to send SMTP traffic over port 587 succesfully, but haven't been able to get to work on a Windows Mobile, iPhone or Blackberry. Here's my setup and some things I have tried:

Adtran Firewall has a port forward setting to flow Port 25 to a Barracdua and then it flows on to my Exchange 2010 box.  Adtran Firewall has port foward setting to send port 80, 443, 990, and 587 directly to Exchange box.  OWA access, POP and SMTP setup on external Outlook client pointing to port 587 all work fine.  The Default Rc've connector is setup for all IP's.  For authentication, TLS, Basic, Offer Basic after TLS, Exchange, and Integrated Windows authentication are all checked.  For Perm groups, all except Partner is selected.  The Client Rc've connector is setup the same.  I do have another Custom Rc've connector that I setup to allow my App svr to relay mail.  It is limited to rc've only from the IP address of the App svr though and should not be conflicting with anything.

I can send email from my Win Mobile phone to my internal domain successfully, but when I try to send them to other domains, I get the error 550, No such domain at this location.  I would look at using ActiveSync, but I am using a Self-signed cert.  I may get a 3rd party cert in the future, but I just need to get the SMTP working for mobile users for now.  I have tried different SMTP and SSL settings on my phone and have tried to play with settings on the rc've connectors, but have not been able to resolve yet.  I have researched the 550 error, but have not been able to find a solution that has helped me.  Thanks in advance for your help.
Avatar of Craig Beck
Craig Beck
Flag of United Kingdom of Great Britain and Northern Ireland image

Microsoft recommend creating a new connector for mobile clients... (written for Exchange 2007, but the same for 2010)...


Open the Exchange Management Console (EMC)
Navigate to Server Configuration, Hub Transport and select the HT server
Click New Receive Connector from the Action pane
Give the new Receive Connector a name such as, "Mobile Clients"
Select Client as the intended use for this receive connector and click Next
Click Next to allow all remote networks to use this receive connector
Click New to create the new Receive Connector
Now open the properties of the Mobile Clients connector
Click the Network tab and notice that the port the connector uses is 587
Click the Authentication tab. Ensure that Transport Layer Security (TLS), Basic Authentication, Offer basic authentication only after starting TLS, and Integrated Windows Authentication are checked.
Click the Permissions Groups tab. Ensure that only Exchange users is checked and click OK to close the properties window.
Avatar of rkarnosh
rkarnosh

ASKER

It would not complete the creation of the connector using the steps listed above.  The current Client Rc've connector that existed out the box conflicts with it.  When I try to create using the steps above, I get the following error:
Mobile Users
Failed

Error:
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector "MSGSVR\Client MSGSVR". A Receive connector must have a unique combination of a local IP address, port bindings, and remote IP address ranges.

Am I missing something?
The Exchange Management Console is telling you that you have a connector already configured on the same IP with the same port number.

You could try removing the secure SMTP options from the Client Receive Connector and applying to the Mobile Users Receive Connector.
I guess I don't understand why the current client connector would not work then versus the one being suggested since the current connector makes available the same IP's and ports, offers the same authentication types (and more), and offers the same permissions (and more, since all except partners is selected).  Is there something I am missing as to why a seperate connector with less authentiction types available and less permissions would help over the current Client connector?

Thanks
ASKER CERTIFIED SOLUTION
Avatar of rkarnosh
rkarnosh

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
No other usable solutions were given