I tested this out for a new project in our pipeline and am very much looking forward to using it! Are there any plans to have this work outside of IMAP? I think it would be great to be able to clean up the dumpster and archive within O365 for example.
Very happy to hear that, Scott! Yes, we have plans to add both Gmail API and Exchange / O365 sanitization capabilities to Obliterator. Gmail currently works reasonably well over IMAP—with the suggested adjustments on Obliterator’s page above—but the inherent IMAP duplication and IMAP’s limited search capabilities reduce the efficiency of the process. We would like you to be able to stay within Gmail API for both the FEC acquisition and the follow-up Obliterator run.
As for O365—yes, we are looking into adding the option to clear the Recoverable Items folder for you upon completion of the sanitization so that you won’t have to do it via Exchange Management Console.
We are always open to any feature requests from the community to make it work seamlessly in your workflow. For instance, when identifying the messages to be deleted, I’m sure most of you would prefer to perform a comprehensive review in a legal review platform or forensic investigation tool. You can currently do this by overlaying the necessary IDs from FEC’s logs to your review tool, and then using your work product in the review tool to narrow down the list of item IDs to be deleted via Obliterator. I find this to be very straightforward, but I may be biased If there is anything we can do to make things easier, I am all ears.
any updates for O365?
Hi Arnold,
We haven’t added EWS API support to Obliterator yet to improve the O365 experience. A major update to Obliterator is close to the top of our priority list. We will start work on that once the dust settles after the FEI launch
Thank you for the quick response! I’ve signed up for the FEI and looking forward to trying it out. Now I’ll also look forward to the update for obliterator. Thanks again and keep up the great work!
Many thanks, Arnold!
We have released a major update to Obliterator yesterday! We have updated the Obliterator blog post to reflect the changes in workflow and created a new changelog.
The most notable improvement is that you no longer need IMAP for Gmail remediation
I am happy to announce that Obliterator now supports EWS! So, it is now possible to use an Exchange/O365 FEC acquisition as the starting point for remediation
Details can be found in the updated Obliterator blog post as well as the changelog.
We have also streamlined the ideas, roadmap, and announcements for Obliterator. You can now access them all in one place:
Hi Arman,
Can we use the new EWS deletion method on Hotmail/Outlook.com?
Cheers,
Yian
Hi Yian,
Hotmail and Outlook.com support IMAP and Graph API, but not EWS. You can do an IMAP acquisition followed by IMAP remediation in Obliterator. If you would like to be able to do Graph API → Graph API remediation, please feel free to add an idea below
Thanks Arman.
I may have found another way.
I noticed that the Mime Hash appears to be the same when collecting using either the Graph API or IMAP method. So I can cross reference using this value and delete using the IMAP method.
For future reference, is this the case that the Mime Hash would be the same for the same mailbox using any method of collection within FEC?
Cheers,
Yian
Hi Yian,
Yes, this is because the MIME copy is retrieved from the server as a whole and written to disk without any modification. If you do not mind performing two acquisitions, you could do an IMAP acquisition as you said and look your IMAP UIDs up for the items to be deleted.
One potential wrinkle is that the scope of an IMAP acquisition is not exactly the same as that of a Graph API acquisition. For instance, IMAP does not include the Recoverable Items Folder which Graph API can access. So, you can theoretically encounter some items in your Graph API acquisition for which you cannot locate IMAP UIDs.
For O365, can the Service ID values be obtained directly from within Microsoft’s Compliance Center / eDiscovery modules? When examining an export log from this process I could only see a 64char Item Identity value and a 7 character Document ID value, neither of which seem to correspond to the Service ID value the input list requires.
Hi Sean,
Yes, the “Item Identity” values you see in Compliance Center exports / reports can be used with Obliterator. However, they require a conversion so that they can be used to address items in Microsoft’s APIs. You need the following conversion if you are using Obliterator in EWS mode:
immutableEntryId ➫ ewsId
This can be done in bulk (1,000 IDs at a time). Here is the relevant documentation: