Identify outbound spam

There are a few things to consider:

#1

The first is that your exchange is set up as internal relay, so the appliance will not reject mail coming from exchange.  That been said, there is no reason for any user to relay 5-10 or 50 emails per second..  The first thing I would do is message rate throttle ad accounts.. no human will try and send more then 1-2 messages per minute.. https://technet.microsoft.com/en-us/library/bb232205(v=exchg.160).aspx  set it to 5-10 message per minute max.. that way if your work station gets infected and trys to mass mail out.. exchange will drop it.

#2

Make sure that SMTP authentication is disabled, this would allow anyone with an ad account to relay mail directly to the appliance.   they should be sending mail through exchange then to the appliance.

if that's checked off remove it. 

#3

Create some additional / data control rules for your particular environment with various actions, such as reject the message or notify some other email account.

AV can not be disabled on the appliance, an email sent in any direction will be immediately quarantined.

#4

Outbound spam checking can only apply content rules to mail, IE: does the word Nigerian and prince appear in this paragraph.. or does that paragraph look like this.. or contain that ..  or match this.   Regardless of the email solution the most effective way of determining if a message is legitimate or spam is via the ip reputation block list data.  

For example. is IP 1.2.3.4 black listed?  yes / no. 

In your case no internal ip would ever be black listed.. so this feature is not available on outbound mail. 

labs uses some very advanced pattern matching, the second they update the rules are updated so its still good to have outbound rules.

#5 make sure your exchange servers (or other infrastructure) that does NOT expressly accept and deliver mail with an MTA is listed as a trusted relay. 

examples: an upstream email appliance IS a trusted relay .. a firewall that port forwards 25 is NOT.  external ip's should also not be listed..  Anything that is.. is omitted from spam checking. 

There are a few things to consider:

#1

The first is that your exchange is set up as internal relay, so the appliance will not reject mail coming from exchange.  That been said, there is no reason for any user to relay 5-10 or 50 emails per second..  The first thing I would do is message rate throttle ad accounts.. no human will try and send more then 1-2 messages per minute.. https://technet.microsoft.com/en-us/library/bb232205(v=exchg.160).aspx  set it to 5-10 message per minute max.. that way if your work station gets infected and trys to mass mail out.. exchange will drop it.

#2

Make sure that SMTP authentication is disabled, this would allow anyone with an ad account to relay mail directly to the appliance.   they should be sending mail through exchange then to the appliance.

if that's checked off remove it. 

#3

Create some additional / data control rules for your particular environment with various actions, such as reject the message or notify some other email account.

AV can not be disabled on the appliance, an email sent in any direction will be immediately quarantined.

#4

Outbound spam checking can only apply content rules to mail, IE: does the word Nigerian and prince appear in this paragraph.. or does that paragraph look like this.. or contain that ..  or match this.   Regardless of the email solution the most effective way of determining if a message is legitimate or spam is via the ip reputation block list data.  

For example. is IP 1.2.3.4 black listed?  yes / no. 

In your case no internal ip would ever be black listed.. so this feature is not available on outbound mail. 

labs uses some very advanced pattern matching, the second they update the rules are updated so its still good to have outbound rules.

#5 make sure your exchange servers (or other infrastructure) that does NOT expressly accept and deliver mail with an MTA is listed as a trusted relay. 

examples: an upstream email appliance IS a trusted relay .. a firewall that port forwards 25 is NOT.  external ip's should also not be listed..  Anything that is.. is omitted from spam checking. 

EnricoGiac, 

follow what Red_Warrior suggested. Option 1 is the best option if your mail delivery chain is:

internal clients > exchange > sea > external

Make sure to allow only Exchange on SEA and viceversa. It is really important to use "least of privileges" principle. Also, it is really important to protect all computers with an AV.

For example, you can restrict that only domain computers with an updated AV and Windows Update ON can send email using a NAC product. If the network is really large, NAC is needed, otherwise you will always play the cat and mouse game.

Regards

First of all, let me thank you for the time you dedicate to me.

#1

I agree with you this is the best option, but unfortunately the internal server is a Zimbra Mail server of whom I have neither access nor knowledge. I hoped the same control might be done in Sophos Email Appliance too. I'll also try to turn the problem to Zimbra administrator too

Others # are already been evaluated, thanks a lot and I hope to find a solution to mitigate or solve this issue.

Thanks again and kind regards,

Enrico

Enrico,

the smtp load is handled by the SMTP server and then the SMTP server sends email to ESA. I agree that SEA should be able to manage maximum emails per seconds, maximum number of recipients even on outboud (Red_Warrior can you open a feature request?) but....any mail server can enforce maximum settings to prevent spam:

https://imanudin.net/2014/09/09/zimbra-tips-how-to-configure-rate-limit-sending-message-on-policyd/

;-)

Regards

Grazie Luciano,

ho girato all'amministratore dello Zimbra ;-)

Suggestion for this new feature:

As SMTP connection is originating from an internal mail server, the maximum email per second should consider the sender address too and automatically create an additional outbound policy that discard the messages and set the status of the appliance to red.

Please let me thank you once again for your help. Ciao

Enrico