Correct, obviously we will be seeing the first hop's IP address all the time so that will not be useful but we will still be doing checks on the messages themselves and mathcing them up with known spam messages and doing a heursitic scan for suspected spam.

Honestly it should work fine. What device will be in front of it, by the way?

Hi,

As long as you configure SBG with the IP addresses of the upstream MTA (i.e the MTA that is actually at the gateway), it will still take action based on sender IP reputation.
Obviously, because the message will have already been accepted by the upstream MTA we cannot do connection level blocking but we can catch it at content time.
You will lose the ability to use Connection Classification and Fastpass, because they are connection time features.
The biggest loss however is reputation based AS (connection time rejection of the inbound TCP connection), which translates to CPU overhead as the content scan takes place in memory rather than rejecting the connection at SMTP time.
How big that overhead is really depends on how many messages per second you receive to SBG and how many of them are spam versus legit.

Could you let us know WHY you have to have an upstream MTA before traffic hits SBG?  It might be possible to achieve your requirements with Brightmail Gateway alone.

Thanks,

//ian

Unfortunately the customer has IronPort and the decision is already made to have those at the gateway while the Brightmail will be the secondary hop.  The IronPorts will be configured to do the reputation based filtering and the SBG will be counted on for only AV scanning and the remaining AS scanning.

This was determined before I was involved through a bake-off of the two products and InfoSec team has already made it clear there is no changing this decision. 

OK cool, I understand.

Thanks for the post!

//ian 

Is there any documentation or KB articles that exist that discuss the configuration of an SBG inside of the gateway instead of at the gateway?  Something that might highlight the disadvantages or what specifically within the AS functionality will be less effective?

Hi,

There is a Best Practice KB here which outlines some things such as Global Bad Senders and connection classification.

You can also read about effectiveness with global reputation in this article I wrote earlier this year 

Also, the installation guide has a section on deployment:

"For Symantec Brightmail Gateway's spam, content compliance filters, and IP-based sender groups to function properly, you should avoid placing Scanners behind other filtering products (such as content filters) or MTAs that alter or remove pre-existing message headers or modify the message body.

If you do place your Scanners downstream of an MTA, specify the gateway MTA on the Inbound Mail Filtering - Connections page during installation. If you do not specify the gateway MTAs, Scanners may identify the IP address of your gateway MTA as a source of spam. Also, sender groups that match IP addresses, such as Blocked Senders (IP-based), will not function properly. Gateway MTAs can be specified after installation on the Internal Mail Hosts tab of the Administration > Hosts > Configuration/Edit page.

Hope that helps!

//ian

We see about 40 million e-mail per day.  97% are blocked by the connection and reputation features.

I've looked @ ironport, I wonder why the customer didn't use it's AV?

The customer has Symantec internally for AV and the Suite price was very little price difference and gave them SBG.  On the Ironport side, they would have had to purchase extra licenses for AS and AV scanning, which was cost prohibitive.  The Ironport was desired for their email encryption, TLS and DLP functionality though.