cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4653
Views
0
Helpful
7
Replies

Destination domain down

IIAGDTRnSC
Level 1
Level 1

I am having a problem with one destination domain being shown as down quite often from the Ironport C100. If I use a webmail account to send mail to the domain it gets delivered. I am trying to send mail to: LS3P.COM.

I assume this is a DNS problem. If I reboot my C100 usually the problem disappears for a while and then returns.

Advice on fixes? I am using my ISP's DNS server. I have put in a manual SMTP route for LS3P mail server (they have two MX records but apparently only one us being used, this might be part of the problem) to see if that helps.

Troubleshooting ideas?

7 Replies 7

First off all, rebooting is a bit brute force. You want to use dnsflush on the CLI and delivernow after that. As the same effect for this issue.

It does sound a lot like a DNS problem. When you have the issue do a nslookup on the IronPort for their MX record an have a look what is going on.

Also when you run tophost, how many bounces do you have for this domain?

Regards,

Mark

IIAGDTRnSC
Level 1
Level 1

When I've done lookups or checked them via dnsstuff.com they are reported as being up, whereas tophosts or Delivery Status shows them as being down. This made me think it had something to do with DNS at my ISP.

This seems to be transitional, I haven't had the problem in about 48 hours now.

[quote:0c93749547="Mark [CSE]"]First off all, rebooting is a bit brute force. You want to use dnsflush on the CLI and delivernow after that. As the same effect for this issue.

It does sound a lot like a DNS problem. When you have the issue do a nslookup on the IronPort for their MX record an have a look what is going on.

Also when you run tophost, how many bounces do you have for this domain?

Regards,

Mark

IIAGDTRnSC
Level 1
Level 1

It's odd this problem affects this single domain. It simply will not show as up until I do a clear DNS cache. Then within a minute or so it is down again. I try 'delivernow' to the domain when it claims to be up but it almost immediately goes down again. I can only seem to make it deliver after a reboot of the appliance. Curious!


[quote:34b9ecb99a="Mark [CSE]"]First off all, rebooting is a bit brute force. You want to use dnsflush on the CLI and delivernow after that. As the same effect for this issue.

It does sound a lot like a DNS problem. When you have the issue do a nslookup on the IronPort for their MX record an have a look what is going on.

Also when you run tophost, how many bounces do you have for this domain?

Regards,

Mark

I like to add one thing. We change the report status only after a retry.

IronPort AsyncOS follows a simple algorithm to determine how long to wait before the next delivery attempt after a soft bounce event. This period of time is referred to as the retry interval. The retry interval is determined as follows:

(secs since message injection) x 2 = (secs until next delivery attempt)

The first time that a recipient is soft bounced, the retry interval is set to the initial retry interval; this value can be configured by the user. The user should set the initial retry time to a high value to reduce the frequency of soft bounce attempts. To increase the frequency, the value should be lowered. By default the initial retry time is set to sixty (60) seconds.

The retry interval is limited on the high end by the maximum retry interval, this value can also be configured by the user. If the calculated retry interval period exceeds the maximum retry interval then the maximum retry interval is used instead.

IIAGDTRnSC
Level 1
Level 1

Okay...the mail log shows this:

Wed Nov 7 08:29:58 2007 Info: Connection Error: DCID: 235711 domain: ls3p.com IP: 63.239.83.197 port: 25 details: [Errno 54] Connection reset by peer interface: xxx.xxx.xxx.xxx reason: network error

Again, I am only having a problem with this single mail domain, so I don't know why it is causing this one problem that is only resolved from an appliance reboot.

Btw I did change the next delivery attempt to be 120s without any difference.

[quote:0c99a24709="Mark [CSE]"]I like to add one thing. We change the report status only after a retry.

IronPort AsyncOS follows a simple algorithm to determine how long to wait before the next delivery attempt after a soft bounce event. This period of time is referred to as the retry interval. The retry interval is determined as follows:

IIAGDTRnSC
Level 1
Level 1

[quote:2ee42c0eb3="Mark [CSE]"]

The retry interval is limited on the high end by the maximum retry interval, this value can also be configured by the user. If the calculated retry interval period exceeds the maximum retry interval then the maximum retry interval is used instead.

I found that by changing the "Maximum Interval Allowed Between Retries to an Unreachable Host:" in the Bounce Profile/Global settings to 120s (180s worked as well) that the mail would get delivered. A tech friend of mine thought it might be their PIX causing the specific problem.

Simple fix, took a long time to track down tho. I wanted to post this in case anyone else has a similar problem.

- Richard

Mark,

I saw a similar problem years ago with plain old postfix. Same scenario, could not send to one particular mail destination. The problem turned out to be a router/firewall at the client's premises that was fragmenting the packets just before delivery to the MTA. The smtp connection setup never completed, so the remote MTA always appeared to be down. The wan mtu was bigger than the lan mtu if I remember correctly.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: