Microsoft Exchange - SpamTagger/SpamTagger-Plus GitHub Wiki

For Exchange Online/Office 365 go here.

SMTP Address Verification

Exchange does not natively reject invalid addresses during the SMTP connection. This can cause problems for MailCleaner customers who select the SMTP Callout option.

However, Exchange can be configured to reject invalid addresses, resulting in a “550 5.5.1 User unknown” error. MailCleaner, in turn, can bounce these messages. This will protect the infrastructure against Denial of Services and the user count will reflect only valid addresses in the system.

Exchange 2003

Exchange 2003: Enable directory lookup for recipients in the recipient filter

  1. Open Exchange System Manager.
  2. Open Global Settings, right-click on Message Delivery, choose Properties
  3. Choose the "Recipient Filtering" tab
  4. Check the box "Filter recipients who are not in the Directory"
  5. Click OK to close. Enable the recipient filter on the SMTP protocol binding that accepts mail from the Internet
  6. Navigate to the SMTP Virtual Server that listens on the Internet (repeat all of these steps if you have more than one)
  7. Right-click on the SMTP Virtual Server, choose Properties
  8. On the "General" tab (already open), click the "Advanced..." button next to IP address
  9. Choose the IP/port binding that corresponds to the one that listens on the Internet. Either double-click or click the "Edit..." button.
  10. Click the check box next to "Apply Recipient Filter"
  11. Click OK three times to close this.

Exchange 2007

  1. Connect on the Hub server
  2. Open Exchange Management Shell and go in folder \Exchange Server\Scripts
  3. Install AntiSpam Component Install-AntispamAgents.ps1
  4. Open Exchange Management Console
  5. Install a new connector (note: there might be multiple connectors which receive messages on the same TCP port, e.g. one for internal connections and one for incoming messages once filtered by MailCleaner). Name: Mailcleaner MAIL-1x Network: Use these local IP addresses to receive mail: "IP address of Hub" Receive mail from remote servers that have these IP address: "IP address of MailCleaner" Permission Groups (x) Anonymous users
  6. Add relay accesses (for forwading, mailing lists, ...) from the shell:

Get-ReceiveConnector "Mailcleaner MAIL-1x" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any- Recipient"

  1. Configure Hub's antispam from the Exchange Management Console:

Organisation Configuration > Hub Transport > Anti-spam : disable all but Recipient Filtering Recipient Filtering > Blocked Recipients (x) Block messages sent to recipients not listed in the GAL (same as cmd "Set-RecipientFilterConfig- RecipientValidationEnabled:$true")

Exchange 2013 - 2016

https://www.mailcleaner.net/downloads/MailCleaner_Exchange_13_16.pdf

Direct Tagged messages to Spam folder

With PowerShell, you can direct Spam messages directly to a 'Spambox' folder like:

New-InboxRule -Name "spamrule" -Mailbox j.doe -MoveToFolder '[email protected]:\Spambox' -SubjectContainsWords "{Spam?}" -StopProcessingRules $True

and Newsletters to a 'Newsletter' folder like:

New-InboxRule -Name "newsletter" -Mailbox j.doe -MoveToFolder '[email protected]:\Newsletter' -SubjectContainsWords "X-Newsl: is newsletter" -StopProcessingRules $True

You can verify your rules with Powershell:

Get-InboxRule -Mailbox [email protected]

LDAP configuration

Notice

Starting from sometime in March of 2020, Microsoft is enforcing encryption for LDAP connections on all recent versions of Exchange:

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

Warning

If you are currently using LDAP without SSL for MailCleaner and any other purposes, it is possible that communication will break if you disable non-SSL communication prior to migrating all clients needed. Before proceeding, you should ensure that you enable SSL communication to Active Directory in addition to leaving regular non-SSL communication enabled. Only after you have confirmed that all MailCleaner domain and all of your other network dependencies on Active Directory have successfully migrated should you disable non-SSL LDAP (port 389).

Access

Once you have confirmed that the LDAPS service is listening, you will need to ensure that MailCleaner is able to actually reach the service. This specifically means ensuring that it is willing to accept port 636 connections from MailCleaner.

If you are confident that the port is available, skip to the next section.

If you use MailCleaner Cloud, the server needs to be available from our two ranges of IPs: 195.176.194.0/24 and 193.246.63.0/24. If you would like to verify this configuration you can request that our staff run the following test for you.

If you are using a MailCleaner Virtual Appliance,telnet allows you to open a connection to the host and port of your choice. A test will look like:

telnet your.ldaps.server 636
Trying 1.1.1.1...
Connected to your.ldaps.server.
Escape character is '^]'.

The result shown here is a successful connection. You can simply enter quit to disconnect. If the command hangs on Trying 1.1.1.1... then it appears that MailCleaner cannot reach your server on that port.

If this test does not succeed you may need to make adjustments to the Access Control List for Active Directory or check for a rule on your firewall.

Updating Existing Domains

Below are the instructions for configuring MailCleaner once you are sure that the LDAPS service is available.

If you are a Virtual Appliance user with a large number of domains and are not sure which are currently using LDAP, you can quickly get a list querying the database. To open the database connection, connect to the master database with:

/usr/mailcleaner/bin/mc_mysql -m mc_config

then run the query:

select d.name, p.auth_server from domain_pref as p join domain as d on p.id=d.prefs where p.address_fetcher = 'ldap' and (p.auth_server not like '%:636' or (p.auth_param not like '%:1:1' and p.auth_param not like '%:1:2' and p.auth_param not like '%:1:3'));

This will show you all domains that are set to use LDAP but which either do not have "enable SSL" checked, or are using a port other than 636. You must be careful if you have domains that do not use Exchange, as some of the results listed may not be required or capable of changing to use SSL.

Address Verification

Configured from: Configuration->Domains->(select Domain)->Address verification

The default method for address verification for newly created domains is an SMTP Callout, so it is possible that you may not need to make any adjustments.

However, in most versions of Exchange, SMTP Callouts do not work by default unless the DBEB (Directory Based Edge-Blocking) feature is enabled, so it is very possible that domains using Exchange have been set up with LDAP instead.

If you do have the "Callout connector" option on the "Address verification" page set to "ldap" you will need to ensure that:

  • The "LDAP server" destination defines the correct port, like:
    • 1.1.1.1:636
    • remote.mydomain.com:636
  • "Use ssl" is enabled

With these settings in place, you can submit, then use the "Test configuration" to ensure that LDAPS is both available and provides the expected reply for valid and invalid addresses.

User Authentication

Configured from: Configuration->Domains->(select Domain)->User authentication

By default, there is no User Authentication method configured for new domains, so it is possible that you may currently have User Authentication enabled at all, or you could be using an alternative method such as IMAP.

Similar to Address verification, if you are using "ldap/Active Directory" as the "Authentication type" you will need to ensure that:

  • The "Authentication server" destination defines the correct port, like:
    • 1.1.1.1:636
    • remote.mydomain.com:636
  • "Use ssl" is enabled

With these settings in place, you can submit, then use the "Test configuration" with a valid set of credentials to ensure that LDAPS configuration will allow users to log in.

New Configurations

If you have never configured LDAP(S) for your domain(s), you may not be familiar with the settings required for the other fields. It is difficult to say exactly what settings you will require, since this varies by tenant and Active Directory version. Here are some general guidelines:

Address Verification

LDAP server: remote.mydomain.com:636    // The host and port running the LDAPS service
Base DN: DC=mydomain,DC=com    // Distinguished Name; the reference to the domain within the directory
Bind user: mailcleaner    // A user account within the directory for MailCleaner to log in with; no special privileges needed; password should never expire
Bind password: p@ssw0rd    // The password for the Bind User
Use ssl: Checked    //
Only addresses in group: [blank]     // Restrict inbound email to only specific groups; probably leave blank

User Authentication

Authentication server: remote.mydomain.com:636    // The host and port running the LDAPS service
Base DN: DC=mydomain,DC=com    // Distinguished Name; the reference to the domain within the directory
Bind user: mailcleaner    // A user account within the directory for MailCleaner to log in with; no special privileges needed; password should never expire
Bind password: p@ssw0rd    // The password for the Bind User
User attribute: sAMAccountName    // The attribute used to match the authentication username; usually sAMAccountName, proxyAddresses, or mail
Use SSL: Checked    // Whether or not the port is encrypted; required for LDAPS
Protocol version: 3    // Version 2 is largely discontinued, you almost definitely want 3
Username modifier: add the domain using @ character    // How to look up the modifier to match the attribute; eg. sAMAccountName probably has no domain, proxyAddresses has the domain with an @
Address lookup: fetch address(es) from ldap directory    // How to determine which addresses the user should have access to

Useful links

https://youtu.be/JFPa_uY8NhY (How to configure and test LDAPs on 2012 Server)