Skip to end of metadata
Go to start of metadata

<p>Ideas for Zend\Mail 2.0 that still need to be converted into decent requirements</p>
<ul>
<li>Zend_Mail should represent an instance of an email.</li>
<li>Support verp</li>
<li>Use a common class that represents a server</li>
<li>"make attachments more clever" (encoding)</li>
</ul>

<p>Protocol features:</p>
<ul>
<li>EHLO keyword parsing <a href="http://www.faqs.org/rfcs/rfc1869.html">http://www.faqs.org/rfcs/rfc1869.html</a>
<ul>
<li>PIPELINING support <a href="http://www.faqs.org/rfcs/rfc1854.html">http://www.faqs.org/rfcs/rfc1854.html</a>, see ticket <a href="http://zendframework.com/issues/browse/ZF-8528">ZF-8528</a></li>
<li>STARTTLS support <a href="http://www.faqs.org/rfcs/rfc2487.html">http://www.faqs.org/rfcs/rfc2487.html</a>, see ticket <a href="http://zendframework.com/issues/browse/ZF-10758">ZF-10758</a></li>
<li>ENHANCEDSTATUSCODES support - <a href="http://www.faqs.org/rfcs/rfc1893.html">1</a> <a href="http://www.faqs.org/rfcs/rfc2034.html">2</a></li>
</ul>
</li>
<li>Support for IMAP ACL</li>
</ul>

<p>Even more tentative:</p>
<ul>
<li>Signing (PGP, DKIM, ADSP)</li>
<li>Templating (through Zend\View<ac:emoticon ac:name="question" />) & batching</li>
<li>CSS Inlining (put all css in their respective elements) <a href="http://premailer.dialect.ca/">1</a> <a href="http://www.campaignmonitor.com/css/">2</a></li>
</ul>

<p>Analysis of Zend_Mail 1.0</p>
<ul>
<li>When adding recipients name and email are filtered, and headers added. Making it hard to manipulate these once added.</li>
<li>The transports use properties rather than parameters. If only php supported threading there would be race conditions everywhere (for now, it's just unproper OOP).</li>
</ul>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 03, 2010

    <p>"When adding recipients name and email are filtered, and headers added. Making it hard to manipulate these once added."</p>

    <p>Maybe it would be good to resolve this "problem" similar to Zend_Pdf?<br />
    Each eMail part/object becomes a own class like Zend_Mail_Recipient(), and then setting the instance to the main Zend_Mail class.</p>

    1. Dec 03, 2010

      <p>It's funny you come with that suggestion, it's exactly what I just implemented the other night. I decided however to rename it to 'Address' because such object can also be used with 'from' addresses etc.</p>

      <p>See also <a href="https://github.com/Freeaqingme/zf2/blob/feature%2FmailRefactoring/library/Zend/Mail/AddressCollection.php">Zend_Mail_AddressCollection</a> & <a href="https://github.com/Freeaqingme/zf2/blob/feature%2FmailRefactoring/library/Zend/Mail/AddressCollection.php">Zend_Mail_Address</a>. Code is still pre-alpha but open for discussion.</p>

  2. Dec 03, 2010

    <p>Hi,</p>

    <p>i would like an easy implementation for such inline images:</p>

    <p><img src="data:image/gif;base64,DATEN"></p>

    <p>for example:</p>

    <p><img src="data:image/gif;base64,R0lGODlhmwDFAPcA ... rDYYCccQRQuzQp1cBAQA7"></p>

  3. Dec 03, 2010

    <p>-templating Support of Zend_View at minimum in templating. Maybe even Zend_Layout, I'm doing that in order to have several possible signatures etc.</p>

    1. Dec 03, 2010

      <p>If we build in templating (and I think we will) it will use Zend\View. What I'm unsure of however is what you want to do with Zend_Layout in this respect.</p>

      1. Dec 06, 2010

        <p>At my previous employer, I've build an extension to Zend_Mail that would accept data for Zend_View, the name of a 'template' and a views directory. If I would create a mail for template foo, before sending the mail it would look for and include:</p>
        <ul class="alternate">
        <li>

        Unknown macro: {view_dir}

        /foo.ptxt for the text/plain version</li>
        <li>

        /foo.phtml for the HTML version</li>
        <li>

        Unknown macro: {view_dir}

        /foo/* for attachements</li>
        </ul>

        <p>Attachments would be available in the HTML part as cid:bar.gif.</p>

      2. Sep 21, 2011

        <p>Manage different signatures for (the same) mails. One of my clients requested that and I implemented it Q&D. Turned out to be handy (to me)</p>

  4. Dec 04, 2010

    <p>The updated component requirements look really good.</p>

    <p>>> CSS Inlining (put all css in their respective elements) 1 2</p>

    <p>I think this would be an excellent addition. I've actually thought about writing my own a few times (talked myself out of taking it on). It would be nice if this were a separate component that was integrated with Zend_Mail|View as a filter (or something similar).</p>

    1. Dec 04, 2010

      <p>You're right. I'm not comfortable doing this in actually Zend\Mail. Where it should be implemented will have to be discussed.</p>

  5. Dec 04, 2010

    <p>Better encoding of attachments, I have had strange issues with the mime encoding using Zend_Mail a way of controlling the encoding would be great as I had to patch to change the line length of the base64 encoding.</p>

    <p>Also the api for attachments isn't very friendly.</p>

    <p>Is reading mail in the requirements?</p>

    1. Dec 06, 2010

      <p>I think the encoding of attachments may refer to ZF-10130?</p>

      <p>About the api for attachments, what kind of improvements would you like to see?</p>

      <p>>> Is reading mail in the requirements?<br />
      There are no requirements yet, but it certainly will be in it <ac:emoticon ac:name="wink" /></p>

  6. Dec 05, 2010

    <p>Return-path, as with DKIM, is usually considered a mailserver problem, however in the same set of circumstances, an application may want to alter the return-path, for example for application-level subscription controls via bounce responses.</p>

    <p>I've written in my previous job a system based on Zend_Mail, which uses Return-Path and DKIM to provide application-level mail services (kind of like MailChimp or similar).</p>

    <p>Whilst I agree the logic for getReturnPath in Zend_Mail returning from may not be right, the SMTP specification states that the return path should be set via MAIL FROM, as its the format<br />
    MAIL FROM:<reverse-path></p>

    <p>Please could some resemblance of this be kept in the Smtp class and not removed? There is a filed bug for it which is now fixed in 1.11 branch #ZF-8988</p>

    1. Dec 07, 2010

      <p>You're right. though the responsibility of returning the from address when the return path is requested will be moved to the smtp transport instead of the mail object though. Does that make sense?</p>

      1. Dec 11, 2010

        <p>Yes, the Sendmail transport (and sendmail in general) doesn't by default send the From address as the return path, whereas the Smtp transport would require it, so it would make sense to move the logic to the Smtp class.</p>

        <p>If the Sendmail transport is also not going to look at the Mail class' getReturnPath, I would also recommend removing the entire return path capability from the Mail class and just having getters and setters in the Smtp class, however I'd prefer if the Sendmail transport was more intelligent and would set the additional parameters to pass in the return-path via the -f option if one was set.</p>

  7. Dec 05, 2010

    <p>Some further ideas I've had</p>

    <p>IMAP UID operation support. In offline application support (and indeed multi-http requests), I find it easier to perform operations on UIDs than message numbers. Performance benefits in some of the following ideas are possible as well through this.</p>

    <p>IMAP SEARCH support. An IMAP client isn't complete without this. The results are either in msgid or UID format based on operation.</p>

    <p>IMAP IDLE. Good for responsive action on scripted readers. It requires a bit of house-cleaning in the tracking of message counts and expunges.</p>

    <p>I've written partial/full implementations of these myself, so will try to contribute as much as I can.</p>

  8. Dec 06, 2010

    <p>Here are some items worth noting:<br />
    1. Automatic re-connect to SMTP servers<br />
    a. Extremely important when you have an email worker and get a timeout from the SMTP server.<br />
    b. Otherwise, being able to call disconnect then connect - this presently does not work.<br />
    2. Mail Reading<br />
    a. Implement Searching for Adapters in order to find corresponding messages - Basic Use Case: Bounce email box - may want to distinguish between original sender or subject line.<br />
    b. Bounce Email Handler - this is extremely tricky since they all return differently, but being able to easily implement a listener to an email box would be a nice to have.</p>

  9. Dec 07, 2010

    <p>when "making attachments more clever": a easy way to forward an email using Zend_Mail would also be clever (as attachment).</p>

  10. Jan 16, 2011

    <p>I don't remember if Zend_Mail can be used for inline images and an attachment. But, it's maybe already in the goal « making attachments more clever » <ac:emoticon ac:name="smile" /></p>

  11. Jan 16, 2011

    <p>When using Zend_Mail for writing a webmailer I had big performance problems and a really high memory usage. For example a mail is always loaded in total and then parsed. With mails 100MB in size this is very slow and uses much much RAM (many hundred MB).</p>

    <p>I first extended Zend_Mail_Storage_Imap to use my own Zend_Mail_Message class which I also needed to extend. Then I added features like BODYSTRUCTURE fetching and parsing, sorting, searching, batch copy(), batch store(), UID support and a separat expunge() function.</p>

    <p>I created issues for some of these functionalities (see below), all of them with patches or code snippets. None of them have been implemented since begin 2010. Nico Edtinger though about some kind of Zend_Mail_Storage_Set to support UIDs, ranges, search, sort etc.. But nothing happened.</p>

    <p>I also added methods to get only specific parts (sections) of a mail, so when needing only the body of a mail I don't want to fetch the whole 100MB mail but only the 2KB body. Or I just want to fetch a specific attachment. This is possible if you have the BODYSTRUCTURE.</p>

    <p>Because adding functionality on my own was this hard and there was still the problem of high memory usage I checked out zeta-components and their mail component, and they do many things better. Attachments are directly written to disk and not held in memory, each line of a mail is directly decoded when fetched, and is a bit easier to extend. It is not perfect, but easier to use and on a "better basis" to work with for a webmailer.</p>

    <p>Perhaps Zend\Mail 2.0 will be easier to extend and get more features for mail reading and parsing.</p>

    <p><a class="external-link" href="http://framework.zend.com/issues/browse/ZF-9138">http://framework.zend.com/issues/browse/ZF-9138</a></p>

    <p><a class="external-link" href="http://framework.zend.com/issues/browse/ZF-8858">http://framework.zend.com/issues/browse/ZF-8858</a></p>

    <p><a class="external-link" href="http://framework.zend.com/issues/browse/ZF-8513">http://framework.zend.com/issues/browse/ZF-8513</a></p>

    <p><a class="external-link" href="http://framework.zend.com/issues/browse/ZF-8488">http://framework.zend.com/issues/browse/ZF-8488</a></p>

    <p><a class="external-link" href="http://framework.zend.com/issues/browse/ZF-5655">http://framework.zend.com/issues/browse/ZF-5655</a> </p>