Open main menu

Halon, SMTP software for hosting providers β

Recipient filtering

Recipient filtering is a crucial part of modern e-mail filtering. All edge (fronting) mail gateways should be aware of all e-mail accounts inside the organization in order to prevent backscatter. Our system is a bit different in the sense that it can operate in a "transparent" fashion by performing in-line delivery. By doing so, the problem of backscatter is totally eliminated, without recipient filtering. It might still be useful however, in order to reject invalid recipients before processing the entire message (DATA).

If you configure an SMTP gateway without recipient filtering nor in-line delivery, you might face;

  • Backscatter; if messages to unknown recipient aren't rejected in the front-end, bounces (DSN) will most likely be generated on the backend servers and you may cause DSN spam to originate from within your organization
  • Exceeded license; the system's paid license is per e-mail recipient (users accounted for in your license may be seen on the Operations > Licenses page)

Recipient filtering policies are set per domain and are defined with a RCPT TO flow. The recipient flow policy comes with some pre-configured blocks that should be preferred over custom scripts. Among these the simplest which is also enabled by default is SMTP forwarding verification.


SMTP forwarding verification

A SMTP forwarding verification will be done (MAIL FROM: <>, RCPT TO: <[email protected]>) to verify against your backend SMTP server. By default, valid users are cached for 24 hours.

Many mail servers are configured to accept any e-mail address (such as [email protected], even if such a user does not exist). In order for the license not to exceed, this behavior should be disabled. The phenomenon are sometimes referred to as catch-all. Also make sure that the e-mail server does not "trust" the mail gateway: sometimes servers accept any e-mails from computers with internal addresses. The user count is reset whenever the appliance is restarted.

Microsoft Exchange

Recipient filtering is a part of Exchanges anti-spam functionality, and therefore requires the anti-spam agents to be installed; so if they are not follow the guide for your Exchange version that is linked below. This could be the case if you're not using a Edge Transport server and instead deliver e-mail directly to a Hub transport server. Once you have verified that it is installed, make sure that the "Recipient filtering" agent is enabled and configured to block inbound messages sent to recipients that do not exist in the directory. Also make sure that you disable all other anti-spam agents. This is important because the Exchange server should trust the VSP and should not reject (causing the VSP to bounce) any messages due to those anti-spam agents.

Guide for Exchange 2003

Guide for Exchange 2007

Guide for Exchange 2010

Microsoft Exchange 2013

In Exchange 2013 it's no longer possible to use SMTP forwarding verification unless you deliver e-mail to a Edge Transport server. The reason for this is that while you can still install Anti-spam agents and enable "Recipient filtering" on Mailbox servers in Exchange 2013 they no longer block inbound messages to invalid recipients during the RCPT-TO phase, instead they do so after the DATA phase. If you do have a Edge Transport server running Exchange 2013, SMTP forwarding verification will work just as it did before if the "Recipient filtering" agent is enabled and configured to do so. The recommended solution if you only have a CAS/Mailbox server is currently to use either LDAP or In-line delivery instead. Note that when using In-line delivery to a CAS/Mailbox server you still need to have "Recipient filtering" enabled on the Mailbox server for the filtering to work, and if a message has one or more invalid recipients it will be rejected for all recipients due to the reasons mentioned above.

Guide for Exchange 2013

LDAP verification

We don't normally recommend using LDAP for recipient verification except in some particular cases such as with Microsoft Exchange 2013. The reason for this is that it adds unnecessary complexity and sometimes have limitations in how it handles aliases.