Zend_Mail was initially a very popular component in ZF1, as it provided a fluent interface for creation of mail messages, abstraction around the transport used to send messages, and reasonable attachment support.
Several problems present themselves, however.
- The relationships between classes are inverted. Current, Zend_Mail is capable of sending itself, and either requires that you provide a default transport, or pass a transport to the send() method. This makes cloning of messages expensive, sending of many messages at once expensive, and muddies configuration of mailers. Ideally, the mail transport should be the base object, and mail messages should be passed to the transport to send.
- Message assembly has largely occurred in the transports; this should be the responsibility of the Message itself.
- Numerous issues exist regarding MIME encoding as well as unicode support of mail messages.
- It's relatively difficult to provide non-standard headers to a mail message.
- Attachments are not intuitve.
I propose the following core architecture for the Mail component:
- Mailer: an interface with a single method, send($message). $message could be either a single message of type Message, or a collection of messages.
- We would supply mailers for Sendmail, SMTP, and the filesystem at the minimum
- Message: a class that aggregates the following:
- To, From, B/CC, and Reply-To Addresses
- Arbitrary Headers
- De/Serialization methods (specifically, from/to string)
- Address: a value object containing a name and email
- Header: a value object containing a fieldName and fieldValue
- Headers: an aggregate of Header objects
- Attachment: a value object containing:
- Content (which could in turn be made up of Attachments)
- Attachments: an aggregate of Attachment objects. Additionally:
- A Mime boundary
- Convenience methods such as "isMultiPart()" (do we have > 1 attachments)
- MessageCollection: a collection of Message objects
The To, From, B/CC, Reply-To, and Subject values would in turn populate individual Header objects.
The primary unit of usage is a Mailer.
You create Message objects and pass them to your mailer.
The fluent API of a Message object can take arguments that can be used to create the appropriate objects, or actual concrete instances of those objects. This allows sculpting the message exactly how one wants, including nesting attachments, setting specific attachment headers, etc.
- Easier to test base functionality of Messages, including serialization to string.
- Easier to test discrete operations of each mailer type.
- More flexibility in message creation.
A number of feature requests/concerns were raised in the Zend_Mail 2.0 proposal. I'm specifically not addressing several of these, as I think they fall outside the responsibilities of a mail component. As examples:
- Templating. Since the bodies can be seeded separately, and message objects will be basically value objects, I see no value to adding templating capabilities. This sort of thing can be easily achieved in userland, and would prevent coupling of the Mail component with the View layer.
- Inline images. I'd like to address this, but I'm not sure how we should approach it, as the proposed use cases require parsing attachments for links as well as transformation of the parsed attachments.
- CSS inlining. Same argument as for Inline images
- Advanced IMAP/Storage operations. This proposal is really directed primarily at the generation and sending of emails, not reading of them. Such requirements should be addressed in a separate proposal.
The first three items feel like a fit for a filtering or event system, and we could potentially compose an EventManager into the Message and/or Mailer classes to allow such operations. However, I'd like feedback as to where in the workflow we should trigger events.