If the email addresses are missing after conversion of your MSG file, the most likely culprit is that the email addresses are actually not contained within the MSG file itself.
Most company environments are set up using Active Directory, which means the "email address" (as far as the MSG file is concerned) looks like this:
/O=SOME_COMPANY/OU=EXCHANGE_GROUP/CN=RECIPIENTS/CN=EMPLOYEE_1
Instead of what you might expect, a more traditional SMTP-type address like:
employee_1@some_company.com
In fact, MSG files created by more modern versions of Outlook typically contain both variants, but especially older ones may only have the Exchange-type. When possible, the converted EML files from MSG Viewer for Outlook will preferentially return the traditional SMTP-style @some_company.com addresses.
The other style, /O=.... , is referred to as an X.400, X.500, IMCEA, and/or Exchange-type address and is not particularly useful outside of the organization itself. Without ActiveDirectory access at the originating company, there is no way to perform a lookup to turn the first type of email address into the second. In this example, /O=SOME_COMPANY could just as easily be /O=I343G, depending on how that company's IT department is structured. Furthermore, there are characters allowed in this Exchange-type of address (like spaces or slashes) that make it an invalid email address and there is a risk of crashing the email client if we try to import these.
Because we have to reconcile these cases on a Mac, we have opted for the following approach: 1) Where possible, return the SMTP-type email address; 2) Where not possible, return a blank email address and add a Sender header to the email headers where this Exchange-type address can be viewed (typically, only by power users).
If you're a power user or forensic technician and have further feedback for us on this discussion, we'd love to hear from you!