Supported file types for processing

Relativity supports many different file types for processing. There are also a number of file types that are incompatible with the processing engine. Before you begin to process your data, it may be helpful to note which types are supported and unsupported, as well as any caveats involved with processing those types of files.

This page contains the following information:

Supported file types

The following file types and extensions are supported by Relativity for processing.

Note: Renaming a file extension has little effect on how Relativity identifies the file type. When processing a file type, Relativity looks at the actual file properties, such as digital signature, regardless of the named extension. Relativity only uses the named extension as a tie-breaker if the actual file properties indicate multiple extensions.

Note: Relativity currently doesn't support the extraction of embedded images or objects from Visio, Project, or OpenOffice files. In addition, Relativity never extracts any embedded objects or images that were added to any files as links. For a detailed list of the Office file extensions from which Relativity does and does not extract embedded objects and images, see Microsoft Office child extraction support.

Note: If you use the Native text extraction method on the profile, Processing does not handle pre-2008 Microsoft Office files that have the Protected view enabled. You must use the Relativity text extraction method to process these files.

Excel file considerations

Due to Excel specifications and limits, when processing a database file with the Native text extraction method, the DBF file may miss data in extracted text. For example, if a DBF file contains more than 1,048,576 rows and 16,384 columns, the extracted text of these files won’t contain text on row 1,048,577 and onward and on column 16,385 and onward. For more information, see Excel specifications and limits on the Microsoft website.

Google Workspace considerations

When you gather Google Workspace data, Google provides a supplemental metadata file. For Google Mail (Gmail), the metadata file is a CSV. For Google Drive, the metadata file is an XML.

Beginning in September 2021, Relativity automatically identifies when the supplemental metadata file is present in your file share, links the metadata fields to the processed files, and makes them available as mappable fields.

There are two methods for collecting Google Workspace data:

• Relativity Collect (Collect)

• Manual download via Google Vault (non-Collect)

For Gmail, the metadata file is provided as a CSV (an XML file is also provided but not used). In the following image, the folder on the left is a Collect job and the folder on the right is non-Collect.

For Google Drive, the metadata file is provided as an XML. In the following image, the folder on the left is a Collect job and the folder on the right is non-Collect.

Note the following requirements and limitations for Google Workspace processing:

• When collecting data manually from Google Vault, Gmail data must be exported as an MBOX. Relativity will not be able to sync up additional metadata if exported as a PST.
•  It is recommended that users do not alter the data that is gathered.
  • When using Collect, Relativity will automatically save data in the format and structure that Processing expects.
  • When downloading data from Google Vault, save all files to the same root source folder, without alteration. This way, Processing will accurately detect the supplemental metadata file and all other data for processing.

• Google Chat data will be converted to RSMF for processing only when Collect is used to gather data.

Google Workspace metadata field lists

The Google supplemental metadata files contain the fields listed below, all of which are available to be mapped to Document object fields. Note that Google may add, remove, or edit these fields at any time, and the most current lists can be found on their website here.

The following table lists the metadata fields found in the Google Drive XML.

Note: Customers won't see any of the source fields until they have processed Google data and the specified fields are included in the sidecar file.

Google Drive XML Field	Relativity Source Field Name	Description
DocID	Google/DocID	A unique identifier for the file. For sites exports, the value is the page ID.
#Author	Google/Author	The email address of the person who owns the file in Drive. For a shared drive file, it shows the shared drive name.
Collaborators	Google/Collaborators	The accounts and groups that have direct permission to edit the file or add comments. Also includes users with indirect access to the file if you chose this option during export.
Viewers	Google/Viewers	The accounts and groups that have direct permission to view the file. Also includes users with indirect access to the file if you chose this option during export.
#DateCreated	Google/DateCreated	The date a Google file was created in Drive. For non-Google files, the date the file was uploaded to Drive.
#DateModified	Google/DateModified	The date the file was last modified.
#Title	Google/Title	The filename as assigned by the user. Because some operating systems can't expand zip files with extremely long filenames, Vault truncates the filename at 128 characters during export. The value shown by the #Title tag isn't truncated.
DocumentType	Google/DocumentType	The file type for Google files. Possible values are: DOCUMENT—A document created in Google Docs. SPREADSHEET—A spreadsheet created in Google Sheets. PRESENTATION—A presentation created in Google Slides. FORM—A form created in Google Forms. DRAWING—A drawing created in Google Drawings. SITES_PAGE—A page from a site created in new Google Sites.
Others	Google/Others	The accounts from your query that have indirect access to the file if you opted to exclude access level information during export. May also include users for whom Vault couldn't determine permission levels at the time of export.
DocParentID	Google/DocParentID	For sites, the site ID.
SharedDriveID	Google/SharedDriveID	The identifier of the shared drive that contains the file (if applicable).
SourceHash	Google/SourceHash	A unique hash value for each version of a file. Can be used to deduplicate file exports and verify the exported file is an exact copy of the source file. Supported by Google Docs, Sheets, and Slides files only.
FileName	Google/FileName	The file name. Use this value to correlate the metadata with the file in the export ZIP file.
FileSize	Google/FileSize	The size of the file in bytes.
Hash	Google/Hash	The MD5 hash of the file.
UserQuery	Google/UserQuery	The query submitted by the Vault user that retrieved the files included in this export.
TimeZone	Google/TimeZone	The time zone used for date-based searches.
Custodians	Google/Custodians	The email addresses of the users whose accounts were searched. If you searched for content rather than individual user accounts, there are no custodians listed here.

The following table lists the metadata fields found in the Gmail CSV:

Google Mail CSV Field	Relativity Source Field Name	Description	Notes
Rfc822MessageId	Google/Rfc822MessageId	A message ID that is the same for the receiver's and sender's messages. Use this value to correlate metadata with the message in an mbox export. For classic Hangouts, the value is for the first message in the thread.
GmailMessageId	Google/GmailMessageId	A unique message ID. Use this value to manage specific messages with the Gmail API. For classic Hangouts, the value is for the first message in the thread.
Account	Google/Account	The account that had the message in their Inbox. For example, user1@company.com received a message sent to groupA@company.com because they're a member of the group. If a search returns that message because it was in user1's Inbox, then the value of To is groupA@company.com while the value of Account is user1@company.com.
From	Google/From	The sender account.
To	Google/To	The recipient account. Multiple recipients are comma-separated and the list is in double quotes.	Gmail only.
CC	Google/CC	Accounts in the cc: field.	Gmail only.
BCC	Google/BCC	Accounts in the bcc: field.	Gmail only.
Subject	Google/Subject	The message subject.	Gmail only.
Labels	Google/Labels	Labels applied to the message by Gmail or the user.	Gmail only.
DateSent	Google/DateSent	The message send date in UTC (yyyy-MM-dd'T'HH:mm:ssZZZZ).	Gmail only.
DateRecieved	Google/DateRecieved	The message received date (yyyy-MM-dd'T'HH:mm:ssZZZZ).	Gmail only.
SubjectAtStart	Google/SubjectAtStart	The subject of the conversation when the first message was sent.	classic Hangouts only
SubjectAtEnd	Google/SubjectAtEnd	The subject of the conversation when the last message was sent.	classic Hangouts only
DateFirstMessageSent	Google/DateFirstMessageSent	The timestamp for when the first message in a conversation was sent.	classic Hangouts only
DateLastMessageSent	Google/DateLastMessageSent	The timestamp for when the last message in a conversation was sent.	classic Hangouts only
DateFirstMessageReceived	Google/DateFirstMessageReceived	The timestamp for when the first message in a conversation was received.	classic Hangouts only
DateLastMessageReceived	Google/DateLastMessageReceived	The timestamp for when the last message in a conversation was received.	classic Hangouts only
ThreadedMessageCount	Google/ThreadedMessageCount	The number of messages in the conversation.	classic Hangouts only

RSMF mapping considerations

Generally, Relativity maps all metadata based on EML, but the following RSMF-specific mappings are considered non-standard.

Note: All EML Header strings are case insensitive, which isn't unique to RSMF files.

EML Header	Metadata Field
X-RSMF-BeginDate	Rsmf/BeginDate EmailSentOn CreatedOn InternalCreatedOn
X-RSMF-EndDate	Rsmf/EndDate LastModified
X-RSMF-EventCount	Rsmf/MessageCount

If an RSMF file doesn't include a Sent Date, and the X-RSMF-BeginDate header exists, that header will be mapped to the Sent Date field.

For more technical details on how Relativity Processing handles RSMF files, see Processing an RSMF file.

Multi-part forensic file considerations

When processing a multi-part forensic image, make sure that the Source location points to the root folder that must contain all files that make up the image. If you select only the first file of the image (E01, L01, EX01, LX01), inventory and discovery will fail with an unrecoverable error.

This is due to the fact that inventory looks at files where they reside in the processing source folder and does not copy them to the repository. If only the first file is selected, during discovery that file and only that file will be copied to the repository and the workers will attempt to extract from it and fail since the rest of the archive is not available.

When processing E01 files, the following NTFS file system files are skipped:

• Unallocated space files
• Index $I30 files

• $TXF_DATE files

Tracking inline/embedded images

It may be helpful for you to understand when Relativity treats an image that is attached to an email as an inline, or embedded, image and not as an actual attachment. The following table breaks down when this occurs based on email format and image characteristics:

Email format	Attachments that are inline (embedded) images
Plain text	None
Rich text	IPicture-based OLE embedded images
HTML	Images with content ID referenced in the HTML body Local, non-internet image references in the HTML that Relativity can match to an attachment PST/OST/MSG files containing metadata hints as to whether or not the image is marked hidden or is referenced in the HTML body

You can arrange for the discovery of inline images when creating Processing profiles, specifically through the field called When extracting children, do not extract. If you discover inline images, Invariant denotes them using a field called HiddenAttachment when it publishes them to your workspace. This field is not typically mapped by default, which means you need to create a new field in your workspace and set HiddenAttachment as the source of the field before processing data. If you've done this, you can then create filters and searches that reference this field to pull up the inline images. If you don't do this before processing data, you won't be able to identify inline images through searching and filtering.

Native text extraction and OCR

Relativity Processing distinguishes between text and line art in the documents you process. For these documents, processing will only OCR the line art. This means that Relativity doesn’t skip OCR if a page has electronic text.

Accordingly, Relativity performs both native text extraction and OCR on the following file formats:

• All vector formats (SVG, CAD files, Metafiles [WMF, EMF], Postscript, Encapsulated postscript)
• PDF, Visio, Publisher, MS Project, Hancom and JungUm files

All image formats (TIFF/JPEG/GIF/BMP/PNG etc.) do not have native text, so only OCR is performed. If the file has electronic text and images, native text extraction and OCR will be performed.

Support for password-protected RAR archives

Relativity Processing doesn't decrypt a file that gets its encryption directly from the RAR file that contains it. This means that if you attempt to process a password-protected RAR archive on which the Encrypt file names property is checked, Relativity Processing is unable to extract the files inside that archive.

In addition, note that Relativity Processing can extract a single password-protected file from a RAR archive, but not multiple password-protected files in the same archive.

The following table breaks down Relativity Processing's support of password-protected RAR archives.

• √ - Relativity Processing will decrypt the file.
• Empty - Relativity Processing won't decrypt the file.

Archive type	Single password-protected file	Multiple password-protected files	Encrypt File Names property
RAR	√
Multi-part RAR	√

MSG to MHT conversion considerations

The following table provides details on the differences between how Relativity handles MSG and MHT files. This information may be especially useful if you plan on setting the Email Output field on the processing profile to MHT.

Category	Field/Attribute	MSG	MHT
Metadata fields	Show Time As	This field sometimes appears in the extracted text from MSG files when not explicitly stated in the MSG file itself. The default for a calendar invite is to show time as "busy;" the default for a cancellation is to show time as "free."	"Show Time As" will not appear in the extracted text if the default value is populated.
Metadata fields	On behalf of	This field is sometimes present in text from MSG. In some cases, this field is populated with the same value as the From field.	"On behalf of" will not appear in the extracted text.
Interline spacing	N/A	The expected number of blank lines will appear in the extracted text. Line wrapping for long paragraphs will also be present.	In some cases, the text in MHT format has fewer blank lines than the text from MSG. In addition, there is no built-in line wrapping for long paragraphs.
Intraline spacing	N/A	White-space characters are converted to standard space characters.	White-space characters may remain as non-breaking spaces.
Email addresses	Email	When an MSG is converted to MHT, the text is extracted from the MHT using OutsideIn. This can lead to a loss of data.	If joe.smith@acme.com renders as Joe Smith in the MHT, the email address is not captured in the extracted text.

Microsoft Office child extraction support

Notable unsupported file types

Processing doesn't support files created with the following programs and versions:

Product category	Product name and version
DOS Word Processors	DEC WPS Plus (DX) Through 4.0 DEC WPS Plus (WPL) Through 4.1 DisplayWrite 2 and 3 (TXT) All versions DisplayWrite 4 and 5 Through Release 2.0 Enable 3.0, 4.0, and 4.5 First Choice Through 3.0 Framework 3.0 IBM Writing Assistant 1.01 Lotus Manuscript Version 2.0 MASS11 Versions through 8.0 MultiMate Versions through 4.0 Navy DIF All versions Nota Bene Version 3.0 Office Writer Versions 4.0 through 6.0 PC-File Letter Versions through 5.0 PC-File+ Letter Versions through 3.0 PFS:Write Versions A, B, and C Professional Write Versions through 2.1 Q&A Version 2.0 Samna Word IV+ Versions through Samna Word SmartWare II Version 1.02 Sprint Versions through 1.0 Total Word Version 1.2 Volkswriter 3 and 4 Versions through 1.0 Wang PC (IWP) Versions through 2.6 WordMARC Plus Versions through Composer WordStar Versions through 7.0 WordStar 2000 Versions through 3.0 XyWrite Versions through III Plus
Windows Word Processors	Adobe FrameMaker (MIF) Version 6.0 Hangul Version 97, 2002 JustSystems Ichitaro Versions 5.0, 6.0, 8.0, 13.0, 2004 JustWrite Versions through 3.0 Legacy Versions through 1.1 Lotus AMI/AMI Professional Versions through 3.1 Lotus Word Pro Millenium Versions 96 through Edition 9.6, text only Novell Perfect Works Version 2.0 Professional Write Plus Version 1.0 Q&A Write Version 3.0 WordStar Version 1.0
Mac Word Processors	MacWrite II Version 1.1
Disk Images	Symantec Ghost
Spreadsheets	Enable Versions 3.0, 4.0, and 4.5 First Choice Versions through 3.0 Framework Version 3.0 Lotus 1-2-3 (DOS and Windows) Versions through 5.0 Lotus 1-2-3 (OS/2) Versions through 2.0 Lotus 1-2-3 Charts (DOS and Windows) Versions through 5.0 Lotus 1-2-3 for SmartSuite Versions 97 and Millennium 9.6 Lotus Symphony Versions 1.0, 1.1, and 2.0 Microsoft MultiPlan Version 4.0 Mosaic Twin Version 2.5 Novell Perfect Works Version 2.0 PFS: Professional Plan Version 1.0 Quattro Pro (DOS) Versions through 5.0 Quattro Pro (Windows) Versions through 12.0, X3 SmartWare II Version 1.02 SuperCalc 5 Version 4.0 VP Planner 3D Version 1.0

In addition, processing doesn't support the following files:

• Self-extracting RAR files
• PEM certificate files
• Apple i-Works suite (Pages, Numbers, Keynote)
• Apple Mail:
  • .emlxpart
  • .partial.emlx

  Note: The .emlxpart and .partial.emlx are distinct from the .emlx file extension, which is supported by processing.

• Audio/Video files
  • .wav
• iCloud backup files
• Microsoft Access
• Microsoft Works
• Raw partition files:
  • ISO
  • NTFS
  • HFS

Note: For information on the limitations and exceptions to our supported file types, see Supported file types.

Supported container file types

The following file types can act as containers:

File type	Extensions
Bloomberg	XML We do not support Instant Bloomberg XML files.
Cabinet	CAB We do not support multi-part CAB files. We do not support Password Protected CAB files.
EnCase	E01, L01, LX01
AccessData Logical Image	AD1 We offer support for processing both single and multi-part non-encrypted AD1 files. For encrypted AD1 files, only single part files are supported. For multi-part AD1 files, you must decrypt the files prior to processing. See Lotus Notes considerations for more information.
iCalendar	ICS For Outlook meeting invites, the email that is sent with the meeting invite (the MSG) will have a sent date that reflects when the sender sent out the meeting request. The resulting calendar file that is then added to the user's Outlook calendar (the ICS) will not include a sent date, as the date doesn’t apply to the calendar file itself.
Lotus Notes Database	NSF. See Multi-part container considerations for more information.
MBOX Email Store	MBOX MBOX is a standard format, in which case it doesn't matter whether you're using a Mac folder format or a Unix file format.
Outlook Offline Storage	OST
Outlook Mail Folder	PST Relativity assigns duplicate hash values to calendar invites, as it does with email messages and other documents.
Outlook Express Mail Folder	DBX
PDF Portfolio	PDF
RAR	RAR You don't need to combine multipart RAR or TAR files before processing them.
Relativity Collection container	RCC
TAR (Tape Archive)	TAR You don't need to combine multipart RAR or TAR files before processing them.
Zip	7Z Relativity doesn't handle multipart ZIP files, which are extensions of WinZIP files. When dealing with archives, there is no limit to the number of layers deep Relativity Processing will go to extract data. It will extract until there is no more data to be extracted. Inventory, however, only extracts data from first-level documents. For example, you have a .ZIP within a .ZIP that contains an email with an attached Word document, inventory only extracts up to the email.
Zip	ALZIP
Zip	BZ2
Zip	GZ
Zip	ZIP
Zip	Z

Lotus Notes considerations

Note the following about how Relativity Processing handles NSF files:

• Relativity Processing doesn't perform intermediate conversion on NSF files, meaning that we don't convert them to PST or DXL before discovering them. This ensures that we don't miss any document metadata during processing.
• Relativity Processing preserves the original formatting and attachments of the NSF file. In addition, forms are not applied, since they are designed to hide information.
• Relativity Processing extracts the contents of NSF files and puts them into individual MSG files using the Lotus Notes C/C++ API directly. This is because NSF doesn't have its own individual document entry file format. All of the original Lotus Notes metadata is embedded in the MSG, meaning if you look at the document metadata in an NSF within Lotus, all of the metadata listed is embedded in the MSG. In addition, the original RTF/HTML/Plaintext document body is written to the MSG. Relativity handles the conversion from NSF to MSG files itself, and any errors regarding metadata or the inability to translate content are logged to the processing Errors tab. Relativity can process the following NSF items as MSGs:
  • Contacts
  • Distribution lists
  • Calendar items
  • Emails and non-emails

This is an example of an original NSF file before being submitted to the processing engine:

This is an example of an NSF file that has been converted to an MSG:

Multi-part container considerations

When processing a multi-part container, the first part of the container must be included. If the first part of the container is not included, the Processing engine will ignore the file.

ICS/VCF file considerations

ICS/VCF files are deduplicated not as emails but as loose files based on the SHA256 hash. Since the system now considers these loose files, Relativity is no longer capturing the email-specific metadata that it used to get as a result of ICS/VCF files going through the system's email handler.

The following table breaks down which metadata values the system will populate for ICS files:

The following table breaks down which metadata values the system will populate for VCF files:

Container file types supported for the password bank

The following container file types are supported by Relativity for Password Bank in Inventory.

File type	Extensions
Lotus Notes Database	NSF
PDF Portfolio	PDF
PST	PST
RAR	RAR
Zip	7Z
Zip	ALZIP
Zip	ZIP
Zip	Z
Zip	BZ2
Zip	GZ

Non-container file types supported for Password Bank in Inventory

The Password Bank also supports the following non-container formats:

• PDF
• Excel*
• Word*
• PowerPoint*
• S/MIME
• P7M

* Except DRM or custom encryption