We recently saw a great question on the forums from a user managing a Cisco Email Security Appliance (ESA), formerly known as IronPort. Their situation is one that every email administrator has faced or will face: a critical internal mail server goes offline.

The User’s Scenario:

“Our customer’s internal domain host is down. We use SMTP routing to communicate with the Exchange server. I want to know: will IronPort automatically retry delivery when the host status is marked as down?”

This is an excellent question that gets to the heart of how a professional-grade Mail Transfer Agent (MTA) like the Cisco ESA operates. Let’s dive deep into the answer and provide a practical guide for managing this situation.

The short answer is a resounding yes. The Cisco ESA is designed for robust and resilient mail delivery. When a destination host becomes unavailable, the appliance will automatically queue the mail and periodically retry sending it. It will not simply discard the message.

Let’s break down the process.

Understanding the “Host Down” Status

First, how does the ESA determine a host is “down”? This status is triggered when the appliance attempts to make an SMTP connection to the destination server (in this case, the internal Exchange server) and fails. Common reasons for failure include:

• Connection Refused: The server is online but the mail service (SMTP) is not running or is actively refusing connections from the ESA’s IP address.
• Connection Timed Out: The server is offline, firewalled, or under such heavy load that it cannot respond to the connection request in time.
• DNS Resolution Failure: The ESA cannot resolve the hostname of the destination server to an IP address.

Once any of these occur, the ESA intelligently marks the host’s availability state as “Down” and places all messages destined for that host into the delivery queue.

The Automatic Retry Mechanism: Queues and Bounce Profiles

This is where the power of the ESA’s delivery engine comes into play.

1. Queuing: Messages are not lost. They are safely stored in the delivery queue on the appliance.
2. Retry Schedule: The ESA does not immediately retry in a continuous loop, as this would waste resources and could overwhelm a server that is struggling to come back online. Instead, it uses a retry schedule governed by Bounce Profiles. By default, it employs an exponential back-off algorithm, meaning the time between retries gradually increases (e.g., 5 minutes, then 15, then 30, and so on).
3. Bounce Profiles: This is the key configuration area that controls retry behavior. You can find it under Mail Policies > Bounce Profiles. In the profile, you define:
   • Retry Intervals: How long to wait between delivery attempts.
   • Hard Bounce Timeout (Time to Live): The maximum amount of time a message will remain in the queue before the ESA gives up. When this limit is reached, the message is considered undeliverable, and a Non-Delivery Report (NDR or “bounce message”) is generated and sent back to the original sender. The default is typically 24 or 48 hours.

A Practical Guide: How to Monitor and Manage Queued Mail

When your destination host goes down, you have several excellent tools at your disposal to see what’s happening and manage the queue.

1. Using the GUI (Graphical User Interface)

The GUI provides a quick and clear visual of the delivery status.

• Navigate to Monitor > Delivery Status.
• Here you will see a list of “Active Recipients” in the queue.
• You can filter by the recipient host to see all messages queued for your downed Exchange server.
• The “Last Error” column will give you the specific reason for the delivery failure (e.g., “Connection refused”), confirming the issue.

2. Using the CLI (Command-Line Interface)

For many seasoned administrators, the CLI is the fastest way to get information. Log into the CLI and use these essential commands:

• tophosts: This command provides a real-time snapshot of outbound connections. You will likely see your Exchange server’s IP address with a “Down” status.

  esa.customer.com> tophosts
  
  Active Hosts (1)
  IP Address/Hostname               Status   Active   Up Time   Down Time
  -----------------------------------------------------------------------
  10.1.1.5 (exchange.internal.local)  Down     250     00:00:00   00:45:12
  

• showrecipients: This command lists the messages currently in the delivery queue. You can see the sender, recipient, and time the message has been queued.

• retryall: This is a powerful action command. Once you have confirmed that your Exchange server is back online and accepting connections, you can run retryall to force the ESA’s scheduler to immediately attempt delivery for all messages in the queue, rather than waiting for the next scheduled retry time.

3. Checking the Mail Logs

For a detailed, forensic analysis, the mail logs are your ultimate source of truth.

• You can access them from the GUI (Monitor > Mail Logs) or by tailing them from the CLI (tail mail_logs).
• Look for lines associated with the message ID (MID) that show connection attempts and failures. You will see entries clearly indicating that the connection to your destination host failed, confirming the “host down” status.

Conclusion and Best Practices

To summarize, the Cisco ESA is purpose-built to handle delivery interruptions gracefully and automatically.

• Yes, it will always retry: Mail is safely queued, and delivery is re-attempted on a configurable schedule.
• You have full visibility: Use the GUI, CLI, and logs to monitor the queue and diagnose the connection issue.
• You are in control: Once the destination server is fixed, you can let the scheduler work naturally or use the retryall command to expedite delivery.

As a best practice, we recommend periodically reviewing your Bounce Profiles to ensure the retry and timeout settings align with your organization’s policies. For a critical internal server, a longer retry window (e.g., 48 hours) is often appropriate to allow your infrastructure team ample time to resolve any issues without causing legitimate emails to bounce.

Stay confident that your Cisco ESA is working 24/7 to ensure no message is left behind.