Add the ability to parse multipart MIME email strings#255
Open
settermjd wants to merge 9 commits intolaminas:2.26.xfrom
Open
Add the ability to parse multipart MIME email strings#255settermjd wants to merge 9 commits intolaminas:2.26.xfrom
settermjd wants to merge 9 commits intolaminas:2.26.xfrom
Conversation
This change adds the ability to instantiate Message objects from multipart MIME email strings. Most of the functionality was already there; there was even a commented out stub that outlined the start of what was required. However, I think because the supporting functionality was lacking in laminas-mime, it was not implemented. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
Slamdunk
requested changes
Nov 21, 2023
Contributor
Slamdunk
left a comment
There was a problem hiding this comment.
I like this, but we need a green build
Author
I'll get it sorted. |
This change adds assertions for the content of the various parts of message. The intention is to be able to check deeper into a multipart message to confirm that it is as expected. As the underlying test data contains a PDF file, it adds the smalot/pdfparser to simplify working with PDF files. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
ccce0e7 to
aa973f5
Compare
Author
|
Hey @Slamdunk, at this stage, I've done all I can without laminas/laminas-mime#36 being merged, as this one is heavily dependent on it. Any chance with support to get it reviewed and merged? |
From my understanding of the various specs, primarily RFC 1341, the existing functionality for setting message headers was wrong. Given that, I've made this change, which should bring it into line with the spec, corrects issues with the existing tests, and sets one existing test as skipped (for the time being). Firstly, it removes the functionality that sets headers on the main message from message sub-parts. Secondly, equally as importantly, it sets the required headers, along with their defaults, based on the message's composition. I won't get into detail here, as it's documented in the code and in the updates to the documentation. Finally, the change also cleans up some of the existing functionality as well, setting return types, as they're supported in the package's allowed PHP versions. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
This commit updates the relevant sections of the documentation to reflect the changes in how mime messages are created. It also does a little bit of cleaning up of the documentation as well. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
I think that I inadvertantly checked in a composer.lock file which referenced a local fork of laminas-mime that I was working on while patching the library. This change reverts that. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
After feedback from @MWOP, this change simplifies test data for testing the HTML part of an email. It removes SendGrid details, to ensure that the tests don't favour any given provider. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
This change adds three custom RecursiveIterator classes with the aim of simplifying working with message parts. - PartsIterator simplifies iterating over a recursive list of parts, as multipart mime email parts can themselves contain parts. - MessagePartFilterIterator is designed to use PartsIterator to filter out parts that are not the contents of a message, such as the plain text or HTML body. - AttachmentPartFilterIterator is designed to use PartsIterator to filter out parts that are not message attachments. Together, these iterators will help provide functionality for quickly retrieving a message's content and attachments, without leaving it to the user. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
You can iterate over all of the message parts in the calling code and extract the plain text and HTML body, as well as the attachments. However, I thought that this would be something that people would do regularly; so much so such that adding utility functions for doing so might be a great productivity win for the package. The documentation's been updated to reflect these additions so that they're as visible as possible, and readily discoverable. Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
aa973f5 to
e7d10b0
Compare
Signed-off-by: Matthew Setter <matthew@matthewsetter.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This change adds the ability to instantiate
Messageobjects from multipart MIME email strings. It's dependent on laminas/laminas-mime#36.Most of the functionality was already there; there was even a commented out stub that outlined the start of what was required. However, I think because the supporting functionality was lacking in laminas-mime, it was not implemented.
I'm submitting this PR for a couple of reasons. Partly because I'm not aware of another library or package that comes close, because I need the functionality, and because it seems worth finishing the existing implementation.