Cisco Cisco Email Security Appliance C160 Mode D'Emploi
2-38
Cisco IronPort AsyncOS 7.6 for Email Advanced Configuration Guide
OL-25137-01
Chapter 2 Configuring Routing and Delivery Features
Hard Bounces and the status Command
When hard bounce message generation is enabled, the following counters in the
status
and
status
detail
commands increment each time the appliance generates a hard bounce message for delivery:
For more information, see “Monitoring and Managing via the CLI” in the Cisco IronPort AsyncOS for
Email Daily Management Guide. When hard bounce message generation is disabled, none of these
counters increments when a recipient hard bounces.
Email Daily Management Guide. When hard bounce message generation is disabled, none of these
counters increments when a recipient hard bounces.
Note
The Envelope Sender address of the message envelope is different than the From: in the message headers.
Cisco IronPort AsyncOS can be configured to send hard bounce messages to an email address different
than the Envelope Sender address.
Cisco IronPort AsyncOS can be configured to send hard bounce messages to an email address different
than the Envelope Sender address.
Conversational Bounces and SMTP Routes Message Filter actions
Mappings for SMTP Routes and message filter actions are not applied to the routing of SMTP bounce
messages generated by the appliance as a result of a conversational bounce. When an Cisco IronPort
appliance receives a conversational bounce message, it generates an SMTP bounce message back to the
Envelope Sender of the original message. In this case, the appliance is actually generating the message,
so any SMTP Routes that apply to an injected message for relaying do not apply.
messages generated by the appliance as a result of a conversational bounce. When an Cisco IronPort
appliance receives a conversational bounce message, it generates an SMTP bounce message back to the
Envelope Sender of the original message. In this case, the appliance is actually generating the message,
so any SMTP Routes that apply to an injected message for relaying do not apply.
Initial number of
seconds to wait before
retrying an
unreachable host
seconds to wait before
retrying an
unreachable host
The amount of time the system should wait before
retrying a host that is unreachable. The default is 60 seconds.
Max interval allowed
between retries to an
unreachable host
between retries to an
unreachable host
The maximum amount of time the system should wait before retrying a host that
is unreachable. The default is 3,600 seconds (1 hour). When the delivery initially
fails due to the host being down, it will start with the minimum number of
seconds retry value, and for each subsequent retry to the downed host, will
increase the duration, up to this maximum number of seconds value.
is unreachable. The default is 3,600 seconds (1 hour). When the delivery initially
fails due to the host being down, it will start with the minimum number of
seconds retry value, and for each subsequent retry to the downed host, will
increase the duration, up to this maximum number of seconds value.
Table 2-5
Bounce Profile Parameters (Continued)
Counters: Reset Uptime Lifetime
Receiving
Messages Received 0 0 0
Recipients Received 0 0 0
Gen. Bounce Recipients 0 0 0