It is fairly common in Exchange Server 2010 environments for there to be applications or devices that send email to users. These are usually configured to relay email messages using an SMTP connection to a Hub Transport server. They almost never authenticate their SMTP session, so are considered anonymous senders by Exchange 2010.
In this scenario you may encounter an issue where the emails that end users receive show the SMTP address of the sender instead of the more friendly display name configured on the user mailbox that has that SMTP address.
For example an email from a scanner device will appear like this.
This will occur if the Receive Connector on the Hub Transport server is accepting anonymous email. Receive Connectors are not configured this way by default but many Exchange administrators enable it because it is the simplest way to allow applications or devices to send emails to internal recipients.
To enable Exchange Server 2010 to resolve the anonymous emails you need to configure the Authentication settings for the Receive Connector to enable the Externally Secured option.
However this is not possible for the Default Receive Connector due to the other Authentication settings that are already enabled.
Instead what you can do is create a relay connector for Exchange Server 2010 following the instructions here. Whether you restrict it to certain sender IP’s or allow your entire private network to use the relay connector is up to you.
Emails sent from devices using the new Receive Connector will resolve the name correctly from the GAL now.
Hello Paul,
Will say hi from Ecuador. Paul, I have a question.
I need to identify from which device was sent an email, how do I get that information, please I need your help as soon as posible.
Thanks
hi Paual, after creating the account in postini external email are deliver in gmail. it suppose to deliver to exchange mail box is there any sync missing.
best regards
Hi Paul,
it’s grate Post, can i ask you one question in my scenario i have 2 hub transport Servers (10.10.200.15 & 10.10.200.16) and we have f5 load balancer (10.10.200.20) and we have a pool for SMTP. so can you advice me how to create a receive connector to allow application to send External Emails using (10.10.200.20) in that case with the following requirements:-
– no authentication required.
– just only need to add IP address in remote servers (Receive connector).
Create a matching relay connector on each of the load balanced Hub Transport servers. On each connector, add the IP address of the F5 load balancer to the Remote Network Settings list.
https://www.practical365.com/how-to-configure-a-relay-connector-for-exchange-server-2010/
Anything that is able to connect to the F5 VIP will be able to relay, so you’ll need to apply access control on the F5 so that only approved IP addresses on your network can use that VIP.
only one user having this issue, when someone sending mail form external get this error . he can send message out
Delivery to the following recipient failed permanently:
hari_pant@hari.com.sg
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the relay xxx.xx.xx.x
The error that the other server returned was:
550 5.1.1 User unknown
—– Original message —–
Whatever the “relay xxx.xx.xx.x” is thinks the email address doesn’t exist. That’s where you should look.
is it possible email address is block by third party spam like Postini scanner.
Yes. I don’t know anything about your environment or mail flow. Do you use something like that?
Hi Paul,
Great article as always, thanks. This helped us solve the SMTP problem but it also opened up another can of worms – custom contacts (external email address) that exist on our system who are members of a distribution group were able to receive emails from other custom contacts while replying to the DL effectively making us an open relay. How do we stop this? Please help!
Thanks.
If you want external people to be able to reply to a distribution list then everyone on the distribution list will receive the emails. That’s what distribution lists do.
Dear Paul,
the Problem with your solution is, that if you have the Mailgateway like IronPorts configured to use this connectors, every external “User” has the posibility to write mails to Distributionlists which are forbiden for external Mail Access.
I think this is something you have to know bevore configuring stuff in this way.
Best regards
Claudius
Hello,
Resolving the SMTP into Display Name is cool, but unfortunately the Externally Secured checkbox brings more with itself. One of those is the ms-Exch-Bypass-Message-Size-Limit permission.
Of course, the message exceeding the size limit won’t be relayed, but it seems to be processed by the HubTransport servers, in extreme situations – causing the back pressure to turn on. Does anyone knows how to deal with that, not loosing that nice SMTP resolution feature?
Regards,
yacoob
Hi,
Actually i have an issue but i don’t know if it is related to this article.
The issue is:
I have some users e-mail add showing up in the inbox instead of their display name.
Can you please advise how can i troubleshoot?
Thank you
Kind Regards
Hi Paul, if I set Externally Secured, the anonymous emails get displayed as Internal (which is what I want). However, we also want to prevent these anonymous connections from relaying externally. I haven’t been able to find out how to prevent that. These are just internal systems. Without the Externally Secured, some of these emails end up in the Outlook junk email (client side filtering). With the Externally Secured, no junk email issues but the sending systems are able to relay externally (which is what we don’t want). How can we accomplish this?
how to block anonymous mails inside the domain
Hello
I followed your recommendations, but when trying to configure the connector as shown, it is still an error: “ExternalAuthoritative cannot be set with BasicAuth…”
Please tell me, there are additional settings or other way to fix the problem?
Hi Bob, that error and the solution are actually explained in the article.
Paul,
I tried this and the names still show the full email address. Will I need to create another IP on the Hub Transport server for this to work?
Hi James, I’d say your connections are still being processed by the Default Receive Connector if you’re not seeing the desired result. You can troubleshoot that by enabling protocol logging on your Receive Connectors, then inspect the logs for the connections and it will tell you with connector processed the connection in question.
A separate IP address for additional connectors is a good way to resolve issues where multiple Receive Connectors are sharing an IP address but you’re having problems getting the correct one to process the connections.
Hope that makes sense!