cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1106
Views
0
Helpful
6
Replies

Clarification needed regarding ESA operation

quaker_73
Level 1
Level 1

Hello folks,

I would like to receive a confirmation that my way of thinking is correct regarding Email Security Appliance operation.

Here is my question:

Does not configuring domains in Sender List applied to a Sender Group (with specified SenderBase Reputation Score) mean that the associated policy action will never take effect? I believe NO

E.g. if I have Sender Group SPAM with SBRS in the range of -10 to -3 and associated policy BLOCK to reject the connections, but no senders specified, this still means that any domains with bad reputation score, i.e. below -3 will be rejected, right?

And second to this:

Is the precenece of the specified senders higher than the SBRS?

E.g. we have random.domain with SBRS of -2, which is attached to Sender Group with SBRS in the range of -8 to -4. The policy associated with this Sender Group will still be applied to random.domain, right?

My questions may be silly but I want to make sure I do not make mistakes.

Regards,

6 Replies 6

Valter Da Costa
Cisco Employee
Cisco Employee

That sender list is not From header of the email, when we are talking about the HAT (Host Access Table). It is the domain (or subdomain) portion of the FQDN (fully qualified domain name). Example:

mailserver.domain.com

If you add domain.com to the Sender Group SPAM, it won't matter the SBRS interval associated with SPAM sender group. All hosts that have domain.com in the FQDN will match to SPAM and their connection won't be accepted by ESA, as you said that you have the policy BLOCK, assuming that policy has connection behavior as "Reject".

The HAT (Host Access Table) works from top to bottom, first match wins. So, if another sender group above the SPAM has domain.com, the a connection from a host named mailserver.domain.com would match that sender group. 

So, to answer your first question directly, I would need to understand what you mean by "no sender specified". If that means no From header, that is correct. A connection from a host named mailserver.domain.com will be rejected based on the entry domain.com listed in the SPAM sender group, it won't matter the From header specified in the email message.

In your second question it is not clear if you have the entry random.domain listed in the Sender Group. Assuming you have, then it wont matter the SBRS score. The connection from a host with random.domain in the FQDN will match with the sender group.

Hope that helps.

Hello Valter,

Thank you for clarifying my second queistion.

Regarding the first one you can refer to the image attached:

Even though no sender are specified each domain with bad reputation will be rejected (assuming that BLOCK policy does this), right?

Hey Quaker,


Yep you are exactly right there.

So your screenshot.

No senders need to be added, as it will be taking action only when something falls within the SBRS ratio you have set.

Essentially BLACKLIST works off SBRS scores (unless you have a mail server you wish to statically block).

Regards,

Matthew

Thanks :)

Hey,

One more question from my side - if we have trusteddomain.com with Reputation Score of -4 already defined in another Sender Group (e.g. TRUSTED with policy that allows the senders), messages from this domain will not be rejected, even though the domain is in the range of -10 to -3. Is this correct?

Or in other words does explicitly specifying senders has precedence over SBRS or as Valter pointed above, I just need to make sure that TRUSTED Sender Group is placed above BLACKLIST Sender group, since both groups will match this domain?

Hello Quaker,


Yep, if you allowed it via the mail server hostname in the WHITELIST (which sits above BLACKLIST) even if it's -4 on the scoring, it will match the WHITELIST first (top-down approach) and be allowed through.

If you have added the mail server host to UNKNOWNLIST which sits under BLACKLIST but it's at a -4, it'll get dropped as Valter shared.

I hope this clears it up.

Thanks,

Matthew