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

Cannot find the fix for Exchange 2010 open relay

Hi
From time to time the queues in my exchange 2010 server are full of spam. When checking those messages, i see the ¨from¨field is some external email address, not from our organization.
Been looking here and trying different options, but still, in tests in mxtoolbox and other tools, the server still figures as an open relay, even if i have a specific domain list in my "accepted domains" tab...
Could someone walk me through the settings to close the open relay?

Thanks
Jaime
0
GreatSolutions
Asked:
GreatSolutions
  • 11
  • 10
  • 2
  • +1
1 Solution
 
Alan HardistyCo-OwnerCommented:
Are you sure you are an Open Relay?  Have you checked on http://www.mailradar.com/openrelay/

What does that return in the results?

Alan
0
 
R--RCommented:
Please only open 25 port on firewall to Exchange server. Also enable and configure antispam feature on exchange 2010.

http://technet.microsoft.com/en-in/library/bb201691%28v=exchg.150%29.aspx
0
 
AmitIT ArchitectCommented:
First disable anonymous setting from the relay connector. If you are using Exchange for application relay, create new relay connector and configure your application to use new relay connector.
1
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

 
GreatSolutionsC.I.OAuthor Commented:
Alan in Tests methods 0,1 and 3 i have "Test not passed"
Amit if i disable the anonymous setting i cannot receive mails anymore
Antispam feature of exchange is configured
0
 
Alan HardistyCo-OwnerCommented:
Okay - then you have a problem as you are an Open Relay.

How many receive connectors do you have setup?
0
 
GreatSolutionsC.I.OAuthor Commented:
Two receive connectors. One named "Default" where all the remote network are enabled (0.0.0.0 to 255.255.255.255) and another one called "Client" where only my internal ip range figures in remote network (192.168.1.1/24)
0
 
Alan HardistyCo-OwnerCommented:
Okay - Please note down the settings in the Default Connector, disable it, then create a new Receive Connector, replicate the settings from the 1st one and then enable and test.

Alan
0
 
GreatSolutionsC.I.OAuthor Commented:
I forgot to mention i have Anonymous selected in both receive connectors.
If I create a new receive connector similar to the default with the exact same settings,  what's the point? Should I set something different in the new connector?
0
 
Alan HardistyCo-OwnerCommented:
Ah!

Pleas just disable the Non-Default connector, restart the Microsoft Exchange Transport Service service and then test on the test site again.

If you get the same results, please disable the Default connector and setup a new one as the Default connector may have underlying permissions that you can't see via the Exchange Console that allow relaying that a new connector won't have by default.

Make sure you restart the Microsoft Exchange Transport Service after making the changes and then test again and report back.

Many thanks

Alan
0
 
AmitIT ArchitectCommented:
That's what I said, in my post disable anonymous  and setup new connector for relay, if required.
0
 
GreatSolutionsC.I.OAuthor Commented:
I disabled the Non-Default connector, i can send and receive mail, and the internal application (that needs the relay) can also send mail. The problem is that when testing it's still an open relay.
If i disable now anonymous in the default connector it won't receive mails at all from the outside...
0
 
Alan HardistyCo-OwnerCommented:
If you disable the Default Connector - you won't receive emails for a short while until you configure a new Receive Connector and restart the Transport Service then emails will flow again and any emails that tried to talk to your server will retry and nothing will get lost.

Then you will have hopefully fixed the problem and mail-flow will return to normal and you can get yourself off any Blacklists that you have managed to land on as a result.

Alan
0
 
GreatSolutionsC.I.OAuthor Commented:
Ok, i'm giving it a try.
I disable all receive connectors.
When creating a new connector, what type should i use, custom?
Created a custom one, then i see that only TLS is selected in authentication, and nothing is selected in the Permission Groups
0
 
GreatSolutionsC.I.OAuthor Commented:
Amit if i disable Anonymous how will it receive mails from outside?
0
 
Alan HardistyCo-OwnerCommented:
You need Anonymous to be able to receive emails - just copy all the settings that you had on the old Default one, restart the Transport Service and test mail-flow and the Open Relay site.

Alan
0
 
GreatSolutionsC.I.OAuthor Commented:
Alan, you're right on the spot. I ticked Anonymous in the newly created one, mail flow is good, and all tests are ok.
Now the only issue left is create a new connector as relay for our internal application. For this receive connector, i guess i do not need to to tick Anonymous, and should i just enter my internal ip range in the "remote networks" setting?
0
 
Alan HardistyCo-OwnerCommented:
Just enable the old Client connector, restart the Transport Service and test the open Relay and see how that goes.  If it was restricted to the internal IP's then you should be good to go.

Alan
0
 
GreatSolutionsC.I.OAuthor Commented:
Enabled the old client connector, which didn't change much - in fact this client connector is for port 587. Don't know why this one is needed.
The problem with the new connector is that the application does not send - i need to give the possibility to send mail even when not authenticated, provided it's from an internal ip.
The weirdest thing is that the new connector has the exact same settings as the default one ( except range which is 1.1.1.1 to 255.255.255.255 since it didn't let me enter the same range as an existing connector)
0
 
Alan HardistyCo-OwnerCommented:
Okay - leave the New connector alone now - that is for the Public to use for sending you emails and nothing else.

In terms of the Client Connector, what is sending to / from that and what isn't working?

What is the network range on the 'New' connector and the Client connector?  Ideally the 'New connector should be everything except your internal network range and your Client connector just your internal network range.
0
 
GreatSolutionsC.I.OAuthor Commented:
As i previously said, there is some internal application that sends mails using unauthenticated users.

The situation now is extremely frustrating. Here it is explained in a nutshell: (forget about the old Client connector everything works without it, so i'm removing it to not complicate things further)

1) Enable old Default Connector (and disable all others)
- remote network range 0.0.0.0-255.255.255.255
- anonymous ticked
******* results ***********
- system sends and receive mails
- internal application sends mails succesfully
- system is open relay in tests

2) Enable two connectors
- new connector Main with the exact same settings as old Default Connector
- remote network ranges: 0.0.0.0-192.168.0.255 and 192.168.2.1-255.255.255.255, anonymous ticked
- new connector Client with range 192.168.1.1-192.168.1.255, anonymous ticked
******* results **********
- system sends and receive mails
- internal applications does not send mails
- system is not open relay in tests

It's driving me crazy!!!!
0
 
Alan HardistyCo-OwnerCommented:
What you need to do is keep the Main connector as it is now - delete the old Default connector and configure the old Client Connector to allow relaying using the following Exchange Management Shell commands:

Get-ReceiveConnector "Client Connector" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Change the "Client Connector" part to match the name of your Client receive connector name

That should sort out the Open Relay and allow your Apps to relay using the Client Connector (which you can change to use port 25 if you prefer.
0
 
GreatSolutionsC.I.OAuthor Commented:
That was it!! Granting the ADPermission to the client was the missing link!!
A million thanks for your patience!
0
 
Alan HardistyCo-OwnerCommented:
You're welcome.  It looks like that permission may have been granted to the Default connector at some point, so that would be why the Open Relay was created.

Now just to tackle any Blacklists:

www.blacklistalert.org / http://mxtoolbox.com/blacklists.aspx

Alan
0
 
GreatSolutionsC.I.OAuthor Commented:
Thanks, i indeed checked for blacklisting as soon as it worked, luckily we were still clean.

On another note, i still have a problem for some users relaying, and that has to do with permissions, so i created a new question for it: http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_28520062.html
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 11
  • 10
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now