One of the challenges of mail filters is managing users. Mailprotector gives you 4 ways to create user accounts:
- Manual creation – Whenever you have a new email user, alias, or distribution group, you need to sign into the console and add the user. This is a 5 minute process, but you have to remember to do it! You also have to be sure to review your account each month before billing, and REMOVE any users that may be gone. This is a solid way to control your expense, because nothing will be added to your bill, unless you do something.
- Import from CSV – if you can export your users from your Exchange server (See PowerShell command at the end), you can import them into Mailprotector pretty easily. This is a great solution for the initial setup, but doesn’t really solve the adds/changes that naturally occur. Eventually you will need to use one of the other options. You can read more about how to do this on the Mailprotector support site.
- LDAP – LDAP setup allows Mailprotector to grab all active users, aliases, distribution lists, etc and it will automatically add and delete any addresses that it finds. If you can set this up, this is the easiest way to manage names, however it does require a little knowledge of Active Directory, and a port open on your firewall to access LDAP on your server. Most importantly, it requires you to keep your Active Directory clean, or you will adding (and paying for!) accounts that do not receive mail. You can read more about how to do this on the Mailprotector support site.
- Address-Discovery – This is a new feature that was added in the last 6 months. It is a great addition, however it has a tendency to create accounts for addresses that should have been rejected. This is not really Mailprotector’s fault, it is a limitation of the way Exchange works
Let me try to explain what happens:
When an email is sent to Mailprotector with Address-Discovery enabled, it goes through all the standard filtering, and if it passes that filtering, it is delivered to the Exchange server, and here is where the problem begins. The last few releases of Microsoft Exchange accept everything. This was done to eliminate “directory harvesting”, where a hacker could simply keep trying names until one was accepted. Exchange just accepts them all, then passes them to the next layer, which then does the actual address look up, and when it can’t find it, sends a NDR receipt to the sender. Unfortunately this makes it impossible to keep Address Discovery turned on permanently, since Mailprotector is simply looking for a “250” code that the user is valid, which is always provided.
[evp t=”indent1″]So what do you do?
Solving this for an on-premise Exchange server is possible. The solution is that you have to by-pass the “Front End Transport” service, and deliver the mail directly to the “Transport Service“. To do this we need to turn on a bunch of things. Here are some steps we have tested:
[evp1 t=”indent1″]1. Check to see if the Exchange Anti-Spam Agents are installed:
(these are all PowerShell commands run in the Exchange PowerShell interface)
Get-TransportAgent
If “Recipient Filter Agent” is not listed, issue the following command to install the Exchange Anti-Spam Agents:
& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
2. Ensure the “Recipient Filtering Agent” is enabled:
Get-TransportAgent
If it is not enabled run the following command to enable the Recipient Filtering Agent:
Enable-TransportAgent “Recipient Filter Agent”
3. Ensure AddressBook is enabled:
Get-AcceptedDomain | Format-List Name,AddressBookEnabled
If any addressbook is not enabled, use the following command per the version of exchange installed:
Exchange 2013:
Get-AcceptedDomain | Set-AcceptedDomain -AddressBookEnabled $true
Exchange 2016:
Get-AcceptedDomain | ? {$_.AddressBookEnabled -ne “True”} | Set-AcceptedDomain -AddressBookEnabled $true
RESTART the “Microsoft Exchange Transport” Service
4. Ensure Recipient Validation is enabled:
Get-RecipientFilterConfig | FL Enabled,RecipientValidationEnabled
If this command returns it as DISABLED, use the command below to enable it:
Set-RecipientFilterConfig -RecipientValidationEnabled $true
RESTART the “Microsoft Exchange Transport” Service
5. Allow access to the Default receive connector:
Edit the “Default <servername> connector” (which is the Hub Transport, NOT Frontend Transport) settings, by checking the ANONYMOUS USERS check box in the SECURITY section
6. By default, this connector accepts messages on 2525. Leave port as-is, however you will need to modify your firewall to allow this port into your Exchange server (ideally only from Mailprotector’s IPs) and you need to MODIFY your Mailprotector Inbound SMTP Host address to add “:2525” to the IP .
7. Test to make sure unknown email addresses are now getting rejected with the “550 5.1.1 Unknown user” error
(these commands would be typed in a command prompt window. You will likely need to enable Telnet in the Control Panel)
Telnet Test:
telnet <mailserver> 2525
mail from: <email@external.com>
250 2.1.0 Sender OK
rcpt to: <fakeuser@your_domain.com>
550 5.1.1 User unknown
PS: If you haven’t typed in Telnet before, you can’t backspace. If you fat-finger something, you pretty much have to start over!
8. Optional, but recommended) Disable the other Anti-Spam Agents:
Set-SenderFilterConfig -Enabled $false
Set-SenderIDConfig -Enabled $false
Set-ContentFilterConfig -Enabled $false
Set-SenderReputationConfig -Enabled $false
9. Once this is finished, if you are in clean-up mode, you can dump a list of all of your Exchange users by running this PowerShell command on your Exchange Server:
Get-Mailbox | select name -ExpandProperty EmailAddresses | select name, smtpaddress | Export-csv c:\temp\AllEmailAddress.csv
You would then compare this list against the list that is in Mailprotector, and either delete them, re-classify them as Mailing lists, or delete them and make them an alias of an existing user.
[/evp1][/evp]Please let us know if we can improve on any of these steps, or if you discover any discrepancies. I hope this helps you tame user creation in Mailprotector. If your clients are hosted with O365, stay tuned for another blog on how to resolve this there.
Special thanks to Benjamin M. at our parent company Network Depot (http://networkdepot.com) for the testing and documentation!
