Skip to end of metadata
Go to start of metadata

<p>This page shall contain all contributions to the Zend_Mail 2.0 component.</p>

<p>This component will undercome huge internal refactorings due to synergies that should be used between Mime, Mail and Mail_Storage components.</p>

<p>Lets continue <a href="http://framework.zend.com/wiki/display/ZFDEV2/Mail+sending+and+building+enhancements+2.0">here</a>. I (<ac:link><ri:user ri:username="freak" /></ac:link>) had missed this page...</p>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 12, 2009

    <p>I think one big improvement should be the handling of attachments (large attachments) also on the Zend_Http_Client side. file_(get|put)_contents isnt a good solution with a 500mb file.<br />
    Adding handling of streams here is the better way.</p>

    1. Nov 13, 2009

      <p>Of course we should support streams as much as possible. Zend_Mail_Storage_Maildir and Zend_Mail_Storage_Mbox are already returning Zend_Mail_Message_File/Zend_Mail_Message_Part, so each part has a getContent() method that takes an output stream as the first argument. Also Zend_Mime_Part supports streams as input, but the assembling doesn't use it.<br />
      On the other hand if you try to send a 500MB file via mail you should get what you deserve <ac:emoticon ac:name="wink" /></p>

      1. Dec 05, 2009

        <p>Yews i know but i have some environments where it is required to send larger files by mail. <ac:emoticon ac:name="smile" /> So it would be nice to have a focus also on that.</p>

  2. Dec 04, 2009

    <p>I think a class that handles MIME Type would be needed. For example, Zend_Mime_Type or Zend_Filter_File_MimeType</p>

    <p>The class should have 2 kinds method at least.</p>

    <p>1) simple converter from file's extension to MIME type.<br />
    it may be required for getMimeType() of Zend_Service_Amazon_S3 (mentioned in ZF-5709).</p>

    <p>2) information extracter from file with finfo() or getimagesize().<br />
    Or we might substitute it by getMimeType() of Zend_File_Transfer_Adapter</p>

    1. Dec 05, 2009

      <p>Using Zend_Mail you will propably not transfer a file, so Zend_File_Transfer is not the right component.</p>

      1. Dec 06, 2009

        <p>Thank you for comment.</p>

        <p>So it had better to be implemented in the components to need,<br />
        because the class does not seem to be necessary by existing Zend_Mime and Zend_Mail.</p>

  3. Dec 06, 2009

    <p>The Return-Path header should be not handled in Zend_Mail but in Zend_Mail_Transport.<br />
    So, it would be better to deprecate following methods and property in Zend_Mail.</p>

    <p>setReturnPath(), getReturnPath(), clearReturnPath().<br />
    $_returnPath.</p>

    <p>BTW, does anyone need setter that passes return-path to 5th parameter of mail() in Zend_Mail_Transport_Sendmail ?</p>

    1. Mar 28, 2010

      <p>Please can you explain why it shouldn't be handled in Zend_Mail?</p>

      <p>Also, yes I need setter and getter methods on either Zend_Mail or Zend_Mail_Transport_Abstract (i.e. to support Smtp as well), preferably the former.</p>

  4. Dec 17, 2009

    <p>In my opinion, the current Zend_Mail architecture is lacking a rendering engine - an embedded Zend_View object and a view script path inference mechanism. A rough draft can be found here:
    <a class="external-link" href="http://pastie.org/747223">http://pastie.org/747223</a>.</p>

    1. Dec 19, 2009

      <p>I disagree. This can already be done by constructing a view object and rendering it. Nice and decoupled, lets keep it that way.</p>

      1. Jan 07, 2010

        <p>I agree that this can already be done (just as sending mail in PHP without Zend_Mail, but somehow that's not an argument against Zend_Mail <ac:emoticon ac:name="smile" />), but it's inconvenient, especially when you're sending mails outside a controller context (i.e. a cronjob). This solution provides a convenient ready-to-use pattern, MVC-style, granting you free access to things like view helpers, which encourages concern separation.</p>

        <p>I'm betting 99% of mails sent through Zend_Mail are (or could be) using all the goodness of access to view helpers, script path inference, etc.</p>

        1. Jan 07, 2010

          <p>Using Zend_View is very trivial already, and there's no need to build an additional MVC pattern into Zend_Mail to accomplish what you describe.</p>

          <p>Since you have access to view helpers already when using Zend_View, I really don't see any advantages to coupling the components; simply use Zend_View to generate the HTML body for your email, and pass that to the mail object.</p>

          <ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
          $view = new Zend_View(array('encoding' => 'UTF-8'));
          $view->addScriptPath('path/to/email/templates');
          foreach ($recips as $recipient) {
          $view->assign(array(
          'name' => $recipient->getFullName(),
          'email' => $recipient->getEmail(),
          'source' => $recipient->getSource(),
          ));
          $mail = new Zend_Mail();
          $mail->addTo($recipient->getEmail())
          >setBodyHtml($view>render('campaign.phtml'));
          $mail->send();
          }
          ]]></ac:plain-text-body></ac:macro>
          <p>It would likely take just as many, if not more, lines of code to accomplish this if we were to build in templating support into Zend_Mail. I honestly see no benefits to coupling the two, but do see a lot of maintenance and testing overhead.</p>

          1. Jan 10, 2010

            <p>Yes indeed this is a very nice way. It would be perfect if you can also configure Zend_Mail and Zend_Mail_Transport_<method> to enable you to easily configure different mail layouts for different purpose. E.g. if you have different mail layouts for request, contact, notification, newsletter, ..., would you render each type of this layout like the suggested way above? In the Rapid application development you should not need to creat for each email purpose a new solution. Simply configure and go on with Email design. Normaly you send emails in the development environment via smpt and in the production environment via sendmail (development on Windows server on Linux).</p>

            <p>My solution is that way:<br />
            I have inherited the Zend_Mail class to handle configution options in ini file<br class="atl-forced-newline" /></p>
            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            email.transport.method = smtp | sendmail

            ; optionaly
            email.transport.server = ...
            email.transport.auth = ...
            email.transport.username = ...
            ...
            email.<scriptname>.layout.layoutPath = ...
            email.<scriptname>.layout.suffix = "phtml"
            email.<scriptname>.layout.encoding = ...
            ...
            ]]></ac:plain-text-body></ac:macro>
            <p>For each <scriptname> there must be a script with the same name and suffix in layoutPath. The inherited Zend_Mail renders the given script with all available View Helpers.</p>
            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            $helper_paths = Zend_Layout::getMvcInstance()>getView()>getHelperPaths() ;

            foreach ($helper_paths as $prefix => $paths) {
            foreach ($paths as $path)

            Unknown macro: { $view->addHelperPath($path, $prefix) ; }

            }
            ]]></ac:plain-text-body></ac:macro>
            <p>The inherited Zend_Mail provides also a sendMail method with the arguments "scriptname" and an array of mail and script parameters<br class="atl-forced-newline" />
            Example:</p>
            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            $mail->sendMail("request", array(
            "emailTo" => ..
            "subject" => ..
            "scriptVars" => array(
            "customer" => $customerData,
            "product" => $productData,
            ..
            )
            ));
            ]]></ac:plain-text-body></ac:macro>
            <p>Each ScriptVar is assigened to the view script, wich will be rendered within the inherited Zend_Mail and send to the recipient via Zend_Mail_Transport_Smtp or Zend_Mail_Transport_Sendmail according to configured transport method.</p>

          2. Jan 21, 2010

            <p>I'd rather make use of the view object set up for Zend_Layout MVC instance during bootstrapping (to make its construction DRY), but wouldn't want to couple every mail sending logic with fetching the view from there (as in Zend_Layout::getMvcInstance()->getView());</p>

            <p>Putting an (optional) ready-to-use view object in Zend_Mail would reduce this coupling and encourage seperating view logic. I don't believe there are serious applications that create the body of the e-mail with setBodyHtml('My very long string created manually'), and I think it's something natural to use the Zend_View rendering mechanism for that.</p>

  5. Mar 28, 2010

    <p>I've built an implementation of DKIM signing which the company I work for is willing to contribute to the Zend Framework.</p>

    <p>e.g.</p>
    <ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
    $dkimSigner = new Authentication\Dkim(array(
    'privateKeyFile' => '/path/to/private.key',
    'passphrase' => 'mypassphrase',
    'domain' => 'signerdomain.com',
    'selector' => 'selector1',
    ));

    $mail->addAuthentication($dkimSigner);]]></ac:plain-text-body></ac:macro>

    <p>The AbstractTransport (or however its named in 2.0), would then have to call a hook to the authentication class to add the DKIM-Signature header.</p>

    <p>Additional methods I may be interested in writing could be S/MIME and PGP (with those also allowing encryption).</p>

  6. Jan 16, 2011

    <p>The correct link to the other discussion: <a class="external-link" href="http://framework.zend.com/wiki/display/ZFDEV2/Zend+Mail+2.0">http://framework.zend.com/wiki/display/ZFDEV2/Zend+Mail+2.0</a></p>