• 256 Virtual Gateway Addresses - The Cisco Virtual Gateway technology allows you to configure enterprise mail gateways for all domains you host — with distinct IP addresses, hostname and domains — and create separate corporate email policy enforcement and anti-spam strategies for those domains, while hosted within the same physical email gateway. See information about “Customizing Listeners” in Configuring the Gateway to Receive Email
• IronPort Mail Merge (IPMM) - IronPort Mail Merge (IPMM) removes the burden of generating individual personalized messages from customer systems. By removing the need to generate thousands of individual messages and transmit them between message generating systems and the email gateway, users benefit from the decreased load on their systems and increased throughput of email delivery. For more information, see Sending Bulk Mail Using IronPort Mail Merge (IPMM).
• Resource-conserving bounce setting - You can configure D-Mode-enabled email gateways to detect potential blocked destinations and bounce all messages bound for that destination. For more information, see Configuring Resource-Conserving Bounce Settings.
• Enhanced performance for outbound delivery

• IronPort anti-spam scanning and on or off box spam quarantining — Because anti-spam scanning pertains mostly to incoming mail, the IronPort Anti-Spam scanning engine is disabled. The Anti-Spam chapter is, therefore, not applicable.
• Outbreak Filters — Because the Outbreak Filters feature is used to quarantine incoming mail, this feature is disabled on D-Mode-enabled email gateways. Information in the Outbreak Filters chapter is, therefore, not applicable.

• Service Logs - The Service Logs feature is disabled on D-mode enabled email gateways.

• Reporting — Reporting is limited. Some reports are not available, and the reporting that does occur is set to run at a very limited level for performance reasons.

Note	The totals shown in the Email Security Monitor Overview report for D-Mode-enabled email gateways may erroneously include spam and suspect spam counts, even though these features are disabled on D-Mode-enabled email gateways.

• Data Loss Prevention — DLP scanning for outgoing messages is disabled on D-Mode-enabled email gateways.

IronPort Mail Merge removes the burden of generating individual personalized messages from customer systems. It removes the need to generate thousands of individual messages and transmit them between message generating systems and the email gateway, resulting in decreased load on your systems and increased throughput of email delivery.

With IPMM, a single message body is created with variables representing locations in the message to be replaced for personalization. For each individual message recipient, only the recipient email address and the variable substitutions need to be transmitted to the email gateway. In addition, IPMM can be used to send certain recipients specific “parts” of the message body, while excluding certain parts from others recipients. (For example, suppose you needed to include a different copyright statements at the end of your messages to recipients in two different countries.)

• Ease of use for the mail administrator. The complexities of creating personalized messages for each recipient are removed, as IPMM provides variable substitution and an abstracted interface in many common languages.

• Reduced load on message generation systems. By requiring one copy of the message body and a table of required substitutions, most of the message generation “work” is off-loaded from message generation systems and moved to the email gateway that is configured for optimized outbound mail delivery.

• Increased delivery throughput. By reducing the resources necessary to accept and queue thousands of incoming messages, the email gateway can significantly increase out-bound delivery performance.

• Queue storage efficiency. By storing less information for each message recipient, users can achieve orders-of- magnitude, better use of queue storage on the D-Mode enabled email gateway.

When a client injects IPMM messages to the listener, it uses extended SMTP with the following key commands.

• When you define variables with the XDFN command, note that the actual command line cannot exceed the physical limit of the system. In the case of the D-Mode-enabled email gateway, this limit is 4 kilobytes per line. Other host systems may have lower thresholds. Use caution when defining multiple variables on very large lines.
• You can escape special characters using the forward slash “ / ” character when defining variables key-value pairs. This is useful if your message body contains HTML character entities that might be mistakenly replaced with variable definitions. (For example, the character entity ™ defines the HTML character entity for a trademark character. If you created the command XDFN trade=foo and then created a IPMM message containing the HTML character entity “ ™ ” the assembled message would contain the variable substitution (“ foo ”) instead of the trademark character. The same concept is true for the ampersand character “&” which is sometimes used in URLs containing GET commands.

The following is an example IPMM conversation of Example Message #2 (shown above). The message will be sent to two recipients in this example: “Jane User” and “Joe User.”

In this example, the type in bold represents what you would type in a manual SMTP conversation with the D-Mode-enabled email gateway, type in monospaced type represents the responses from the SMTP server, and italic type represents comments or variables.

A connection is established:

220 ESMTP


EHLO foo


250 - ehlo responses from the listener enabled for IPMM

The conversation is started:

XMRG FROM:<user@domain.com> [Note: This replaces the MAIL FROM: SMTP command.]

250 OK

Variables and parts are set for each recipient:

XDFN first_name="Jane" last_name="User" color="red" *PARTS=1,2

[Note: This line defines three variables (first_name, last_name, and color) and then
uses the *PARTS reserved variable to define that the next recipient defined will receive
message parts numbers 1 and 2.]

250 OK

RCPT TO:<jane@company.com>

250 recipient <jane@company.com> ok

XDFN first_name="Joe" last_name="User" color="black" *PARTS=1

[Note: This line defines three variables (first_name, last_name, and color) and then
uses the *PARTS reserved variable to define that the next recipient defined will receive
message parts numbers 1 only.]

RCPT TO:<joe@company1.com>

250 recipient <joe@company1.com> ok

Next, part 1 is transmitted:

XPRT 1 [Note: This replaces the DATA SMTP command.]

354 OK, send part

From: Mr. Spacely <spacely@example.com>

To: &first_name; &last_name; &*TO;

Subject: Thanks for Being an Example.Com Customer

&*DATE;

Dear &first_name;,

Thank you for purchasing a &color; sprocket.

.

And then part 2 is transmitted. Note that the LAST keyword is used to identify Part 2 as the final part to assemble:

XPRT 2 LAST

Please accept our offer for 10% off your next sprocket purchase.

.

250 Ok, mailmerge message enqueued

The “250 Ok, mailmerge message queued” notes that the message has been accepted.

Based on this example, recipient Jane User will receive this message:

From: Mr. Spacely <spacely@example.com>


To: Jane User <jane@company.com>


Subject: Thanks for Being an Example.Com Customer



message date

Dear Jane,



Thank you for purchasing a red sprocket.

Please accept our offer for 10% off your next sprocket purchase.

Recipient Joe User will receive this message:

From: Mr. Spacely <spacely@example.com>


To: Joe User <joe@company1.com>


Subject: Thanks for Being an Example.Com Customer


message date


Dear Joe,

Thank you for purchasing a black sprocket.