1

Related: Exchange 2010 Anonymous user with accept-any-sender permission?

An Exchange 2013 default setup for a connector that has "Anonymous users" security setting checked grants the following rights to the connector:

User                         ExtendedRights                                    Deny
----                         --------------                                    ----
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Accept-Any-Sender}                  False
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender} False
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Accept-Headers-Routing}                  False
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Submit}                             False
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Store-Create-Named-Properties}           False
NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Create-Public-Folder}                    False
NT AUTHORITY\ANONYMOUS LOGON                                                   False
NT AUTHORITY\ANONYMOUS LOGON                                                   False

"Accept any sender" is obviously required, because otherwise incoming emails won't get through at all, also "SMTP Submit" is required. but what about "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"? The right is explained here as "Allow to send as any domain hosted on the connected server's Exchange organization", or any domain in Get-AcceptedDomain that's listed as "Authoritative". I expect that this right is superfluous, and frankly detrimental to maintain, yet revoking this makes Exchange connector to display that no one has enough rights to send mail through this connector. Still, incoming mail flow does not get interrupted from this.

Why is this right present by default on anonymous-enabled Exchange connectors? Is it safe enough to remove this right, as no external devices should be sending mail through this unsecured connector (it only has STARTTLS as security option, and no auth settings are defined by default)? And, should I ever allow this right on any unsecured connector at all, provided the connector is facing the Internet? Also what about the rights for "create public folder"?

Vesper
  • 794
  • 1
  • 9
  • 32

1 Answers1

1

The default permissions on the Receive Connector are secure for most implementations. Enabling Anonymous is the only thing that most sites have to do. The permission you have flagged though is often removed to attempt to deal with spoofing issues, where the email is being delivered to your server with the From line the same as your own domain. There are however valid reasons why you would accept those emails - a common one from a web server which sends email as something@example.com (example.com being your domain) and sends a copy to an internal recipient. Therefore you need to consider very carefully whether to remove the permission or not.

Sembee
  • 2,884
  • 1
  • 8
  • 11
  • Hmm. If a web server would send mail as @example.com, I'd rather make them an anonymous relay connector IP-locked to that web server. I'm talking about general purpose connectors primarily. Also I wonder if Exchange 2013 checks SPF/DKIM (or only SPF) for incoming connection sending mails from authoritative domain. My experience says the check is at least bugged, and at most absent. – Vesper Apr 18 '17 at 14:15
  • There is no support for DKIM in Exchange. It can do SPF lookups, but that would require you to use the spam filter agents and if your internal domain is the same as your external one, having the additional DNS entries internally. – Sembee Apr 21 '17 at 10:34
  • Well, aren't antispam agents on CAS servers pretty necessary? So, SPF checks are really present, and I've seen them working. No DKIM support - bad, however I've found a mention of third party software that does outgoing DKIM signing of mail. I wonder however, can Exchange with such an agent run automatic DKIM verification on incoming emails? PS: while searching I've found your name on another site - nice :) – Vesper Apr 21 '17 at 12:43
  • There is an outbound DKIM agent, I haven't seen one inbound though. Most Exchange deployments I see will be using a third party tool to do the spam filter rather than the built in agents. – Sembee Apr 23 '17 at 19:45
  • We can at most use EOP as third-party antispam solution due to our business specific, clients receive mail server SaaS without third party antispam solution. I wonder if we can implement incoming DKIM filtering with any kind of embeddable (agent-like) software. I'd be glad if there is some. It's weird that Microsoft kind of ignores this initiative. – Vesper Apr 24 '17 at 08:21
  • EOP can do DKIM. For on premise, Microsoft's attitude is that third parties should do that functionality. – Sembee Apr 24 '17 at 12:02