On-Premise Solution
We’ve already explored some ways to deal with outbound spam, now it’s time to see what is possible to do to protect ourselves from an internal perspective.
For an Exchange-based email server (2007 and later), even if it is configured to block invalid addresses, at the SMTP envelope, it is possible to personify a user of the domain using the DATA section of the message.
The “ms-Exch-SMTP-Accept-Authoritative-Domain-Sender” extended right indicates to the server from which domains it can accept to send e-mails, which are identified in the “Accepted Domains” section of Exchange.
When a domain is an “Authorative Domain Sender”, it is inappropriate to allow external users to submit e-mails without authentication by using this domain in the MAIL FROM header or in the FROM of the DATA section of the email.
To enforce this restriction, it is possible to remove the NT AUTHORITY \ Anonymous Logon” right on Exchange’s external connector (legitimate users, being authenticated, will still be able to send e-mails).
In order to validate the anonymous (non-authenticated) external sending from your server, you can issue the following command through the Exchange Management Shell by replacing “Default internet facing connector” with the connector accepting Internet emails:
[PS] C: \ Windows \ system32> Get-ReceiveConnector “Default internet facing connector” | Get-ADPermission -user “NT AUTHORITY \ Anonymous Logon” -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-SenderTo remove the personification using the “Anonymous Logon” rights, use the following command (always replace “Default internet facing connector” with the identifier of the connector accepting Internet e-mail):
[PS] C: \ Windows \ system32> Get-ReceiveConnector “Default internet facing connector” | Remove-ADPermission -user “NT AUTHORITY \ Anonymous Logon” -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-SenderPlease note that it is important for Exchange mail server administrators to ensure that there are no legitimate uses of the “NT AUTHORITY \ Anonymous Logon” right to send email using the external connector before proceeding with the steps mentioned in this article.
If this is the case, the creation of a new connector with this right, but limited to only receive corresponding IPs, can legitimize the implementation of this protection on the default connector while allowing the sending of emails anonymously for specific services.
This protection is unfortunately not implemented by default during the basic installation of the Exchange mail servers. The small amount of documentation available, the lack of visible impact and the lack of awareness of this problem mean that its implementation is not very widespread in the industry.
This simple manipulation, however, ensures a higher level of integrity for your electronic communications.
Office365 Solution
Office 365 does not offer internal spoofing protection for emails received from your own domain. It is therefore essential to put in place certain rules which will greatly limit attempts to spoof internal names.
We will create between 1 and 3 distribution lists as needed:
– 1 dynamic list to include all users with a mailbox
– 1 static list to add exceptions to rules **
– 1 static list for resource mailboxes **
** Both static distribution lists are optional if you do not use resource or exception mailboxes (scanners, printers)
Note: The following rules do not include optional distribution lists, but you can add them as conditions in the rules, if necessary.
To create these rules, you must access the Exchange Admin Center > Admin Center > Exchange > Mail Flow > Rules
Rule # 1: If the message is received by a member of the group “globalddl@domain.com” and is received from “Inside the organization”, Add the “X-Transport_Validation” message header with the value “validated sender “.
Rule # 2: If the message is sent to a member of the group “globalddl@domain.com” and includes these words in the sender’s address: “domain.com” (your domain name), add the subject with “USURPED WARNING MESSAGE:” unless the “X-Transport_Validation” header contains “validated sender”.
** Rule # 2 can be adjusted to bounce the message, deliver it with the warning or send it to another monitoring mailbox.
Note: It is recommended that you modify the included examples of names for the header and values to avoid widespread use of the same values that would circumvent this security.
In fact, these rules add a specific value within your message headers (confirmed sender) whenever a “real user” sends an e-mail inside the organization. Each time you receive a message from your own domain, it looks for that value if this header is not present, it will add to the subject of the message “USURPED WARNING MESSAGE” (or perform the action of your choice). It is also possible, in the Office 365 options, to reject the message by generating an incident report that will be sent to a valid mailbox for moderation.