The e-mail was sent while the recipient e-mail system was down. What I'm trying to determine is why didn't it queue up either on the sending e-mail system or on IronPort. I don't really understand the path when IronPort is involved. Anyway, my research has led me to believe the problem was caused by a TTL parameter that was too small. Do all e-mail systems use TTL? The sending e-mail system admin. says they don't have/use TTL.
How old was the message when it expired? There is no explicit TTL mechanism in SMTP, each server retries for however long it is configured. RFC 2821 recommends a minimum retry time of "at least 4-5 days" (interesting that it is so nonspecific).
Regarding "understand[ing] the path when IronPort is involved," that's going to be very installation-specific. Your mail system may be configured to route its outbound mail via your IronPort, or it may be configured to route its own outbound mail. The fact that you got an error from the IronPort implies the former. In this case, mail will stay on the appliance for the duration of its retry time. The default is 72 hours, but can be changed via a bounce profile.
The message expired within one minute of it being sent. It is being sent by a mainframe XMITIP application.
My path question is more related to how does an IronPort appliance handle the traffic. Is it a container, will the message actually be stored on the appliance if IronPort cannot connect to the recipient server? The recipient server was down at the time but why didn't the appliance hold onto it until it was available?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...