For partners that build or integrate commercially available applications and service solutions with the Oracle Cloud Platform
For partners that provide implementation or managed services around Oracle Cloud Applications
Hi,
does anyone know if Oracle discontinued the use of Barracuda SPAM filter? I am sure that we are still receiving emails from some of the email addresses that have been previously added to the blacklist. Does anyone else have this experience?
Alternatively, what other ways do you use to block SPAM? I know it is possible to block through the business rules, but that we only use for the heaviest offenders. I am talking about a blacklist that would hold hundreds or even thousands of email addresses we can add.
Many Thanks
Pavol
I had the same issue. None of the blacklist addresses I put in picked anything up. I had to resort to a couple of business rules.
Sometimes I get quarantine emails from it though, but nothing to do with the rules I put in just the odd email if flags itself.
I guess if there were no other option you could write a CPM to delete/categorise incoming emails and use a custom object to store a blacklist. That seems like there should be a better solution though with less effort.
I have said goodbye to Baracuda a long time ago. We do filtering through business rules (regex on thread, header, email and subject) and jst give them a specific status which allows us to quickly adjust filters (BR) and use the rule log to see which one got triggered. We also have a more permanent one (custom field menu type for contact)
Default is filter which would make incidents from this contact go through the filter.
I think it's common to have external (corporate) spam filtering before anything even gets through to Oracle. So Oracle ends up being a second line of defense, and whatever Spam filtering they use. I don't think Barracuda has been discontinued, but it's possible that their own algorithms may have updated. Containing spam is a never-ending and constantly changing thing so I'm not surprised of previously blacklisted stuff gets through, though certainly it shouldn't happen. I think business rules is *not* the ideal way, because they have to churn every time an incident gets into the system. Granted, the system can handle a huge volume of business rule processing. But it still has to go through potentially every rule until it finds a match, then has to deal with either setting statuses, deleting, not-creating-incident, or whatever the rule action needs to do. It's an unnecessary load on the server, even if small. And the only way this would be effective is to block a specific address that is a repeat offender. Spam generators can get around this easily. It's much better to block before it reaches the rules. One way to do that is to add addresses or other criteria to the individual mailbox filters. (Mailboxes > Incoming Email > Discard filters.) Here's where you can list specific addresses, headers, etc. A good use case for this is if you need to block certain auto-reply addresses, like 'noreply@yourpartner.com'. What will happen then is that "we've received your message" email of theirs will hit the mailbox, get caught by the discard filter, and the story ends. No need to trigger the rules and go down the list evaluating until the correct one matches. This too would only really work for specific repeat-offender addresses that you want to block but that aren't spam pe se. I'd say that mailbox filters are better than business rules, pretty much always, unless there is some reason you need to do an additional action upon it. For spam messages, I can't imagine when this would be the case. Summing it up, the layers of defense should be: Corporate, external to Oracle > Oracle spam handling (e.g. Barracuda) > mailbox filters > business rules (last resort or if additional action is needed on the messages).
Thanks all for great suggestions. I agree fully on the part that there should be a Corporate system before Oracle, and we do have this, but I am talking about emails that still come through. As for Barracuda, I do not expect magic from it, but such a basic functionality as to not let through emails from manually blacklisted email addresses should definitely work - if it doesn't I have little trust in any other function within it.
I believe I am going to stick with Sebastiaan's suggestion because as he pointed out, I need the agents to be able to quickly mark spam. They anyway have to trash those emails when handling them as they do arrive in OSvC. It actually should be able to save them one click :)
(Currently: 1 click to open Status Menu, 1 click to chose Trashed, 1 click to Save & Close
New: 1 click on a SPAM button (upon which a Workspace Rule will change Status to Trashed and set the Contact Custom Field "SPAM" to True), 1 click to Save & Close - next time we receive anything from this email address the Business Rule will catch it based on the Custom Field value and stop it from creating an incident.)
As for the Mailbox filters, I am talking about at least hundreds of email addresses every week which I still would need the agents to mark, so that I can find them and then add to the filter.
Many Thanks
Pavol
Hi Pavol
You can save another click :-)
If you use a spam button as you stated you can add an additional action to it (Execute an editor command) that will save and close the incident.
I thought Save & Close wouldn't be possible in the Workspace Rules :)
Should have looked better!
Thanks!
Mailbox filters are not ideal either. They are only accessible to admins where a custom field on a workspace allows for easy access to agents dealing with incidents. But I agree that preventing is better than curing. It also depends on the customer and legal compliance. I have government agencies as clients that do not want to filter anything away as they need to comply with local law but they do use a custom field.
I have said goodbye to Baracuda a long time ago. We do filtering through business rules (regex on thread, header, email and subject) and jst give them a specific status which allows us to quickly adjust filters (BR) and use the rule log to see which one got triggered. We also have a more permanent one (custom field menu type for contact)
Default is filter which would make incidents from this contact go through the filter.