-
-
Notifications
You must be signed in to change notification settings - Fork 172
Todo
Destiny Peterson edited this page Jan 1, 2023
·
3 revisions
This page is a list of all the current items remaining on the todo list for the module. This will be updated as things are completed and as things are discovered, but it allows me to more easily update the todo list without having to commit to the master branch.
TODO:
- Tests (ie. unittest).
- Finish writing a usage guide.
- Improve the intelligence of the saving functions (mostly done. Few more issues remaining).
- Improve README.
- Create a wiki for advanced usage information (in progress, as you can see).
- Allow extraction of plain text from HTML body.
- Finish filling out properties for
MSGFile
andMessageBase
. - Finish proper routing for all known MSG file types (only the ones that have documentation).
- Allow messages to return an
EmailMessage
object for use in other code. - (Possibly) add parsing for .olm files, if possible. If I can reasonably understand the format or find documentation, then I'll add support, although it may be made into a separate package due to not being an MSG file.
- Add handling for embedded msg files on signed messages.
- Add option to, where possible, save raw MSG files instead of just always saving the embedded ones. This would end up sort of acting like the
skipEmbedded
option ofAttachment.save
. This means that embedded MSG files on a signed message would definitely be saved, even if regular embedded MSG files cannot
- Add option to, where possible, save raw MSG files instead of just always saving the embedded ones. This would end up sort of acting like the
- Do something about the special attachments. Easiest solution would be to completely ignore them and just give the user a message about that.
- Current solution (added in 0.36.1) is to add an option to just blatantly ignore them to
MSGFile.save
and the command line. This is not the preferred solution. - Preferred solution would be a way to handle at least outlook
signaturesembedded images in a way that makes sense. Unfortunately nothing about it is clear and Microsoft has decided to keep the implementation close to their chest as far as I can tell, so this may not be possible. (Update: I've gathered a large amount of information necessary to allow me to (mostly) figure this out. Currently a branch of the module has partial ability to actually do this, though determining rendered characters is currently posing a bit of a problem. Additionally, HTML generated from the plain text body (as it seems that having an actual HTML body prevents these types of images from existing) can have errors with email addresses and links in them causing the count of rendered characters to be incorrect.)
- Current solution (added in 0.36.1) is to add an option to just blatantly ignore them to
- Fix issue with RTF saving. Current header injection methods mean that it is possible for the header to be in an invalid location, causing the RTF stream to be invalid. This will likely require actually writing some form of parser to update the RTF and inject the header. So long as modifications to the RTF lead to the exact same graphical output, I don't think it would be a big deal for the code to modify it.