E-mail notifications and Exchange Hub Transport

Most of organizations have a number of smtp notification sources, which exist in background of common operations. They can compound a problem if something goes wrong with these notifications. Usually only a few of smtp sources are capable for TLS and authentication, while others are not perfectly configured. As a result, smtp server confines
itself with straightforward ip filter where IPs of anonymous “technology sources” are enlisted.
On the other hand, some of administrators may encounter ip address forging in their networks. Thus they want to prevent sending from forged email address but preserve anonymous emails from notification sources.
This is possible with help of Exchange transport server. The general approach is to prevent anonymous sending from sensitive accounts. This can be achieved through
standard sender filter, which is a part of antispam filter set.
The other side of the problem, anonymous sending to sensitive/all addresses, is a part of common antispam strategy and is not addressed here.

First, lets install sender filter agent on Hub Transport server. (You may use Edge server instead, avoiding most of the following recommendations.)

1. Install sender filter agent:
install-transportagent –name:”Sender Filter Agent” –transportagentfactory:”<factory>” –assemblypath:”<dll path>”

(Let me know please if you need an example, as I don’t remember the source and found nothing appropriate via fast search which was not thorough.)

OR

Just launch install-antispamagents.ps1as described inhttps://technet.microsoft.com/en-us/library/bb201691.aspx

2. Make sure that sender filter is enabled, see https://technet.microsoft.com/en-us/library/bb124087.aspx

Make sure that the next flags are set for the sender filter:

Externalmailenabled=true (anonymous connections are filtered);

Internalmailenabled=false (authenticated connections are NOT filtered).

See pls. https://technet.microsoft.com/en-us/library/aa996920.aspx

3. Create receive connector for technology sources <TechnologySources>, make IP filter allowing IPs of technology sources as usually. It is better to appoint connector type as Customandtoallow anonymous connections explicitly on this connector.

Take away relay permission from anonymous connection:
get - receiveconnector < TechnologyAccounts > | remove - adpermission - user " NTAUTHORITY \ ANONYMOUSLOGON " - extendedrightsms - exch - smtp - accept - any - recipient

Take away sending as Exchange Authoritative domain (or Partner domain) permission:
get-receiveconnector <TechnologyAccounts> | remove-adpermission -user "NT AUTHORITY\ANONYMOUS LOGON" -extendedrights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Note, please, that sending is impossible if alert source appoints sender address belonging to "AuthoritativeDomain" or "InternalRelayDomain".

Make sure that the permission Ms-Exch-Smtp-Accept-Any-Sender and permission ms-Exch-SMTP-Submit are still present for anonymous account.

See pls. https://technet.microsoft.com/en-us/library/aa996395.aspx for more details.

4. Add blocked (sensitive) senders to external blocked senders list:
set-senderfilterconfig -blanksenderblockingenabled:$true -blockedsenders bigboss@contoso.com,superadmin@contoso.com

This parameter can accommodate up to 800 email addresses in Exchange 2010.

5. Create External Relay Domain in Exchange organization and have alert sources send alerts from external addresses. If this recommendation is not achievable for some reason, note, please, that you should not take away sending as Exchange Authoritative domain (or Partner domain) permission. In this case, emails might be sent as insensitive senders under the forged IPs.

Checkup sending via <TechnologySources> connector:

- Anonymously sent emails can be mailed to internal Exchange recipients only;

- Relay to other domains is not allowed;

- Anonymous sending from sensitive addresses is not allowed;

- Authenticated user can send as any (allowed to him) sender to any (allowed) recipient.

Sometimes you can find it useful to place external MTA in before of Exchange Hub Transport to accept emails from some internal sources. For example, it might be a typical coexistence scenario.

Thus you will use only authenticated connections from only one source on the receive connector.

Just create sending account <domain\connectorsvc> to enter it’s credentials onto the external MTA gateway and allow this account to send as any sender.

6. Create receive connector <Partner>, and add external MTA’s IP to the corresponding list. It is better to create connector of the Customtype. No permissions should be granted under creation. Allow basic authentication and TLS on the connector.

7. Grant the account <domain\connectorsvc> permission ms-exch-smtp-accept-any-sender and permission ms-exch-smtp-submit on the <Partner> receive connector.

Checkup sending via external MTA:

- You can send a message as any sender (allowed by MTA) except of the sender in Authoritative/Partner domain (no permission ms-Exch-SMTP-Accept-Authoritative-Domain-Sender);

- You can send a message to any recipient in Authoritative/Partner domain;

- You can not send a message to the recipient in Internet (no permission ms-exch-smtp-accept-any-recipient).

Note please that the authentication is much simpler since external MTA supports mutual TLS authentication, as described in https://technet.microsoft.com/en-us/library/bb123543.aspx