SMTP Routes allow you to redirect all email for a particular domain to a different mail exchange (MX) host. For example, you could make a mapping from example.com to groupware.example.com . This mapping causes any email with @example.com in the Envelope Recipient address to go instead to groupware.example.com . The system performs an “MX” lookup on groupware.example.com , and then performs an “A” lookup on the host, just like a normal email delivery. This alternate MX host does not need to be listed in DNS MX records and it does not even need to be a member of the domain whose email is being redirected. The AsyncOS operating system allows up to forty thousand (40,000) SMTP Route mappings to be configured for your email gateway. (See SMTP Routes Limits)

This feature also allows host “globbing.” If you specify a partial domain, such as .example.com , then any domain ending in example.com matches the entry. For instance, fred@foo.example.com and wilma@bar.example.com both match the mapping.

If a host is not found in the SMTP Routes table, an MX lookup is performed using DNS. The result is not re-checked against the SMTP Routes table. If the DNS MX entry for foo.domain is bar.domain , any email sent to foo.domain is delivered to the host bar.domain . If you create a mapping for bar.domain to some other host, email addressed to foo.domain is not affected.

In other words, recursive entries are not followed. If there is an entry for a.domain to redirect to b.domain , and a subsequent entry to redirect email for b.domain to a.domain , a mail loop will not be created. In this case, email addressed to a.domain will be delivered to the MX host specified by b.domain , and conversely email addressed to b.domain will be delivered to the MX host specified by a.domain .

The SMTP Routes table is read from the top down for every email delivery. The most specific entry that matches a mapping wins. For example, if there are mappings for both host1.example.com and .example.com in the SMTP Routes table, the entry for host1.example.com will be used because it is the more specific entry — even if it appears after the less specific .example.com entry. Otherwise, the system performs a regular MX lookup on the domain of the Envelope Recipient.

You can also define a default SMTP route with the special keyword ALL . If a domain does not match a previous mapping in the SMTP Routes list, it defaults to being redirected to the MX host specified by the ALL entry.

When you print the SMTP Routes entries, the default SMTP route is listed as ALL: . You cannot delete the default SMTP route; you may only clear any values entered for it.

Configure the default SMTP route via the Network > SMTP Routes page or the smtproutes command.

Use the Network > SMTP Routes page (or the smtproutes command) to construct routes. When you create a new route, you first specify the domain or partial domain for which you want to create a permanent route. You then specify destination hosts. Destination hosts can be entered as fully-qualified hostnames or as IP addresses. IP addresses can be either Internet Protocol version 4 (IPv4) or version 6 (IPv6).

For IPv6 addresses, AsyncOS supports the following formats:

• 2620:101:2004:4202::0-2620:101:2004:4202::ff
• 2620:101:2004:4202::
• 2620:101:2004:4202::23
• 2620:101:2004:4202::/64

You can also specify a a special destination host of /dev/null to drop the messages that match the entry. (So, in effect, specifying /dev/null for the default route is will ensure that no mail received by the email gateway is ever delivered.)

A receiving domain can have multiple destination hosts, each assigned a priority number, much like an MX record. The destination host with the lowest number identifies as the primary destination host for the receiving domain. Other destination hosts listed will be used as backup.

Destinations with identical priority will be used in a “round-robin” fashion. The round-robin process is based on SMTP connections, and is not necessarily message-based. Also, if one or more of the destination hosts are not responding, messages will be delivered to one of the reachable hosts. If all the configured destination hosts are not responding, mail is queued for the receiving domain and delivery to the destination hosts is attempted later. (It does not fail over to using MX records).

When constructing routes using the smtproutes command in the CLI, you can prioritize each destination host by using /pri= , followed by an integer between 0 and 65535 to assign priority ( 0 is the highest priority) after the hostname or IP address. For example, host1.example.com/pri=0 has a higher priority than host2.example.com/pri=10. Separate multiple entries with commas.

You can define up to 40,000 routes. The final default route of ALL is counted as a route against this limit. Therefore, you can define up to 39,999 custom routes and one route that uses the special keyword ALL .

Use the special keyword USEDNS to tell the email gateway to do MX lookups to determine next hops for specific domains. This is useful when you need to route mail for subdomains to a specific host. For example, if mail to example.com is to be sent to the company’s Exchange server, you might have something similar to the following SMTP route:

example.com exchange.example.com

However, for mail to various subdomains (foo.example.com), add an SMTP route that looks like this:

.example.com USEDNS

Alerts sent from the email gateway to addresses specified in the System Administration > Alerts page (or the alertconfig command) follow SMTP Routes defined for those destinations.

Incoming: if one message has 10 recipients and they are all on the same Exchange server, AsyncOS will open one TCP connection and present exactly one message to the mail store, not 10 separate messages.

Outgoing: works similarly, but if one message is going to 10 recipients in 10 different domains, AsyncOS will open 10 connections to 10 MTAs and deliver them one email each.

Splintering: if one incoming message has 10 recipients and they are each in separate Incoming Policy groups (10 groups), the message will splinter even if all 10 recipients are on the same Exchange server. Thus, 10 separate emails will be delivered over a single TCP connection.

If an Outbound SMTP Authentication profile has been created, you can apply it to an SMTP Route. This allows authentication for outgoing mail in cases where the email gateway sits behind a mail relay server that is at the edge of the network. For more information about Outbound SMTP Authentication, see Outgoing SMTP Authentication.

Use the Network > SMTP Routes page to manage SMTP Routes on your email gateway. You can add, modify, and delete mappings in the table. You can export or import the SMTP Routes entries.

Alias tables are defined in sections as follows: each section is headed by a domain context, which is a list of domains that the section is relevant to, followed by a list of maps.

A domain context is a list of one or more domains or partial domains, separated by commas and enclosed in square brackets (' [ ' and ' ] '). A domain is a string containing letters, digits hyphens, and periods as defined in RFC 1035, section 2.3.1., “Preferred name syntax.” A partial domain, such as .example.com is a domain that begins with a period. All domains that end with a substring matching the partial domain are considered a match. For example, the domain context .example.com would match mars.example.com and venus.example.com . Below the domain context is a list of maps, which are aliases followed by a list of recipients. A map is constructed as follows:

An alias in the left-hand side can contain the following formats:

You can enter multiple aliases, separated by commas on a single left-hand side line.

Each recipient in the right-hand side can be a full user@domain email address, or another alias.

An alias file can contain “global” aliases (aliases that are applied globally instead of to a specific domain) with no implied domain, domain contexts within which aliases have one or more implied domains, or both.

“Chains” (or recursive entries) of aliases may be created, but they must end in a full email address.

A special destination of /dev/null is supported to drop the message in order to be compatible with context of a sendmail configuration. If a message is mapped to /dev/null via an alias table, the dropped counter is increased. (See the “Managing and Monitoring via the CLI” chapter.) The recipient is accepted but not enqueued.

To import an alias table, first see FTP, SSH, and SCP Accessto ensure that you can access the email gateway.

Use the export subcommand of the aliasconfig command to save any existing alias table. A file (whose name you specify) will be written to the /configuration directory for the listener. You can modify this file outside of the CLI and then re-import it. (If you have malformed entries in the file, errors are printed when you try to import the file.)

Place the alias table file in the /configuration directory, and then use the import subcommand of the aliasconfig command to upload the file.

Comment out lines in the table using a number symbol (#) at the beginning of each line.

Remember to issue the commit command after you import an alias table file so that the configuration changes take effect.

If you delete entries from the alias table from the command line interface (CLI), you are prompted to choose a domain group first. Choose the “ALL (any domain)” entry to see a numbered list of aliases that apply to all domains. Then choose the number(s) of the aliases you want to delete.

Generally, the masquerading feature rewrites the Envelope Sender, and any subsequent actions to be performed on the message will be “triggered” from the masqueraded address. However, when you run the altscrchost command from the CLI, the altsrchost mappings are triggered from the original address (and not the modified, masqueraded address).

For more information, see Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™ Technologyand Review: Email Pipeline.

To import or export a domain map table, first see FTP, SSH, and SCP Accessto ensure that you can access the email gateway.

Create a text file of entries of domains to map. Separate the entries with white space (either a tab character or spaces). Comment out lines in the table using a number symbol (#) at the beginning of each line.

Place the file in the configuration directory, and then use the import subcommand of the domain subcommand to upload the file. Use the commands in this order:

 listenerconfig ->		edit -> 	inejctor_number -> domainmap -> import

Alternatively, you can use the export subcommand to download the existing configuration. A file (whose name you specify) will be written to the configuration directory. You can modify this file outside of the CLI and then import it again.

When you use the import subcommand, ensure that the file contains only valid entries. If there is an invalid entry (for example, a left-hand side with no right-hand side), the CLI reports syntax errors when you import the file. If there is a syntax error during import, no mappings in the entire file are imported.

Remember to issue the commit command after you import a domain map table file so that the configuration changes for the listener take effect.

Our Enterprise Gateway configuration now looks like this:

The AsyncOS operating system classifies undeliverable email, or “bounced messages,” into the following categories:

You use the Bounce Profiles page on the Network menu in the GUI (or the bounceconfig command) to configure how AsyncOS handles hard and soft conversational bounces for each listener you create. You create bounce profiles and then apply profiles to each listener via the Network > Listeners page (or the listenerconfig command). You can also assign bounce profiles to specific messages using message filters. (See Using Message Filters to Enforce Email Policiesfor more information.)

In the following example, a bounce profile named bouncepr1 is created using the Bounce Profiles page. In this profile, all hard bounced messages are sent to the alternate address bounce-mailbox@example.com . Delay warnings messages are enabled. One warning message will be sent per recipient, and the default value of 4 hours (14400 seconds) between warning messages is accepted.

Once you have created a bounce profile, you can apply that profile to a listener using the Network > Listeners page or the listenerconfig command.

In the following example, the bouncepr1 profile is applied to the OutgoingMail listener.

At this point, our Email Gateway configuration looks like this:

• Concurrent Connections: number of simultaneous connections to remote hosts the email gateway will attempt to open.
• Maximum Messages Per Connection: number of messages your email gateway will send to a destination domain before the email gateway initiates a new connection.
• Recipients: number of recipients the email gateway will send to a given remote host in a given time period.
• Limits: how to apply the limits you have specified on a per-destination and per MGA hostname basis.

• Whether TLS connections to remote hosts will be accepted, allowed, or required (see Controlling TLS).
• Whether to send an alert when TLS negotiation fails when delivering a message to a remote host that requires a TLS connection. This is a global setting, not a per-domain setting.
• Assign a TLS certificate to use for all outbound TLS connections to remote hosts.

• Whether or not to perform address tagging via Bounce Verification (see Bounce Verification).

• Which bounce profile should be used by the email gateway for a given remote host (the default bounce profile is set via the Network > Bounce Profiles page).

You can also control the default settings for unspecified domains.

Unless you specify the output interface via the deliveryconfig command or via a message filter ( alt-src-host ), or through the use of a virtual gateway, the output interface is selected by the AsyncOS routing table. Basically, selecting “auto” means to let AsyncOS decide.

In greater detail: local addresses are identified by applying the interface netmask to the interface IP address. Both of these are set via the Network > Interfaces page or by the interfaceconfig command (or during system setup). If the address space overlaps, the most specific netmask is used. If a destination is local, packets are sent via the appropriate local interface.

If the destination is not local, packets are sent to the default router (set via the Network > Routing page or with the setgateway command). The IP address of the default router is local. The output interface is determined by the rule for selecting the output interface for local addresses. For example, AsyncOS chooses the most specific IP address and netmask that include the default router's IP address.

The routing table is configured via the Network > Routing page (or via the routeconfig command). A matching entry in the routing table takes precedence over the default route. A more specific route take precedence over a less specific route.

Each outbound destination domain has its own outbound queue. Therefore, each domain has a separate set of concurrency limits as specified in the Destination Controls table. Further, each unique domain not listed specifically in the Destination Controls table uses another set of the “Default” limits as set in the table.

Use the Mail Policies > Destination Controls page in the GUI or the destconfig command in the CLI to create, edit, and delete Destination Control entries.

When sending email with bounce verification enabled, your email gateway will rewrite the Envelope Sender address in the message. For example, MAIL FROM: joe@example.com becomes MAIL FROM: prvs=joe=123ABCDEFG@example.com . The 123... string in the example is the “bounce verification tag” that gets added to the Envelope Sender as it is sent by your email gateway. The tag is generated using a key defined in the Bounce Verification settings (see Bounce Verification Address Tagging Keysfor more information about specifying a key). If this message bounces, the Envelope Recipient address in the bounce will typically include this bounce verification tag.

You can enable or disable bounce verification tagging system-wide as a default. You can also enable or disable bounce verification tagging for specific domains. In most situations, you would enable it by default, and then list specific domains to exclude in the Destination Controls table (see Working with Destination Controls).

If a message already contains a tagged address, AsyncOS does not add another tag (in the case of an email gateway delivering a bounce message to an email gateway inside the DMZ).

By default, the system uses an IP interface or IP interface group for email delivery. Any currently configured IP interface or IP interface group can be set. If no specific interface is identified, AsyncOS will use the hostname associated with the default delivery interface in the SMTP HELO command when communicating with recipient hosts. To configure IP interfaces, use the interfaceconfig command.

These are the rules for using Auto selection of email delivery interfaces:

• If the remote email server is on the same subnet as one of the configured interfaces, then traffic will go out on the matching interface.
• When set to auto-select, static routes you have configured using routeconfig take effect.
• Otherwise, the interface that is on the same subnet as the default gateway will be used. If all of the IP addresses have an equivalent route to the destination, then the system uses the most efficient interface available.

Caution

If you enable this feature, message delivery will not be reliable and may lead to loss of messages. Also, your email gateway will not be RFC 5321-compliant. For more information, see http://tools.ietf.org/html/rfc5321#section-6.1..

When the Possible Delivery feature is enabled, AsyncOS treats any message that times-out after the body of the message is delivered, but before recipient host acknowledges receipt of the message, as a “possible delivery.” This functionality prevents recipients from receiving multiple copies of a message if continuous errors at their recipient host prevent acknowledgment of receipt. AsyncOS logs this recipient as a possible delivery in the mail logs and counts the message as completed.

You also specify the default maximum number of concurrent connections the email gateway makes for outbound message delivery. (The system-wide default is 10,000 connections to separate domains.) The limit is monitored in conjunction with the per-listener maximum outbound message delivery concurrency (the default per listener is 600 connections for private listeners and 1000 connections for public listeners). Setting the value lower than the default prevents the gateway from dominating weaker networks. For example, certain firewalls do not support large numbers of connections, and this could induce Denial of Service (DoS) warnings in these environments.

In the following example, the deliveryconfig command is used to set the default interface to “Auto” with “Possible Delivery” enabled. The system-wide maximum outbound message delivery is set to 9000 connections.

mail3.example.com> deliveryconfig


Choose the operation you want to perform:

- SETUP - Configure mail delivery.

[]> setup

Choose the default interface to deliver mail.

1. Auto

2. PublicNet2 (192.168.3.1/24: mail4.example.com)

3. Management (192.168.42.42/24: mail3.example.com)

4. PrivateNet (192.168.1.1/24: mail3.example.com)

5. PublicNet (192.168.2.1/24: mail3.example.com)


[1]> 1

Enable "Possible Delivery"? [Y]> y

Please enter the default system wide maximum outbound message delivery

concurrency

[10000]> 9000

mail3.example.com>

Our Email Gateway configuration now looks like this:

Cisco has developed a unique Virtual Gateway technology designed to help ensure that corporations can reliably communicate with their customers via email. Virtual Gateway technology enables users to separate the email gateway into multiple Virtual Gateway addresses from which to send and receive email. Each Virtual Gateway address is given a distinct IP address, hostname and domain, and email queue.

Assigning a distinct IP address and hostname to each Virtual Gateway address ensures that email delivered through the gateway will be properly identified by the recipient host and prevents critical email from being blocked as spam. The email gateway has the intelligence to give the correct hostname in the SMTP HELO command for each of the Virtual Gateway addresses. This ensures that if a receiving Internet Service Provider (ISP) performs a reverse DNS look-up, the email gateway will match the IP address of the email sent through that Virtual Gateway address. This feature is extremely valuable, because many ISPs use a reverse DNS lookup to detect unsolicited email. If the IP address in the reverse DNS look-up does not match the IP address of the sending host, the ISP may assume the sender is illegitimate and will frequently discard the email. The Cisco Virtual Gateway technology ensures that reverse DNS look-ups will always match the sending IP address, preventing messages from being blocked accidentally.

Messages in each Virtual Gateway address are also assigned to a separate message queue. If a certain recipient host is blocking email from one Virtual Gateway address, messages intended for that host will remain in the queue and eventually timeout. But messages intended for the same domain in a different Virtual Gateway queue that is not being blocked will be delivered normally. While these queues are treated separately for delivery purposes, the system administration, logging and reporting capability still provide a holistic view into all Virtual Gateway queues as if they were one.

Before setting up the Cisco Virtual Gateway addresses, you must allocate a set of IP addresses that will be used to send email from. (For more information, see the “Assigning Network and IP Addresses” appendix.) You should also ensure proper configuration of your DNS servers so that the IP address resolves to a valid hostname. Proper configuration of DNS servers ensures that if the recipient host performs a reverse DNS lookup, it will resolve to valid IP/hostname pairs.

While each Virtual Gateway address has its own email queue for delivery purposes, the system administration, logging, and reporting capabilities still provide a holistic view into all Virtual Gateway queues as if they were one. To monitor the recipient host status for each Virtual Gateway queue, use the hoststatus and hostrate command. See the “Reading the Available Components of Monitoring” section in the “Managing and Monitoring Using the CLI” chapter.

The hoststatus command returns monitoring information about email operations relating to a specific recipient host.

If you are using Virtual Gateway technology, information about each Virtual Gateway address is also displayed. The command requires you to input the domain of the host information to be returned. DNS information stored in the AsyncOS cache and the last error returned from the recipient host is also given. Data returned is cumulative since the last resetcounters command.

The statistics returned are grouped into two categories: counters and gauges. In addition, other data returned include: last activity, MX records, and last 5XX error.

Certain system parameters require settings at the system and Virtual Gateway address levels.

For example, some recipient ISPs limit the number of connections they allow for each client host. Therefore, it is important to manage relationships with the ISPs, especially when email is being delivered over multiple Virtual Gateway addresses.

See Controlling Email Delivery Using Destination Controlsfor information about the destconfig command and how Virtual Gateway addresses are affected.

When you create a “group,” of Virtual Gateway addresses, the good neighbor table settings for Virtual Gateway are applied to the group, even if the group consists of 254 IP addresses.

For example, suppose you have created group of 254 outbound IP addresses set up as a group to cycle through in a “round-robin” fashion, and suppose the good neighbor table for small-isp.com is 100 simultaneous connections for the system and 10 connections for Virtual Gateway addresses. This configuration will never open more than 10 connections total for all 254 IP addresses in that group; the group is treated as a single Virtual Gateway address.

In this example, the address user@example.net is added to the Global Unsubscribe list, and the feature is configured to hard bounce messages. Messages sent to this address will be bounced; the email gateway will bounce the message immediately prior to delivery.

mail3.example.com> unsubscribe


Global Unsubscribe is enabled. Action: drop.

Choose the operation you want to perform:

- NEW - Create a new entry.

- IMPORT - Import entries from a file.

- SETUP - Configure general settings.

[]> new

Enter the unsubscribe key to add. Partial addresses such as

"@example.com" or "user@" are allowed, as are IP addresses. Partial hostnames such as

"@.example.com" are allowed.

[]> user@example.net

Email Address 'user@example.net' added.

Global Unsubscribe is enabled.

Choose the operation you want to perform:

- NEW - Create a new entry.

- DELETE - Remove an entry.

- PRINT - Display all entries.

- IMPORT - Import entries from a file.

- EXPORT - Export all entries to a file.

- SETUP - Configure general settings.

- CLEAR - Remove all entries.

[]> setup

Do you want to enable the Global Unsubscribe feature? [Y]> y

Would you like matching messages to be dropped or bounced?

1. Drop

2. Bounce

[1]> 2

Global Unsubscribe is enabled. Action: bounce.

Choose the operation you want to perform:

- NEW - Create a new entry.

- DELETE - Remove an entry.

- PRINT - Display all entries.

- IMPORT - Import entries from a file.

- EXPORT - Export all entries to a file.

- SETUP - Configure general settings.

- CLEAR - Remove all entries.

[]>


mail3.example.com> commit

Please enter some comments describing your changes:

[]> Added username “user@example.net” to global unsubscribe

Do you want to save the current configuration for rollback? [Y]> n

Changes committed: Fri May 23 11:42:12 2014 GMT