Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for returning an EmailMessage object #248

Closed
ndrsn opened this issue Apr 5, 2022 · 6 comments
Closed

Support for returning an EmailMessage object #248

ndrsn opened this issue Apr 5, 2022 · 6 comments
Labels
Complete This feature has been fully implemented. enhancement

Comments

@ndrsn
Copy link

ndrsn commented Apr 5, 2022

Hi, thank you for all the work you've put into this! I need to parse .msg files and this looks like a good fit.

However, I'd like to leverage Python's native email library and interface as much as possible. convert-outlook-msg-file is a module to convert msg files to an .eml / rfc822 format, which is what email can parse.

Would there be interest in a pull request that adds a method to extract_msg.message.Message which returns an email.EmailMessage object, leveraging some of the code in convert-outlook-msg-file?

@ndrsn ndrsn changed the title Support for returning an EmailMessage object based Support for returning an EmailMessage object Apr 5, 2022
@TheElementalOfDestruction
Copy link
Collaborator

Related to #56

I would like to have some form of interface to the email module for certain parts, as some other parts of the messages can need them, but haven't had the time to sit down and actually learn how to use it enough to implement anything. Looking at that conversion script you mentioned, it looks like there is little to know code that could be leveraged without ripping it from the module, especially in the case of embedded msg files. Of course, that's more from just a cursory glance so I could be wrong.

Such a feature is low on the priority list and would likely take a long time to get to (especially because of how busy I am right now, thanks life) so if someone wanted to work on it then I would be happy to look at a pull request. Of course, it would need to be a pull to next-release, but it also wouldn't need to be done entirely alone. I'm happy to discuss things about the process with someone who is developing it.

@ndrsn
Copy link
Author

ndrsn commented Apr 5, 2022

Ah apologies, I missed #56!

it looks like there is little to know code that could be leveraged without ripping it from the module

I'm sorry, I think I wasn't very clear. What I meant, was: because msg-extractor already does most of the parsing, and it wouldn't make sense to duplicate that, I was proposing using convert-outlook-msg-file only as inspiration for the fields to copy/extract, not as an actual dependency.

Such a feature is low on the priority list and would likely take a long time to get to

I opened this issue because such a conversion is something I need and want to work on — and would prefer it be part of a larger, maintained library than a little script sitting somewhere in my own repository, and was inquiring whether there would be interest in reviewing/merging such a pull request 😊

The idea is (so far) to add an asEmailMessage method (naming is of course open for discussion) to the Message class, which returns an EmailMessage instance with as much information copied over from the original .msg file as is possible and makes sense.

There would be a big caveat to using this method, as I'm not clear what edge cases there may be, or how much information is currently extracted from .msg files, or more importantly which information isn't. The included test cases would make clear what the limits of the method are.

@TheElementalOfDestruction
Copy link
Collaborator

Ah apologies, I missed #56!

The issue there seems to be about a lot more than just the email module so this should still stand as it's own. It is related though.

I'm sorry, I think I wasn't very clear. What I meant, was: because msg-extractor already does most of the parsing, and it wouldn't make sense to duplicate that, I was proposing using convert-outlook-msg-file only as inspiration for the fields to copy/extract, not as an actual dependency.

Ah, I see. That makes a lot more sense and allays most of my issues.

The idea is (so far) to add an asEmailMessage method (naming is of course open for discussion) to the Message class, which returns an EmailMessage instance with as much information copied over from the original .msg file as is possible and makes sense.

The naming sounds perfect, and I'll be happy to point you to whatever data fields you are trying to find in the message for this task.

There would be a big caveat to using this method, as I'm not clear what edge cases there may be, or how much information is currently extracted from .msg files, or more importantly which information isn't. The included test cases would make clear what the limits of the method are.

Just because something currently isn't extracted doesn't mean it can't be. For most fields, they can be added rather easily with just a few lines of code. We actually have convenience functions to make this a lot easier. If you would prefer I can be reached about this (when I am free, of course) by email or on the Discord. You can also take a look at the properties in the code to find out how this is done.

@ndrsn
Copy link
Author

ndrsn commented Apr 5, 2022

Great! I'll make a start and reach out with any questions on Discord when they arise. Thanks :)

@TheElementalOfDestruction
Copy link
Collaborator

BTW if you would be interested I also have another issue that will require the use of the email module. Signed emails will put a mime type email content as the attachment and I need a way to reliably access the attachments on that as well as the body and everything. Let me know if you are interested in helping with that. Issue is #223

@TheElementalOfDestruction
Copy link
Collaborator

I finally got around to adding this feature. Anything that is a subclass of MessageBase can be converted to an EmailMessage instance now in version 0.43.0. Let me know if you have any issues with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Complete This feature has been fully implemented. enhancement
Projects
None yet
Development

No branches or pull requests

2 participants