Dropping connections in Ironport when CASE is triggered

[Steve Ballantyne]

I have had a real problem lately with spammers picking up legitimate hosting accounts in the United States. The strange part is that when I pull a message history in Ironport, I am seeing it make different decisions on the same single connection.

In other words, the message history looks something like this with an incoming connection (all under the same one IP address) ...

Message 1 - Dropped by CASE

Message 2 - Dropped by CASE

Message 3 - Dropped by CASE

Message 4 - Delivered!

Message 5 - Dropped by CASE

Message 6 - Sent to SPAM quarantine

Message 7 - Dropped by CASE

Message 8 - Dropped by CASE

Message 9 - Delivered!

My question is, why can't I drop a connection to Ironport the moment it's identified with CASE? It makes absolutely zero sense to let the sender keep pushing emails with slightly different sending addresses and subject lines until it's able to push a few through.

I have opened a ticket with support, but I am getting nowhere fast with them. They just want me to keep sending them more sample submissions.

[Libin Varghese]

The antispam verdict is not based on the sender IP alone so submitting samples to TAC would help you update the rules for antispam accurately.

If you would like to block all connections coming to the ESA based on the sender IP or hostname you can certainly add them to the HAT Blacklist. As more spam is reported from an IP its emails reputation would drop globally.

Also an email is identified as spam during the workqueue processing after the sender IP is determined to have a good or neutral email reputation.

[Steve Ballantyne]

---

@Libin Varghese wrote:

If you would like to block all connections coming to the ESA based on the sender IP or hostname you can certainly add them to the HAT Blacklist. As more spam is reported from an IP its emails reputation would drop globally.

Also an email is identified as spam during the workqueue processing after the sender IP is determined to have a good or neutral email reputation.

---

I do manually block these IP's at the firewall level. I generally see who owns that block, and I block the entire range. A lot of the time, it's "yet another" fly by night hosting company in the US. But it's after the damage is done. And it's unlikely I will see SPAM from them soon, if ever. 

The workqueue process is the problem here. It's flawed. Emails should be entering a queue or a buffer of some sort so that a decision can be made on the lot of them. If I accept 100 emails from a host, and 99 of them are SPAM - I think it goes without saying that they are all SPAM.

[Libin Varghese]

That is the thing with hosting services, not all emails coming from them may be spam.

An email is determined to be spam or not spam based on the actual email since legitimate domains use hosting services for business emails too.

For example mimecast may be used by spammers but not all emails from their servers are spam.

If there are spam missed, that is an opportunity to further tighten the rules. Do note that currently the rules work the way they do to prevent false positives and the same rules apply globally.