Access to text/plain or text/html body part?

[C-Duv]

Would be nice to have an "easy" way of accessing the human-text-body part like it was possible with ZF1's Zend_Mail (using getBodyText(), getBodyHtml()).

With current implementation of Zend\Mail\Message, theses human bodies are anonymous parts of the body (a Zend\Mime\Message). Once added there is no easy way of fetching the HTML body for instance.

When building an e-mail it can be useful to alter the already-set body.

My workaround is to loop on each Zend\Mime\Part and find the one(s) having "text/html" type (or "text/plain" when looking for plain text body).

[weierophinney]

zend-mail uses zend-mime to address multi-part emails. One key aspect of multi-part emails is that even with multipart/alternative, you can have more than one part using the same type.

The impact this has is that getBodyText() and getBodyHtml() could lead to ambiguous results in cases where more than one part has the same type. As such, we need to decide:

• Should situations such as these throw an exception?
• Or should the first part matching the criteria return the result?

Thoughts?

[Maks3w]

I agree the API of Zend\Mail is not very friendly. It's too technical

Sometime Ago I had to write this project for extract the files attached in a message https://bitbucket.org/startupbootstrap/email-attachments/

[C-Duv]

I get why the \Zend\Mime API is following MIME "flexibility" of content and the impact it has on the \Zend\Mail API.

@weierophinney said:

Or should the first part matching the criteria return the result?

According to RFC 1521 - 7.2.3 The Multipart/alternative subtype

In general, user agents that compose multipart/alternative entities must place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. Receiving user agents should pick and display the last format they are capable of displaying. In the case where one of the alternatives is itself of type "multipart" and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both.

What I would humbly suggest (this is what I ended coding): adding a getter \Zend\Mime\Message::getPart($type, $revIndex) to get a \Zend\Mime\Part by content type that would, by default, return the last (following RFC 1521 advice) matching Part and accept an optional index argument to match the _n-_last (similar, in a way, to how it's done on LDAP nodes with \Zend\Ldap\Node\AbstractNode::getAttribute($name, $index = null)). This would give more power to the developer (the library user). A more technical \Zend\Mime\Message::getParts($type) returning an array of every \Zend\Mime\Part of given type could also be added for advanced use-cases.

[Freeaqingme]

The impact this has is that getBodyText() and getBodyHtml() could lead to ambiguous results in cases where more than one part has the same type.

You could of course implement these methods, but have them return an array of body parts. That would allow for easy access, yet transparently work if there's a multitude of parts with the same content type.

[djozsef]

I like @Freeaqingme 's idea, but I think it should be an other method, sg. like getHtmlParts() and get TextParts(). It could return an ArrayObject or Iterator compatible stack with the last, preferred part of that type (as per RFC1521) at the first position. The getBodyHtml() and getBodyText() methods then would return the preferred part of the kind. I have an other suggestion under #67 related to this. What is your opinion on that

[michalbundyra]

This repository has been closed and moved to laminas/laminas-mail; a new issue has been opened at https://github.com/laminas/laminas-mail/issues/73.