I am working with a customer who is in the process of deploying SaaS Email and have myself only recently come into contact with the product.
The scenario I am working with is one which is actually quite simple and this customer only really needs to use some fairly basic functionality. The question is whether SaaS Email can be configured a simply and this customer actually needs it to be, or whether they will be required to do some additional stuff even though they don't really want SaaS to be involved to that degree.
Their current email flow brings SMTP traffic in directly through their McAfee Firewall Enterprise appliance to a Symantec email security appliance. The job of this appliance is very simple - using IP reputation filtering and basic analysis is the message likely to be spam or not?
If it is, the message is discarded (no quarantine, no nothing). If it passes this stage it is then passed to a second email security appliance (from a different vendor). It is the job of this appliance to check the recipient mailbox actually exists, perform content-level scanning to determine whether any spam messages have slipped through the net of the first solution and to perform compliance checks to ensure there is nothing else within the message body (illegal message content, attachment type, attachment size, etc...) before then passing the message through to their Exchange server.
This same (second) solution is solely responsible for outbound mail as it contains all of their TLS policies.
The object of the exercise is to replace email security appliance #1 with SaaS Email for inbound scanning only.
The question, I'm guessing, is whether is it a requirement to go through the process of synchronizing SaaS with the back-end Active Directory and whether, at a domain-level, the SaaS will peform this most basic check of "is there a 90%+ chance this message is spam? yes or no", and then route messages passing this test on to the next hop?
Many thanks in advance.
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.
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.