ms-Exch-SMTP-Accept-Authoritative-Domain-Sender deny seems not to work on FrontendTransport connector

Question

We run an Exchange 2016 op-prem. As our internet-faced SMTP Receive connector we use a FrontendTransport Connector. By some reason it looks like ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Deny for Anonymous Logon seems to not apply. First I did remove AD permission by using this command:

Get-ReceiveConnector "Connector Name" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"} | Remove-ADPermission

Then I even have explicitly denied permission via ADSI Edit security tab, but no success. Still mail from with a autoritative domain in Email Address can send emails through this connector. This is not true for a test connector of type Hub Transport.

Is this as designed? Do I need to create my internet smpt connector as a Hub Transport connector? What is the difference anyway?

Interesting is that I am pretty sure this worked in the past. I have configured that several years ago and from what I can remember ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Deny for Anonymous Logon did work.

kind regards,

Dieter

Answer 1

hi @Anonymous ,
I checked with the Exchange Product Group and can confirm that ms-Exch-SMTP-Accept-Authoritative-Domain-Sender only works with Hub Connectors in 2016 and above. :(

Answer 2

Hi, the goal is that I am trying to avoid accepting spam emails which come like from our own addresses.
So, on this connector no emails coming from like e.g. first.last@mathieu.company .com to either first.last@mathieu.company .com or to whatever @comapny.com. Because this is our only Exchange Server and no emails from any authoritative domain shall pass through it. We have another dedicated smtp connector which allows this for certain purposes like mailchimp etc.

cheers

Answer 3

Ok, in that case, I wouldn't even mess with the receive connectors. :)
Does your anti-spam/anti-phishing solution do this? I recommend setting there if it exists on a SMTP gateway that sits in front of Exchange.

If not:

Just create a transport rule. Example.
Craft as you see fit:
https://support.knowbe4.com/hc/en-us/articles/212679977-Domain-Spoof-Prevention-in-Exchange-2013-2016-Office-365

This is far easier to maintain and you can provide a rejection message if you want or just drop the message.

Alternatively, use anti-spam tools built into Exchange, though I typically do not recommend these as they are pretty basic and you really should run anti-spam/anti-phishing on a separate gateway :
https://www.codetwo.com/admins-blog/how-to-prevent-internal-email-spoofing-in-exchange/

Answer 4

Ok, thanks for that hint. Well, this could valid approach, even though I'd rather have this ms-exch-smtp-accept-authoritative-domain-sender extended permission working on the connector. However, I have implemented a Transport Rule. For now I do forward emails for approval to check how reliable my configuration works.

On our mail gateway this is a feature which requires additional licensing.

But beside this, when I had a closer look to my Mail Flow Rule I figure that it seems to to work as expected.
The problem is, that if one user who is connected via Outlook, but from the internet, and he sends an email obviously as an internal user to another internal user AND an external user, gmail or so, this email gets blocked for approval. We have tested this carefully and this is what always happen. It only happens if the user's outlook is connected through internet and as recipients there is a mix of at least one internal + one external user. If it is just like from usera@mathieu.company .com to userb@mathieu.company .com it goes through without additional approval. Any idea? If that works this way, it is of no use, since my users often do connect to outlook from internet via ssl/https. Am I missing something? I configured my rule according to this https://support.knowbe4.com/hc/en-us/articles/212679977-Domain-Spoof-Prevention-in-Exchange-2013-2016-Office-365

See a screenshot attached:

Honestly I do not understand why sending an email from @mathieu.company .com to company.com AND gmail.com triggers this rule, and just sending from company.com to company.com doesn't.

Answer 5

In the email header of an Email sent via Outlook, but via Internet connection I see "X-Originating-IP" which is obviously a public IP. Is this eventually because of that considered to be "outside the organization"?