relay only for server domains

I have an exchange server on my network.  We have multiple domains mycompany1.com, secondcompany.org, etc.
I want to be able to accept and relay an email with a 'from' address from one of my domains without having to use authentication.
I don't want relay only based on IP.

Here's why:  I have a public facing web based application that generates email notifications.  The server was hacked and being used to relay spam.  All the spam messages had a bogus 'from' - somewhere in france.  If is used regular authentication, the web app would still authenticate and still send all the bogus spam messages.  So, on the exchange side, if I only accept emails with 'from' using a valid domain that's part of my exchange server, that would minimize the problem.

How would I setup my exchange server (relay connector or transport rule?) to accept and relay messages with a from domain that exists on my server?
tia
Edmonds_ITAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

rgormanCommented:
You can't filter on your receive connector based on from address so you won't be able to do what you are suggesting.  You will need to use IP addresses as your relay restriction option.

You could possibly do something funky with a transport rule where you look at the subject or body for something specific to messages coming from your web application then look at the sender email and if it is from within your organization then allow the message to be sent otherwise you could drop it.
0
Edmonds_ITAuthor Commented:
I have the IP address in the SMTP connector as a valid relay.  When the web app got compromised, it stared sending thousands of emails with a from set to: supp-fr@grp.mobilesfree.fr  - or various derivatives there of.  
So my thought was to validate the 'from' domain against my domains and drop if no match.
0
rgormanCommented:
There is no validation function in Exchange other than maybe doing it through a transport rule like I suggested.
0
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.

tigermattCommented:
This sounds to me a classic case where one needs to take a step back and fix the root cause of the problem, not the symptom.

Limiting the sender address is unlikely to work. You effectively create an authentication token (the approved email address) which is not secure nor is it intended to be. If that token is present in the web app on the server in order to send mail, there is no defense should the server be hacked again.

Contrary to popular belief, many such infiltration cases are semi-automated; the servers are broken into by whatever means are necessary, and if not immediately exploitable, a human might spend some time to look around and obtain some specific knowledge in order to exploit the system. The attackers clearly already discovered how to authenticate to your mail server, or exploited the web app's built-in credentials to do so.

I would strongly recommend instead focusing on why the server was "hacked" in the first place:

Was it up-to-date with the latest security patches?
If the attack vector was over the network, did the IDS correctly detect the intrusion attempts, or do the rulesets need tweaking?
Is management access to the server restricted to trusted and pre-approved hosts?
(Linux only) Have you enabled key-based authentication for SSH and disabled native password authentication?
Has the web app been kept up to date to prevent exploits?

--

That said, this is not intended as a "lecture" but simply reframing the problem. It is not possible with the native Exchange tools to do what you seek to accomplish -- there is no way to filter sender address at the granularity of a receive connector, only at the whole organization, which would restrict other legitimate mail passing through your server.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Guy LidbetterCommented:
Hi There,

As tigermatt stated... you need to do some Application\Server Hardening... get a pen test done or at least review how you present the web app to the internet, look at how they got in and close it off.

The only thing you could do here is create a transport rule that drops any email that comes from "Outside your Organization" AND "The Recipient is not Inside your Organization"... i.e. the sender AND receiver are not an accepted Domain configured in Exchange.
0
Edmonds_ITAuthor Commented:
The server that was compromised is running a coldfusion application from a vendor.  We've patched the server and cold fusion, removed the compromised code and server was compromised again.

Unfortunately, the vendor is mom/pop shop and the application is of high importance.

We're reviewing Adobe's recommendations for server hardening.

The obvious is the obvious... I was just wondering if there was a way of adding some logic between a needed application over which we have little control and needed notifications from said application.

Public execution of hackers or email spammers might be a good starting point.

thanks. -BT
0
Guy LidbetterCommented:
LOL - Agreed....

But as I mentioned, to prevent your internal SMTP servers from relaying SPAM, your best bet is the Transport rule...
0
tigermattCommented:
BT - understood; these types of situation using software that is challenging to support really is a pain.

The transport rule is likely your best line of defense, at least to stop the novices / script kiddies.

Really depends on how the compromised app is being used to send mail. If a method call in the application is being used, then it is unlikely you will be able to stop this, since the mail will come from all the proper addresses and appear as legitimate mail. If you were previously using SMTP authentication and that was bypassed, it is possible this is how the vulnerability was being exploited.

If we can help further, let us know; EE has plenty of CF experts (not me, though, sadly) who might be able to help you analyse the app for vulnerabilities!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Legacy OS

From novice to tech pro — start learning today.