I'll preface my answer with the general warning that redundant filtering with multiple vendors, while in theory sounds like a good idea, in practice we see many problems, and it is not something we recommend. And in reality, it is not neccisary. If properly configured, the SaaS service will handle all inbound filtering, including TLS Enforcement, DKIM Enforcement, Content Scanning and enforcement, and can check whether or not the mailbox is legitimate (when combined with Directory Integration and Explicit User Creation enabled, with the action of Deny or Silently Discard the message if to an invalid recipient). The SaaS product was designed specifically to be a cloud replacement for on-prem appliances.
Now, to answer your more specific questions:
- Is Directory Integration a requirement? No, it is not. Although Directory Integration is recommended, especially for larger organizations, to allow a much easier management of user creation and deletion. However, any organization is free to use SMTP Discovery user creation mode and/or manually create users individually or via the batch process.
- Will the SaaS perform the basic "Spam Yes/No" check and send it on? With a major caviat, yes, it can be configured to scan for spam and do nothing as a result, thus sending the message on, however, there is nothing included in the header that can be used by another product to take any follow up action. You can tag the subject line with a [spam] tag, but this may or may not help with your product. There are also defenses that are in place that sit higher than the domain level which can block mail: our Perimeter Block, Rolling Defensive Blocks, and Critical Spam scoring (100% proability spam, which is blocked in absense of a white-list entry).
There are several potential problems with the customer's desired setup.
- Because the spam scoring is of no use to other appliances, the desired effectiveness will be reduced
- Messages can and will still be blocked by the SaaS service for Perimeter Blocks, Rolling Defensive Blocks, and Critical Spam scoring
- Message tracking becomes a difficult affair. Messages presumed missing must be tracked from McAfee SaaS, to the Appliance, then on to the Exchange Server.
- The full cabililities of the product, and thus the investment, are not being fully utilized.
Let me know if you have any further questions!
Many thanks, Brad - an excellent answer as usual.
To respond to your preface - yes, I'm 100% with you. With this one exception, all of our customers operate quite happily with a single-layer email security solution - be that on-premise, in the cloud, supplied by McAfee or by another vendor.
While working with the solution today on one of our test e-mail domains I had essentially established that AD integration wasn't necessary and had come to understand that in addition to the "manual" option there is also the SMTP Discovery method. I'm guessing that our customer will opt for this latter option as they don't, at present, intend to hold any data in the SaaS environment once a decision has been made.
Slight misunderstanding with the Spam yes/no question - if SaaS determines the message is almost certainly spam, I expect the customer to select the "Deny" action. With the others, I'm anticipating they will go down the "Do Nothing" route (as unnatural as it will seem to you and I). So, I'm not expecting the SaaS solution to embdedd any additional spam info/data for the second solution to act upon.
Who's to say that one day, in the future, they will commit to using more of what the SaaS solution has to offer? The second on-premise solution is very mature (in that they have spent a number of years creating their content-level policies and TLS configuration) and they simply don't wish to consider moving it elsewhere at present. But, they only require a solution to replace a box that currently makes a "yes/no" decision on whether a message is spam and/or if it contains a virus, what I really wanted to check was that SaaS wouldn't actually work if we didn't apply any additional configuration (such as full user integration).
That was exactly what I was not certain about, so yes if in this case they do want to filter high-level spam in the cloud and send all other mail to the appliance, it will work in that capiacity. I would recommend though going through and reviewing the Content and Attachment polices to ensure that there is nothing there that should not be applied by default. The system will still scan for viruses and spam, and take whatever actions are specified. SMTP Discovery will work just fine.
This would also give the client the opportunity to start playing with off-loading some specific content filtering policies to the cloud as they see fit, and allow them to test those other functionalities in a slow-roll process if they desired.