I am trying to prevent Exchange from sending emails from addresses that do not exist in the organization. For example sales@somedomain.com is a valid email address setup in Exchange and should send emails. However aslkjs38@somedomain.com is not an email address assigned to any users however the Exchange server will still send the emails as long as someone logs into the server with a valid user account and password.  They have made it apparently impossible to find the actual user account that is sending the emails so I would like to prevent Exchange from sending emails that aren't associated with a user account and also matching the users account that logged in.  Also if anyone knows how to find the users security account that is actually sending an email in the queue that would be helpful as well.

As far as I know the only way to submit a message from a phony sender is via unauthenticated SMTP, such as from a POP or IMAP client connecting to TCP port 25 when any anonymous user is allowed to submit.  You have the option of locking down which IP addresses can submit unauthenticated SMTP through configuration of your receive connectors, thereby requiring POP and IMAP users to send via authenticated SMTP, e.g., the Client receive connector over TCP port 587, which I believe won't accept mail from invalid addresses.

I encourage you to specifically describe the method your users are employing to send from phony addresses if it's different from the one I described that you can res

The users connect in all sorts of ways.  Outlook, OWA, IMAP, POP3, SMTP depending on the device(PC, Laptop, MAC, Phone).  The issue isn't actually the users. It is the spam company that hacked a users account. If only I could figure out the security account we could change the password but I've searched long and hard on the Internet to figure this out and there doesn't seem to be a documented solution.

We blocked 4 IP Addresses today at the firewall that were sending the spam however I imagine those 4 addresses will change and we will be in the same boat.  We really hate to make 90+ people change passwords due to being unable to determine the account being used.

The server is not an open relay.  We have tested with several tools and by writing a small c# program to test all sorts of weird combinations on what the server will and won't do.

• Edited by jhersey 5 hours 22 minutes ago

You can deploy an Exchange Edge server and block that kind of stuff, or subscribe to an antispam cloud service or an appliance.  I believe all of them will block mail from forged sender addresses from your domain.

Already have a cloud based anti spam that does not block that sort of stuff.  That is sort of cop out answer with no explanation.   Edge transport does not support what we need.  Microsoft needs to fix lots of issues in Exchange since they went away from Exchange 2003.  Everything since has been somewhat broken.

Insulting those who are trying to help you is not a good way to get a better answer.

You need to better tune your cloud-based antispam solution to block forged sender addresses or choose a better one.

This is what out-of-the-box Exchange 2013 has to offer.

https://technet.microsoft.com/en-us/library/bb124354%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396

Thanks but that function is pretty useless.  It would require use to put every combination of every letter and number in the filtered list up the maximum number of characters supported in the email address to be of any use.  The antispam solution is helpful but still whoever this is, is sending 90,000 emails+ per day for the last 2 days through the server.  That is taxing the server to say the least.  Even with anti-spam the message still enters the queue and has to filtered out.

The users connect in all sorts of ways.  Outlook, OWA, IMAP, POP3, SMTP depending on the device(PC, Laptop, MAC, Phone).  The issue isn't actually the users. It is the spam company that hacked a users account. If only I could figure out the security account we could change the password but I've searched long and hard on the Internet to figure this out and there doesn't seem to be a documented solution.

We blocked 4 IP Addresses today at the firewall that were sending the spam however I imagine those 4 addresses will change and we will be in the same boat.  We really hate to make 90+ people change passwords due to being unable to determine the account being used.

The server is not an open relay.  We have tested with several tools and by writing a small c# program to test all sorts of weird combinations on what the server will and won't do.

• Edited by jhersey Wednesday, August 26, 2015 2:05 AM

The users connect in all sorts of ways.  Outlook, OWA, IMAP, POP3, SMTP depending on the device(PC, Laptop, MAC, Phone).  The issue isn't actually the users. It is the spam company that hacked a users account. If only I could figure out the security account we could change the password but I've searched long and hard on the Internet to figure this out and there doesn't seem to be a documented solution.

We blocked 4 IP Addresses today at the firewall that were sending the spam however I imagine those 4 addresses will change and we will be in the same boat.  We really hate to make 90+ people change passwords due to being unable to determine the account being used.

The server is not an open relay.  We have tested with several tools and by writing a small c# program to test all sorts of weird combinations on what the server will and won't do.

• Edited by jhersey Wednesday, August 26, 2015 2:05 AM

Now I see that you just want to be argumentative. 

First, sender filtering would very easily achieve what you originally asked for.  But now that you clarify that you want the messages kept off the Exchange server, an Exchange-based answer isn't what you want, so we now go back to you needing a better cloud-based or appliance-based solution.

We're done here.

Wow, you are really no help here. We have a similar issue and use industry leading anti SPAM and CISCO security appliances. Ed Crowley MVP lol

Thanks but I am not trying to be argumentative.  Hopefully someone will see this that has some answers. 

 

Hi,

A few recommendations:

On the receive connector or firewall you should limit it to only receive connections on port 25 from your cloud filtering. Cloud filtering providers publish the IPs that you need to allow through your firewall (recommended) or on your receive connector. This way you can prevent people bypassing your cloud filtering.

Enable verbose logging on the receive connectors. Here you may see the username that is being used to send the email however it may be blank and they are not using a valid login. If you do find the username then you can change the password or disable the account as needed.

Sender ID filtering checks the SPF record to see if the sending IP address is a permitted sender for the sending domain. For example, you configure the SPF records for your domains and include a list of permitted senders. You can then configure Exchange to block email that is sent using your domain but from an IP that's not on the permitted senders list. I've written a blog about SPF records with instructions on how to write your own one. See here: http://markgossa.blogspot.co.uk/2015/08/understanding-spf-records-part-1.html. We use Sender ID filtering for our customers and this prevents spoofing of their domains.

Let me know how you get on.

Thanks.

Also, if you suspect that the user is logging into OWA and sending emails this way, you should be able to tell in the message tracking logs as there will be no client IP specified or it will be the Exchange server IP. If this is happening then check the IIS logs around the time that the emails are received - you may find the user who is logging in.

Thanks.

They are coming via SMTP. I can see the emails in the SMTP logs but can not see the username even with verbose logging on.

Ok, in this case, we can move on to try the other suggestions:

On the receive connector or firewall you should limit it to only receive connections on port 25 from your cloud filtering. Cloud filtering providers publish the IPs that you need to allow through your firewall (recommended) or on your receive connector. This way you can prevent people bypassing your cloud filtering.

Sender ID filtering checks the SPF record to see if the sending IP address is a permitted sender for the sending domain. For example, you configure the SPF records for your domains and include a list of permitted senders. You can then configure Exchange to block email that is sent using your domain but from an IP that's not on the permitted senders list. I've written a blog about SPF records with instructions on how to write your own one. See here: http://markgossa.blogspot.co.uk/2015/08/understanding-spf-records-part-1.html. We use Sender ID filtering for our customers and this prevents spoofing of their domains.

When enabling sender ID filtering, ensure to set the internal SMTP servers on the transport config to include the mail filter IPs otherwise Exchange will think that those IPs are the actual sender's IPs. You do this by using Set-TransportConfig -InternalSMTPServers ip1,ip2. More info here: https://technet.microsoft.com/en-us/library/bb124151%28v=exchg.150%29.aspx

Thanks.