ESA as intelligent SPAM filter used to protect outgoing emails in hosted environment

[Jernej Vodopivec]

Hi, we have the following situation:

- customer is offering hosted email service

- each mail server (Exchange) is hosting thousands of email accounts used for many different e-mail domains

- Exchange server relays outgoing email through ESA

It happens that some users sends high volume of emails in some period of time. Usually these emails are SPAM emails but not always.

That can bring ESA's public IP address to some RBL lists which of course influences all email users hosted on that server.

What would be best practice to prevent this happening:

- outgoing emails are scanned with AS engine?

- number of messages per connection, max. recipents per hour etc. are tuned?

Is there any better way to do it? I'm thinking of - let's say - some "intelligent" filter that would detect sender that is sending large volume of email messages and temporary suspends sending only for that email sender? Any idea/suggestion?

[Mathew Huynh]

Hey Jernej,

Yes this is a tricky situation indeed.

I've seen from some deployments, on the ESA a seperate Listener and IP interface is configured for the 'bulk' senders which is more restricted by filters if matching specific bulk mail listener and such.

It is suggested to deploy AS filtering as well for outgoing as it's not your actual domain but hosted for many so it's best practises.

As for the final thought, perhaps Envelope Sender Rate limiting might be within your scope for deployment, to stop (temporarily) senders who exceed a threshold of allowable mail sending behaviours.

You can keep it on the SMTP 452 reply code which will temporarily delay any additional emails for acceptance,

or [[ This is a very aggressive setting, only use it if you're comfortable to do so ]]

use a custom SMTP reply code (to 5XX) if you want to hard bounce the emails once it exceeds the threshold. Where the bounce NDR is generated on the connecting server, not your ESA as you are denying it at the connection.  

(This can be limited to a sendergroup + mail flow/listener.)

Regards,

Matthew

[Jernej Vodopivec]

Hi Matthew,

thank for your reply. Limit envelope sender could be one useful way also, I forgot about it :) Tanks.

I'm also thinking of creating "small intelligent app", that would more dynamically block senders.

Process would be: export logs to external syslog server. App would then process this information. Based on app's smart logic :) app would put problematic sender (through Ironport's CLI) to custom filter's sender list. That custom filter would do all the necessary actions: sends alert to admins, (temporary) block sender...

"smart logic" could be more intelligent than static envelope sender limiting: for example: if number of messages sent from some sender in some period of time exceeds the average number of emails sent from same sender in same period for 300% alert admin. If it exceeds the average number of sent emails for 1000%, drop emails and alert admin. I'll discuss it with the customer.

If I'd create useful app, I'll share it on this forum.

[exMSW4319]

Jernej, if your IP is appearing in relevant DNSBLs then you're not sending the odd bit of spam - you're sending a lot. The offending customers are possibly buying and using lists containing spamtrap addresses.

It's very simple - leaving aside the technology, e-mails are conversational, transactional or bulk and if you have a customer who expects to be able to bulk through your equipment then you are going to steadily lose deliverability. Aside from the DNSBLs there are characters like me who will throw your IP, your local net block or your ISP's entire ASN into our blacklists* and then never review it unless someone complains that they're not getting a mail. Not all of the significant smarthosts offer a lookup service, and the big freemailers can be equally opaque. Deliverability is easily lost, and only regained with great difficulty. 

There are e-mail service providers who specialise in sending bulk, and they exist for a reason: so we can blacklist their equipment whilst accepting traffic from the organisations they are sending on behalf of. My recommendation would be to check the terms of service your customers are signed up under.

* Other readers please note that this does require a fair degree of diligence and practical experience, and the extent to which you can blacklist will depend on your recipient community.