New Features & More Compatible: Email 2.1.0 2009-11-11
It's been quite a while now since the Email project has seen any new releases, but the project does not stand still. With regular request for help from developers across the globe Email has been gradually improved, sometimes with the odd bug-fix, other times with suggestions for new features. This latest release encompasses both.
I am happy to say there are no show-stoppers in the previous release, and it is safe for continued use. However, Email 2.1.0 has improved capabilities for servers on un-reliable links and systems which intentionally bottle-neck mail throughput such as Gmail. The latest version also clears up an oversight in the code spotted by a developer, Dick M, which could result in the initial period of a line not being handled properly.
Email 2.1.0 also introduces a few new methods, setFrom() and setHTML() which allow you to easily set the From: header and indicate that your message content should be treated as HTML - freeing many users from the use of complex headers and the addHeader() method.
While it has been a while between updates, I'd like to once again reassure everyone that I'm always here to help and with the project looking forward to it's 5th year of development (work was done prior to it's premier on SourceForge.net) we can reflect on the great progress Email has made. Change of direction, from a web-form solution to library; change of license, GPL to MIT; and finally change of paradigm from imperative to object-oriented. All these changes were driven by you, the end user, and I look forward to many more productive years working on this project.
To get your very own copy of Email 2.1.0 visit the download page now.
Analysis of Early End of Message Bug 2008-05-09
I decided to take another look at the previously mentioned bugs in Email 2.0.0. What follows is my conclusions, succinctly: upgrade to Email 2.0.1 to minimise the chance of becoming a source and target of unwanted junk mail.
Please Note: The issues mentioned here do not affect Email 2.0.1 or subsequent releases.
In my last update I focused on the two issues in the source one regarding premature message termination, and a second, the introduction of a preventative measure to handle poor header parsing. What troubled me about the first issue was it was in fact a regression introduced during the move from 0.9.x to 2.x which was not picked up by myself, or any review during the release candidate stage.
In my initial analysis I identified the issue as minor, but this is only
true in cases where only trusted parties have access or input into the
message content - you are unlikely to insert "\r\n.\r\n" into your message content, but you
are not trying to utilise a weakness in the system. In the interests of
full disclosure, the following details how this weakness could
potentially by exploited by a malicious user.
For instances where Email is used in environments where user generated data is injected into a template, as is typical in 'Contact Us' forms, it allows the user to manipulate the target mail server, with the web server hosting Email acting as a proxy for this attack. Consider the following code.
<?php
// Include email class and email() function
require_once('email.php');
// Create new instance of email
$email = new Email();
$email->addRecipient('webmaster@example.com');
$email->setSubject($_POST['subject']);
$email->addHeader('From', $_POST['from']);
$email->setMessage($_POST['message']);
$email->send();
?>
While this implicit trust of user data as demonstrated here is
inadvisable in most circumstances the protections built into the Email
library ensures that both the setSubject
and addHeader methods clean any parameters
to prevent malicious use. However the protections for the setMessage method, until version 2.0.1, have been
insufficient allowing the string "\r\n.\r\n"
to be inserted into the message body. For example, consider the
following malicious content for the $_POST['message']
parameter.
I was just reading your article and... . RSET MAIL FROM:<evil@example.com> RCPT TO:<target1@example.com> RCPT TO:<target2@example.com> RCPT TO:<target3@example.com> DATA TO: <lucky.target@example.com> FROM: <your.friend@example.com> SUBJECT: I thought you might like to see this great offer! Buy V14GR4 cheap N0W! http://v1agr4.example.com
This text, where lines are terminated with the string "\r\n", could even be entered into the form field
available on a vulnerable website and would result in the intended
recipient of the form receiving the innocuous message, while the three
targets would receive a junk mail message which would be traceable back
to the web server hosting Email.
Depending on the configuration of the receiving mail server this type of attack is typically limited to targets at the same domain as the intended recipient, where this is business.example.com, the potential targets are limited, however, if the intended recipient is, for example, at hotmail.com then the attacker has a much larger, and more lucrative, selection of potential targets. It must also be noted that in instances where the receiving mail server for the intended recipient is in fact an open relay the targets could then be on any domain.
To ensure your use of Email is not open to malicious use it is strongly suggested that all users of Email 2 update to Email 2.0.1 now. Please accept my apologies for the delay in releasing Email 2.0.1, if I had realised the severity of this issue I would have endeavoured to release as soon as possible.
Email 2.0.1 Released - Bug Fixes & Project Update 2008-04-28
600 downloads of Email 2.0.0 - but it's nothing to be proud of... I've been distributing buggy software. So move along now and download the greatest thing since Email 2.0.0, no, not sliced bread, Email 2.0.1.
OK, OK, I'm being a little dramatic. In all of those downloads I've not had one complaint regarding the software. Both the bugs I have identified are extremely unlikely to have any real world impact, but better safe than sorry eigh?
The first bug could potentially cut your message in half (or less), especially if you find yourself frequently putting a single period between two blank lines. This happens to be the control sequence to terminate message content and would cause the receiving server to think you have finished writing your message - unfortunately it would likely get all confuzzled by the rest of your message and simple dump the whole thing, but as you can see the likely hood of placing a single dot between two blank lines in your message is pretty slim - and is already a known issue, inducing strange behaviour on Windows, with PHP's own mail() function - who knew we had bug-level compatibility to?
The second bug is pretty much impossible to trigger. It is potentially possible to cause a header injection with Email 2.0.0! Strictly speaking headers have to be delimited with a CRLF (\r\n) pair, however poorly coded software may just look for the LF (\n) so as a precaution I now remove the control characters individually from any headers - including the subject line, Now, even if a malicious header were to be injected it wouldn't do much good. Since Email does not parse headers it's not like your Contact Us form would suddenly become a spammers paradise. Never the less, it's fixed.
Now, upfront, I've known about these two bugs for a while... between 1 and 3 months! I'm sorry, I repent. It's all because I started a new job (or three - but mainly my current one) and I've been pretty snowed under, after all who want's to code all day and all night? Oh wait...
Anyway, I'm now working at JPMH*, an integrated marketing agency based in the heart of London. JPMH is primarily a .NET shop - but they were happy enough to take on an open source crazy PHP developer to offer development expertise and keep their systems running smoothly. So if you're looking for a new marketing partner, especially digital or email marketing, look us up!
I'm sure by now you've had quite enough of my waffle, go, grab Email 2.0.1 while it's still smoking hot!
* I'm pretty sure I'm contractually obligated to point out that JPMH do not endorse or support Email in any way and is not involved in it's development.
Email 2.0.0 Final - Happy New Year 2007-12-30
Email 2.0.0 Final is ready for download, and only 9 days late!
With just shy of 250 downloads email 2.0.0, and over 150 of those downloads the latest release candidate, with no reported bugs, I think it is time to fully endorse Email 2.0.0 Final as the preferred release of email.
There are no significant changes to the code since Release Candidate 3, however I would like to note that the class name now starts with a capital letter like so: Email, as preferred by the Pear Coding Standards. As PHP uses case insensitive class names this will not affect any code currently based on any release candidate which can continue to use the all lower case name.
Email is looking forward to some new and exciting features in the next year, including native MIME mail support and multiple server fallback as suggested by William Steinford to improve delivery rate and standards compliance.
Let me thank you all for your support of email and I wish you all the best in the new year!
Email 2.0.0 Release Candidate 3 - Important Update 2007-11-21
Gustavo Lara wrote in with one of the smallest, yet most important, bug reports for the system I have ever received. Email was lacking a second carriage-return line-feed pair (crlf). For more information, please read on but I would like to stress all users of email 2.0.0 RC 1 or RC 2 should update to RC 3 as soon as possible for the security reasons outlined below.
Email was written with security in mind, trying to insulate the developer from issues introduced by users who try to manipulate the system. This is the reason I decided that email should not parse headers for CC: or BCC: information. Messages are only sent to the destination(s) specified by the developer.
The missing crlf allows plain text in the message body to be sent and parsed as headers by the receiving mail server and end user's mail client. This can cause two issues: the mail client may ignore any content in the message body until it comes across a double crlf; and/or the receiving mail server and/or end user client may attempt to process these headers with unintended side effects.
While this is a minor update, it is particularly fundamental, so again, I encourage all users of email 2.0.0 RC 1 and RC 2 to update to RC 3 as soon as possible.
To get your very own copy of email 2 visit the download page where you will find links to both version 2 and the older 0.9 revisions.
Email 2.0.0 Release Candidate 2 - Minor Fix 2007-11-17
William Steinford wrote in to let me know that the email was a little lax when it came to HELO conformity. I really do appreciate feedback especially when people have done all the hard debugging work for me! Details follow:
Email was written based on the original specification detailed in RFC 821 which only specifies how to send domains as a HELO parameter. In some instances, when a domain name is not known, email sends over an IP address instead. Turns out that the good folk at http://cbl.abuseat.org/ think that this means you're a spammer unless you encapsulate it with square brackets. Their assumption is based on the new-and-improved specification outlined in RFC 2821. So to avoid the slightly overzealous spam filtering I've updated the code to add the brackets when needed.
I've also decided that if email stands with no reported [code] issues for 1 month the current release candidate will be updated to the full 2.0.0 release. I really felt this whole 'release candidate' process was important due to the sweeping changes to the code base before I formally recommended the move from the devil we know, the 0.9 series. Please feel free to provide feedback on any aspect of the code or documentation by getting in touch so we can have the best possible code base for general release.
To get your very own copy of email 2 visit the download page where you will find links to both version 2 and the older 0.9 revisions.
Email 2.0.0 Release Candidate 1 - Out Now! 2007-11-09
Well, 2 months after my initial announcement Email 2.0.0 is available for download. Since the announcement a few minor bugs have been corrected and a couple of new methods added to the object to simplify use.
A significant factor slowing development has been my move to a new ISP, Tiscali UK. The IP addresses issued by Tiscali are listed on at least one major rejection list and ensuring mail delivery works as expected against a variety of mail providers is a much more difficult task than it has been previously.
Part of the delay can also be blamed on the new, updated documentation which covers both the new object oriented interface and the re-implemented function interface. The new documentation provides easy access to information about every aspect of email and also provides a great print style sheet to allow you to generate your very own 14 page hard copy should you so desire.
The final cause of delay is my lack of inspiration. Like many project's I wanted to celebrate the new release with a site overhaul. I have been trying to create a beautiful, functional site design for sometime now but PHP code isn't exactly the best design inspiration. For the time being I've put up this stop-gap site which will be gradually refined as needed.
To get your very own copy of email 2 visit the download page where you will find links to both version 2 and the older 0.9 revisions.
Feel free to provide feedback on any aspect of the code or documentation by getting in touch.
Status Update 2007-08-22
Friends, Romans, countrymen... no wait, that's Shakespeare. Never mind.
I'm sure a lot of people who are using this software are quite concerned about it's status, especially those of you using it in commercial or educational settings (Oh yes, some of you are silly/trusting/brave enough to use it in mission critical circumstances). The good news is: it's not dead.
Over the last year my job(s) have been quite demanding leaving me with little time to spend on the project with the bulk of my available time spent on support and bug-fix considerations - regrettably, none of which ever made it into a release. Never the less I've put in some long nights over the last few weeks and the project is back on track, full steam ahead.
Email has been largely re-written to allow me to move it to an object oriented paradigm. Of course there is, and always will be, function support for those users who just want a drop in replacement for PHP's native mail() function. This major re-write has given me the opportunity to fix many of the bugs brought to my attention and with any luck avoid creating a shed load more! While I was performing this radical open heart surgery I took the liberty of tweaking and hopefully improving some of the core functionality.
I'd like to take this opportunity to thank Mike Laurie for a great time at Mirola Ltd. and inspiring me to write version 2.0. It was fun while it lasted.
So look out over the next few weeks for the new and improved, object oriented, so-amazing-you'll-wonder-how-you-emailed-with-out-it email version 2.0. Best of all, it's free!