filer for rejected inbound from domain during time period

chmeehan0421 · ‎11-17-2009

We had a large outage that lasted about 12 hours. during this time our mail was held and queued. I'm seeing in the GUI alot of rejected attempts from this domain. How can I filter for the rejected attempts in the CLI to determine what threshold in the mail flow policy cause the attempts to be rejected. I was think the findevent command but I think it requires some information I can't provide.

Thanks in advance.

Chris

mychrislo_ironport · ‎11-17-2009

Umm..if you want to allow a longer queue lifetime and avoid messages become render undeliverable. you can look at bounce profile

But if you actually want to reject incoming connections when ironport detects certain destination domain queue is high...it maybe difficult.

Max interval
allowed 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,

Max number of
retries

The number of times the system should try to reconnect to the recipient host to redeliver the soft bounced message before treating it as a hard bounced message. The default is 100 retries.

Max number of
seconds in queue

The amount of time the system should spend trying connect to the recipient host to redeliver the soft bounced message before treating it as a hard bounced message. The default is 259,200 seconds (72 hours).

Max number of
seconds to wait
before retrying a
message

The maximum amount of time the system should wait before trying to redeliver the soft bounced message. The default is 3,600 seconds (1 hour). This is not the interval between each subsequent try; rather, it is another parameter that can be used to control the number of retries. The initial retry interval is limited on the high end by the maximum retry interval. If the calculated retry interval period exceeds the maximum retry interval then the maximum retry interval is used instead.

chmeehan0421 · ‎11-17-2009

mychrislo,

Thanks for the info and i will start looking into it. In any case however, an NDR should be returned back to my internal senders correct?

mychrislo_ironport · ‎11-17-2009

Yes, but in fact, you can optionally disable NDR.

In cli
> bounceconfig

Current bounce profiles:
1. Default

Choose the operation you want to perform:
- NEW - Create a new profile.
- EDIT - Modify a profile.
[]> edit

Please enter the number of the profile to edit:
[]> 1

Please enter the maximum number of retries.
[100]>

Please enter the maximum number of seconds a message may stay in the queue before being hard bounced.
[259200]>

Please enter the initial number of seconds to wait before retrying a message.
[60]>

Please enter the maximum number of seconds to wait before retrying a message.
[3600]>

Do you want a message sent for each hard bounce? [Y]>

Do you want bounce messages to use the DSN message format? [Y]>

Enter the subject to use:
[Delivery Status Notification (Failure)]>

Do you want to parse the DSN "Status" field received from bounce responses to include in the DSN generated by the appliance? [N]>

If a message is undeliverable after some interval, do you want to send a delay warning message? [N]>

Do you want hard bounce messages sent to an alternate address, instead of the sender? [N]>

Do you want bounce messages to be signed (Yes/No)? [N]>

Please enter the initial number of seconds to wait before retrying a host that is unreachable.
[60]>

Please enter the maximum number of seconds to wait before retrying a host that is unreachable.
[3600]>

Please enter the maximum size of the original message (in bytes) to include in the bounced notification message.
[10240]>

Current bounce profiles:
1. Default

mychrislo_ironport · ‎11-17-2009

Oh, and be sure you associate this special bounce profile to the problematic domain only. If you just want this to be specific to be this very domain.

(destconfig) or in the GUI Destination Control.

chmeehan0421 · ‎11-17-2009

Thank you. This was very helpful.

But what I really asked was if I can filter the mail_logs for inbound rejected connections from a specific domain between day x and y..

I need to see why we rejected some inbound mail from a specific domain but not all of it and what the response back would have been or if it would have just been dropped and not produced an NDR.

Thanks.

Chris

mychrislo_ironport · ‎11-17-2009

Thew, I am embrassed to mis-understand your question.

The ironport support site has two tools that comes into mind

1. findevent for (linux?)
2. spamtowho.

you can first scp the mail_logs out from the ironport.

But normally, I'd resort to eye ball checking if there is a probematic domain not receiving our mails.

You'd do related message tracking if you have MFC or M-series.

chmeehan0421 · ‎11-17-2009

No worries on the misunderstanding, your reply was still very helpful.

I have used findevent before but I thought that I could only find on certain criteria such as from and to and so on...

Can I use it to find rejected connections from domain name?

Chris

mychrislo_ironport · ‎11-17-2009

You can use grep from within ironport.

But my experience is that you'd much better off by scp the mail_logs out

(hints: scp admin@ironport:mail_logs/* ./ )

Because in linux/unix, you can do nested / pipe to multiple grep.

e.g. grep your incoming connection ip. then according to the MID or DCID. grep further details.

steven_geerts · ‎11-26-2009

Hello,

Despite to the fact it was a misunderstanding, I like to jump back to the excellent explanation mychislo did about the lifetime of a (temporarily) undeliverable message.

I once tried to save my ass by changing the "Max number of seconds in queue" parameter after I discovered my downstream mail server was in such severe troubles that i was not sure i could bring it back before the first messages started to expire. (that was a good expectation, it took us way more time to get the system up and running again).

The fact is that the "Max number of seconds in queue" value is calculated when the message arrives, using the value configured at that time. a change of the parameter does not impact the messages already stored in the queue.
Please keep this in mind if you ever find yourself in a situation like I was at that time.

Steven.