Some attachment properties are null terminated

[martinburchell]

Bug Metadata

• Version of extract_msg: [0.54.1]
• Your python version: Python [3.9.22]
• How did you launch extract_msg?
  • I used the extract_msg package

Describe the bug
First of all, thanks for providing msg-extractor. It's going to save us a ton of effort.

I've noticed that with the .msg files I'm seeing in the real world, some attachment properties, such as mimetype, dislayName and extension, are terminated with \x00. I don't see this with your unicode.msg example. Workaround is to call str.replace("\x00", "") wherever needed.

What code did you use or can we use to reproduce this error?

Run this script with the attached .msg file (remove .txt extension first!).

#!/usr/bin/env python

import sys

from extract_msg import openMsg

filename = sys.argv[1]

message = openMsg(filename, delayAttachments=False)
print(f"Properties for {filename}:")
for attachment in message.attachments:
    for name in ("mimetype", "displayName", "extension"):
        if value := getattr(attachment, name):
            print(f"{name}: {value.encode()}")

Is there a message.msg file you want to share to help us reproduce this?

• [X ] Uploaded message (drag and drop on this window)

null_terminated_attachment_properties_test.msg.txt

[TheElementalOfDestruction]

Them being null terminated sometimes is actually intended behavior because it means the underlying data includes the null termination. However, it not being handled by certain functions using said data would be unintended, so I'll go and verify that all the properties are properly sanitized before internal use

Unfortunately this is one of those cases where there may be a use to keeping the unsanitized versions accessible to the user because it can show the file was generated by something non-standard or had weird stuff generally happen to it

[martinburchell]

Them being null terminated sometimes is actually intended behavior because it means the underlying data includes the null termination. However, it not being handled by certain functions using said data would be unintended, so I'll go and verify that all the properties are properly sanitized before internal use

Unfortunately this is one of those cases where there may be a use to keeping the unsanitized versions accessible to the user because it can show the file was generated by something non-standard or had weird stuff generally happen to it

Thanks for the explanation and for checking this out.

All of the files I've been testing with have come from Outlook itself so naively I'd expect that to be standard and not weird! Maybe if it is expected behaviour, there could be a short note in the code documentation for each of the properties (assuming this is meant to be a public API). Regardless, I have my workaround so I'm happy.

[TheElementalOfDestruction]

The thing about trying to make a note on the properties is that null termination can happen on every single string property. I'm not exactly sure where it would be best to put it that wouldn't require adding a note in I've 100 places but would also be easily accessible

[martinburchell]

The thing about trying to make a note on the properties is that null termination can happen on every single string property. I'm not exactly sure where it would be best to put it that wouldn't require adding a note in I've 100 places but would also be easily accessible

Well we have it documented here if nothing else.