IronPort ESA - Number of messages received per connection exceeds limit

[exMSW4319]

Point 1:

No, you need to know the host name or IP address of the sending equipment. The sender's domain is unlikely to match it.

At that point I do a spot of diligence to see if the equipment is dedicated or shared. Additionally, if its SBRS rating is negative then it's probably negative for a reason.

If all looks good, the IP or host name can then be added to a WHITELIST HAT sender group if you have one. Our corresponding mail flow policy permits fairly silly connection and recipient numbers, as opposed to the more moderate ones for the default policy.

Point 2:

If you really want to, you could even create a new Sender Group just for this one sender and any similar cases that crop up.

Point 3:

No, if the mail was chucked before the ICID became a MID then you never had the message. Strictly speaking at that point the rejection is the sender's problem rather than yours, though I imagine the reality is somewhat different. I'd say the Cisco factory defaults are generally fair, so unless someone cranked the default mail policy connections limit down you're meeting "industry standards" and are in the clear.

[scott.walker1]

Thanks for the feedback. 

We know the IP and trust the sender of these mails coming in from the Internet, ratings on the ip are fine too. 

If I create a Whitelist in HAT does this then remove the incoming sender connection limitations. I think we're set at 10.  

[exMSW4319 · Accepted solution]

In your HAT you've got your sender groups on the left and your mail flow policies on the right. An incoming mail is checked against each sender group in descending order, so be careful of the sequence.

Once the sender group is found, the corresponding mail flow policy on the right applies.

If you've got a WHITELIST group and want to use that then just include your privileged bulk sender's IP or host name with the Add Sender button.

If you're creating a new group then it looks as if you have to create the mail flow policy first and the sender group later. An extra sender group SBRS range can be blank and the host DNS verification checks should be off.

A mail flow policy has a large number of settings, so it's worth taking notes of your TRUSTED (if you have one) or ACCEPTED policy before starting the change.

In our TRUSTED policy I have Max Mess Per Conn 1000, Max Recip Per Mess 5000 and Max Mess Size 50M. This works for us on a C170. You may need to jack up the Max Conc Conn From Single IP as the default is only 10, but I've used the same mail flow policy for a bulk sender and they were fine with the default.

General tip: save your config file unmasked before and afterward, and keep a note of any changes you put in so you know why something's the way it is.

[scott.walker1]

Thanks for this and putting us on the right track.

We have implemented and awaiting a test today.

Our only issue initially is that List, ACCEPTED > BLOCKED > THROTTLED > TRUSTED is in alphabetical order. We are so far unable to change this so have had to amend each name to A1TRUSTED etc... to make it first in the list.

Without doing this the other policies are being hit before the trusted.

[exMSW4319]

Scott, I suspect that you're reading Mail Flow Policies as presented by the Asyncos menu. It's a fairly pointless menu entry; I access all of my sender groups and mail flow policies from the HAT. From the GUI, Mail Policies > Hat Overview should show you the sequence that matters.

There's an Edit Order button on the HAT Overview that will allow you to alter the sequence. Think carefully before changing it!