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

Exchange 2010 Resolve Anonymous mail to GAL but NOT enabling relay

I'd like to configure an Exchange 2010 SP1 receive connector for anonymous mail, have it resolve to the GAL, but NOT allow it to relay outside my organization.  This connector is only to be used by internal applications for internal e-mail deliver only.  So far, I have been able to find out how achieve this but the connector would also allow mail relay.

Does anybody know how to achieve this?

Summary:  Exchange 2010 SP1 Receive connector for anonymous mail, with GAL resolution, but NO mail relay allowed (only internal mail delivery)

0
ctc1900
Asked:
ctc1900
  • 10
  • 6
  • 3
1 Solution
 
JohnGrunwellCommented:
Sorry Mis-understood the question
0
 
ctc1900Author Commented:
No worries JohnGrunwell, thanks for checking though
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
ctc1900Author Commented:
JohnGrunwell, that solution enables mail relay, which I would like to avoid.  Thanks
0
 
ctc1900Author Commented:
I'm testing a possible solution: follow the instructions on "http://exchangeserverpro.com/how-to-configure-a-relay-connector-for-exchange-server-2010" for creating an relay connector and apply the following Remove-ADPermission

Get-ReceiveConnector “Name” | Remove-ADPermission –User “MS Exchange\Externally Secured Servers” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”
0
 
AkhaterCommented:
Basically you have nothing to do to meet your requirement just enable "anonymous" on it, by default the connector will NOT allow relaying. if yours does then the permission was added and it can indeed be solved by removing the “ms-Exch-SMTP-Accept-Any-Recipient” extended right
0
 
ctc1900Author Commented:
Akhater, one of the requirements is to enable GAL resolution.  Just enabling "anonymous" does not help me meet that requirement.  Thanks.
0
 
AkhaterCommented:
can you please give me more details about what you mean by "GAL resolution"
0
 
ctc1900Author Commented:
This article explains resolving anonymous mail to the GAL, thanks

http://exchangeserverpro.com/resolving-anonymous-mail-gal-exchange-server-2010
0
 
AkhaterCommented:
this makes it clearer thanks.

so what is the problem with using this method to create a new connector and restrict its usage only to the IPs of the internal applications ?
0
 
ctc1900Author Commented:
I want to allow local mail delivery only (no mail relay) with anonymous GAL resolution, thanks.

The only solution I found so far is to create a relay connector like explained here "http://exchangeserverpro.com/how-to-configure-a-relay-connector-for-exchange-server-2010" and remove the "mail relay" functionality with the following:


Get-ReceiveConnector “Name” | Remove-ADPermission –User “MS Exchange\Externally Secured Servers” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”
0
 
AkhaterCommented:
Just for my info this solution worked ?
0
 
ctc1900Author Commented:
So far this solution has been working OK
0
 
AkhaterCommented:
thank you, that's an interesting approach
0
 
ctc1900Author Commented:
One more thing, it seems as if the Exchange powershell console noticed the change as it is throwing this warning every time I get the receive connector.  I have ticket going on with Microsoft to see if this is a recommended solution or if they have a better a approach

[PS] T:\>Get-ReceiveConnector "Name"

Identity                                              Bindings                                             Enabled
--------                                              --------                                             -------
..............\Name                               {X.X.X.XX:XX}                                      True
WARNING: The object .............\Name has been corrupted, and it's in an inconsistent state. The following validation errors happened:
WARNING: You must set the value for the PermissionGroups parameter to ExchangeServers when you set the AuthMechanism parameter to a value of
ExternalAuthoritative.

0
 
AkhaterCommented:
thank you for the update, and if you can share PSS solution it would be geeat
0
 
ctc1900Author Commented:
PSS advised they recommend enabling authentication for the application servers sending e-mail, which requires a mailbox for each one of them to the very least.  They also advised that this is a time-consuming process so the workaround (removing the ms-Exch-SMTP-Accept-Any-Recipient permission for MS Exchange\Externally Secured Servers) is the most optimized.  

There are a few a couple of gotchas with this workaround:

1) The warning message mentioned on a previous post when "get-receiveconnector". PSS advised it can be safely ignored

2) The Exchange Management Console sees this change when trying to open the receive connector object and throws this warning "The properties on this object have invalid data. If you click OK, default values will be used instead and will be saved if you do not change them before hitting Apply or OK on the property page.  If you click cancel, the object will be displayed read-only and corrupted values will be retained".    

      PSS advised that in order to make changes to this connector, we would need to temporarily add the "ms-Exch-SMTP-Accept-Any-Recipient" permission for "MS Exchange\Externally Secured Servers", make the appropriate changes, and then remove the permission again.


PSS Message

To achieve the receive connector for internal email only whilst be to able resolve display name, our recommended way is to enable authentication for the application servers. This method requires you to create mailbox for each of the application servers.  This could be a time-consuming process when you have over hundreds application servers. Thus, the workaround you found is the most optimized in our case.

After removing the AD permission for the connector, the connector will be unable to configure but it is functional. The warning can be ignored. One thing is that if you want to make some changes to the connector afterwards, the permission needs to be re-added, or you need to re-create the connector.
0
 
ctc1900Author Commented:
Found solution
0

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.

  • 10
  • 6
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now