View Source

<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>&quot;make attachments more clever&quot; (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" />) &amp; 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>