Community Knowledge Base

Gateway Setup in SmarterMail

Gateways perform a crucial function when running mail servers, especially in very busy environments. Their primary mission is to handle the flow of inbound or outbound traffic, ensuring timely and proper delivery of messages. They also offload the processing of messages, easing the work done by the actual SmarterMail server. As such, they handle the majority of the traffic sending and/or delivering email to its intended recipients.

SmarterMail simplifies the ability to set up and configure gateways, allowing administrators to quickly and easily set up both inbound and outbound gateways. If any gateways have already been created, they will be displayed on the Gateways tab. If no gateways exist, this tab will be blank.

Types of Gateway

There are essentially two types of gateway: Inbound and Outbound.

Outbound Gateways

There are two Outbound Gateway modes: Round Robin and Specific Domains. Outbound gateways handle the pre-processing of messages prior to them being sent off to recipient email servers. This pre-processing can include antispam and anti-malware checks. Outbound gateways can also be used for more granular email processing like the configuration of throttling limits. For example, if a hosting provider has a particular email plan targeted towards email marketers, these domains can be funneled through a particular outgoing gateway that throttles the ability to send emails from these domains to a set number to mitigate the potential for the domains to become blacklisted.

Round Robin means that when multiple gateways are configured for round robin, outbound mail cycles through them one after another in sequence, distributing the load evenly across all of them regardless of which domain the mail is coming from. Specific Domains instead lets an administrator pin one particular domain's outbound mail to one particular gateway, bypassing the round-robin rotation for that domain. As a worked example, consider a hosting provider running three outbound gateways in Round Robin mode: with dozens of customer domains sending through them, outbound connections simply cycle 1, 2, 3, 1, 2, 3... spreading volume (and reputation risk) evenly across all three regardless of which domain sent the message. Now suppose one of those customer domains is a high-volume email marketing operation whose sending patterns are far more likely to draw spam complaints or an RBL listing than the rest of the customer base. That single domain can instead be switched to Specific Domains mode and assigned its own dedicated gateway, isolating its reputation risk so that a blacklisting event affecting the marketing domain's gateway doesn't touch the round-robin pool the other, better-behaved domains are using. This is the same reputation-isolation logic that applies to assigning a domain its own dedicated outbound IP address, just applied one layer further out at the gateway level instead of the IP level.

A domain is assigned to a specific gateway from that domain's own settings, not from the Gateways list itself: on the domain's Domain Settings > General Settings page, the Outgoing card includes an Outbound Gateway dropdown listing None, Round Robin (if a round-robin gateway exists), and every gateway configured for Specific Domains mode by its address. Selecting one of those specific gateways here is what pins the domain to it. A companion switch, Use Primary IP on Failure, appears once a specific gateway is selected; enabling it means that if the assigned gateway becomes disabled or unreachable, the domain's outbound mail automatically falls back to the round-robin pool instead of simply failing to send.

Inbound Gateways

There are two types of inbound gateway: Backup MX and Domain Forward. In both cases, the purpose of an inbound gateway is to reduce server load by pre-processing incoming messages prior to the messages being handed off for delivery to the primary SmarterMail server. For example, spam checks and antivirus scans can be performed by these types of gateways, especially in larger environments, as they are standalone servers that simply process incoming messages, so they don't act as primary mail servers. This frees up the primary server so all it has to do is deliver messages to individual users.

A Backup MX gateway is intended to receive mail only when the primary server is unreachable. It's important to understand that SmarterMail itself performs no active health check of the primary server to make this happen — there is no polling, heartbeat, or "is the primary down?" logic running anywhere in the product. Backup MX is entirely a function of standard DNS MX-priority behavior: the administrator publishes a second MX record for the domain pointing at the Backup MX gateway server with a higher priority number (a lower-priority preference) than the record pointing at the primary server. Per ordinary SMTP client behavior, every well-behaved sending server already tries MX records in ascending priority order and only falls through to the higher-numbered backup record when the lower-numbered one refuses the connection or times out. SmarterMail doesn't create or enforce that behavior; it simply benefits from it once the DNS records are set up correctly. What SmarterMail's Backup MX gateway does do on its own is use the Backup MX Address Range configured on the gateway record to help the primary server recognize mail that arrived by way of that path: when the primary server sees a message for a domain whose MX record resolves to an IP address inside that configured range, it treats the message as local rather than trying to re-deliver it externally, since the range identifies the Backup MX gateway's own address rather than a competing external mail server.

A Domain Forward gateway allows you to easily send mail through one server to another and permit you to have a single point of entry for inbound SMTP traffic. A common real-world layout is a large ISP or hosting provider that publishes MX records for many customer domains pointing at one public-facing gateway server; that gateway performs spam and antivirus pre-filtering on everything arriving for those domains, then forwards only the clean mail onward to the actual mailbox server (or servers) sitting behind it, which never has to be exposed directly to the internet at all. When messages come in for a forwarded domain, they are handled just like any other incoming message once they reach the primary server, which includes being subject to the general Spool settings for that server (i.e., Settings > General Settings > Spool). For example, if a delivery delay has been configured for the server, forwarded messages are subject to that same delay just like any other inbound mail. In addition, because the Domain Forward gateway can run its own external virus or spam scanners ahead of the primary server, it reduces the antispam and antivirus processing load that would otherwise fall entirely on the primary server.

Adding Gateways

To add a new gateway, click the New button on the Gateways tab. When adding or editing an entry, the following cards and settings will be available:

Options

  • Server Address - The IP address or hostname of the gateway server. (When the gateway's Inbound Mode is set to Backup MX further down the page, this field changes to Backup MX Address Range and instead accepts an IP address range, since a Backup MX gateway is identified by the range of addresses its MX record resolves to rather than a single hostname to connect to.)
  • Port - The port used to connect to the gateway server.
  • Description - A detailed, yet friendly description for the type of gateway set up, its purpose, etc.
  • Enable SMTPUTF8 - Toggle this to enable the use of UTF-8 encoding (i.e., non-ASCII) for email addresses, message headers, subject lines, etc. for SMTP traffic.
  • Enable SmarterMail Gateway Mode - Select this option to indicate that the gateway being set up is another SmarterMail server. Turning this on unlocks several capabilities that only make sense when the gateway is known to be a SmarterMail instance:
    • Live spool message count monitoring for the gateway, shown in the Spool Count column on the main Gateways list (a non-SmarterMail gateway always shows this column as N/A).
    • The Web Service option for inbound User Verification Mode and the All (Web Service) option for inbound Domain Verification, both described below, which query the primary server's SmarterMail web services for valid users and domains rather than relying on a static list.
    • A Verify Connection before Save test (below) that authenticates against the remote server's ServerAdmin web service using the SmarterMail Username and Password entered here, in addition to the plain SMTP connection test.
  • SmarterMail URL - The webmail URL for the SmarterMail server the gateway is being set up for. For example, you have one SmarterMail server being set up as a Domain Forward "inbound" gateway (e.g., gateway1.example.com), and it's forwarding mail to a domain (or to domains) on a separate SmarterMail server (e.g., mail1.example.com). The information input as the "SmarterMail URL" will be the primary URL for the SmarterMail server the gateway will forward email to, or https://mail1.example.com. Use of a SmarterMail gateway allows administrators the ability to use web services to verify the users and domains, if needed.
    Note: SmarterMail uses a cache of the domains and users on a server, so if there are any changes (e.g., additions, modifications like enabling/disabling users or domains, or deletions) these changes may not be reflected for up to 10 minutes until the cache is refreshed.
  • SmarterMail Username - The identifier used to log in to the SmarterMail server.
  • SmarterMail Password - The corresponding password used to log in to the SmarterMail server.
  • Verify Connection before Save - Enabling this means SmarterMail will test the connection to the Server Address and Port prior to actually connecting to the gateway.

Outbound Gateway

  • Enable Outbound - Toggle this to set up an outbound gateway. This is unavailable if the same gateway record's Inbound Mode is set to Backup MX, since a Backup MX gateway cannot also relay outbound mail.
  • Outbound Mode - Select the type of outbound gateway to set up: Round Robin or Specific Domains, as described above under Types of Gateway.
  • Encryption - Select the type of encryption used for the connection to the gateway server, from the list of None, SSL/TLS, or StartTLS.
  • Enable Authentication - Enable this setting if the outbound gateway server itself requires the sending SmarterMail server to log in before it will relay mail — this is authentication between this SmarterMail server and the gateway server, not the SMTP authentication an end user performs when submitting a message. Then enter the Auth Username and Password below.
  • Auth Username - The authorized username of the gateway server.
  • Auth Password - The corresponding password for the authorized username.
  • Verify Connection before Save - Enabling this means SmarterMail will test the connection to the Server Address and Port prior to actually connecting to the gateway.

Inbound Gateway

  • Enable Inbound - Toggle this to set up an inbound gateway.
  • Inbound Mode - Select the type of inbound gateway to set up: Domain Forward or Backup MX, as described above under Types of Gateway. Switching to Backup MX disables this gateway's outbound functionality (if enabled) and changes the Server Address field, above, into the Backup MX Address Range field.
  • User Verification Mode - The method used by the inbound gateway to determine whether a recipient is a valid user before accepting the message:
    Note: If None is selected, the inbound gateway accepts mail for any address at the domain without checking whether the mailbox actually exists; this is the fastest option at the gateway, but any invalid address then has to be caught later — typically bouncing or generating a non-delivery report only after the message has already consumed resources traveling all the way to the primary server. If Web Service is selected (available only when SmarterMail Gateway Mode is enabled above), the inbound gateway checks the primary server's cached list of valid users and domains, obtained via web service, which is generally the most accurate option but is subject to the up-to-10-minute cache delay noted above. If SMTP is selected (available only when Inbound Mode is Domain Forward, not Backup MX), the gateway performs a live, real-time recipient-verification handshake with the primary server during the incoming SMTP session itself before deciding whether to accept the message.
  • Domain Verification - Used for Domain Forward only, this allows an administrator to select whether specific domains will be handled by the forward (Specified Domains), all domains BUT specific domains will be handled by the forward (All But Specified Domains), or whether the primary server's web service will be consulted to determine which domains it hosts (All (Web Service), available only when SmarterMail Gateway Mode is enabled above).
  • Domains - Used for Domain Forward only, this is the list of specific domains handled by the gateway or, conversely, the list of domains NOT handled by the gateway, depending on the Domain Verification that's set. This list goes away when the Domain Verification is set to All (Web Service).
  • Enable Spam Checks - As Backup MX or Domain Forward gateways act on mail coming into the server, it's possible to specify the action taken for messages the gateway classifies as spam at the Low, Medium, or High level, as well as messages that come back with no spam classification at all. When toggled on, a new Inbound Spam Checks card displays with a mini-card for each of those four tiers; clicking one opens a dialog to choose its action — No Action, Add Text to Subject, Add Header, Reroute Message (to another address), Delete Message, or Pass Score to SmarterMail (forward the calculated spam score to the primary server instead of the gateway acting on it directly). Rejecting or quarantining obvious spam at this stage, before it is ever handed off to the primary server, keeps that spam out of the primary server's spool entirely, which is exactly the kind of load-reduction an inbound gateway is meant to provide.