htmlMimeMail3 is a drop in replacement for the original htmlMimeMail. ===================================================================== PROJECT NO LONGER BEING MAINTAINED Because of non-reparable issue with sending secure emails with SMTP, this project has been dropped in favor of PHPMailer, which I recommend as a robust, well maintained project. https://github.com/PHPMailer/PHPMailer If you want to adopt this project and see if you can figure out the various issues with lack of DKIM/SPF support, and issues with SSL SMTP while retaining the small footprint of this software, give it a try, but I found that for modern emailer security, this codebase is simply inadequate. ===================================================================== NOTE TO USERS: I am going to try to maintain the API of 2.5 as is for as long as possible. Any changes or updates will simply be mapped to translator functions, for example, if I add the 5 attachment/image updates, the old methods will keep working, at least that's my plan. So ideally in the end, this class will work for both htmlMimeMail 2.5 AND 5.0 users. That is still not done. ===================================================================== CODE STATUS - PHP VERSION SUPPORT The project has been forked, and updated to work without errors on current PHP versions. Tested and debugged on: PHP Version 5.6.12-1 (development, full error reporting on, warnings, etc) PHP Version 5.3.29 NOTE: There will be NO support for very old PHP versions, this project is all about keeping all deprecated or obsolete PHP syntax out, not supporting it. This should ideally always work on the latest PHP version, within reason. IMPORTANT: this version is not fully compatible with version 5 of htmlMimeMail. See the htmlMimeMail5 documentation page for a list of the differences. See above comments for API support plans. http://www.homer.com.au/webdoc/htmlMimeMail/htmlMimeMail5.htm I may end up adding the changed 5 syntax to 3.0, but for now, the image/attachment syntax follows 2.5. This is version 5 syntax: $mail->addEmbeddedImage(new fileEmbeddedImage('background.gif', 'image/gif', new Base64Encoding())); $mail->addAttachment(new fileAttachment('example.zip', 'application/zip', new Base64Encoding())); See API.txt for the 2.5/3.0 syntax. ===================================================================== WHY FORK htmlMimeMail 2.5 AND NOT 5.0? Because htmlMimeMail5 contained some updates and improvements that were actually undesirable for our application, I decided to fork the 2.5 version from 2002, which we have been running since about 2003 without any problems, and which meets our use case perfectly. The smtp.php and RFC822.php libraries were taken from the 5.0 release and then updated, since nothing in them particularly conflicted with our needs. Note that nothing changes at all if you were using htmlMimeMail 2.5 from 2002, and only a few small things change if you are using 5.0. Because I've always really liked this class, and found it to be neat, tightly written, and overall perfect for our needs in production, I decided that it is best to fork it, and then maintain the updated version, which we run live in fairly heavy production use. The 3.0 release is intended for our purposes primarily, and with that in mind, we have no interest in anything but making sure the code is solid, clean, and bug free. The main reason I didn't use htmlMimeMail5 was that it splits all emails into text AND / OR html, using email boundaries, which creates a situation that is actually a negative for our needs. htmlMimeMail5 is also more complicated, and doesn't really do anything that we need. I may now and then pull pieces off of it and put them into 3.0 if they prove to be more reliable and do not change the functionality of the 3.0 release at all. As noted, smtp.php and RFC822.php are from the 5.0 release. Please do not ask for support, I included the original example files from the original download release, and the API.txt, my purpose in releasing this is purely to help maintain what I have always felt to be a very fine class that did its job in clean Unix way, ie, do one thing, and do it well. There are bigger classes out there, more complicated, probably orders of magnititude larger, if you want one of those, I urge you to use them. This is a simple clean class, that does what it is supposed to do. ===================================================================== BUGS FIXED: There were a few bugs in the original and version 5.0 that have not been corrected. Version 3.0 corrects the following bugs: ------------------------------------ 1: http://www.phpclasses.org/discuss/package/32/thread/4/ The _encode_header() functionremoves wanted whitespace when there are Umlauts (äöüß) in the subject line. ------------------------------------ 2: I fixed another one, where the RFC spec was incorrectly implemented: http://www.w3.org/Protocols/rfc822/3_Lexical.html _validateAtom() returned false for valid email: jones.fred <jones.fred@fred.com> because it was searching for a dot as an invalid character. ===================================================================== DEVELOPERS: Please note: I have cleaned up the indentation, and the code, so if you want to contribute, please make sure to use the proper indentation (TABS), and do NOT use oneliner flow controls, or skip brackets, etc. There's no reason to do that, and all those practices do is hide bugs and issues, and make the code hard to read, for no gain at all. Example: BAD: if ($m) execute_code(); GOOD: if ( $m ) { execute_code(); } Pull requests are welcome as long as they improve the overall code quality, get rid of deprecated features, and prepare the class for any future PHP updates. Pull requests that try to add undesirable features, or features that break our core requirements, will of course not be accepted. All patches should be tested in real production situations, not just local servers. Note: If you spot something that seems wrong and which should be cleaned up, by all means, let me know, submit a patch, a pull request, etc, but always remember, the existing functionality can never be changed without prior discussion and approval because this is used actively and heavily.