Continuing on in their look at sending MIME emails with PHP, DevShed has posted a better way for you to determine the correct MIME type of the file you're wanting to send (third part of the series).

I demonstrated how to build a modular MIME mailer class in PHP 4; it was provided with the capacity to send messages in plain text, and to work with different types of file attachments. This class implements a private method, called "getMimeTypes()," which, as its name would suggest, comes in handy for determining the correct MIME type of a given file. [...] However, the logic implemented by this method is rather primitive and can definitely be improved.

They start with a review of the previous code (PHP4) and show how to get the correct mime type of the file based on the extension mapped to an array of types.

Richard Heyes has posted about a mail() replacement he's come up with that adds the additional functionality of backing up all of the data to a certain directory of your choosing.

A simple drop in replacement function for PHPs mail() function called mailb() which backs up all the data to a specified directory. [...] I've also added a simple header file to Apache and the download directory so it looks nicer.

You can download a copy of his library here as a .phps file (a quick and easy 40ish line script).

The Zend Developer Zone has another podcast posted from its ZendCon Sessions series. This time it's Wez Furlong's talk about sending mail from PHP.

Welcome to The ZendCon Sessions. This episode of The ZendCon Sessions was recorded live at ZendCon 2007 in Burlingame, CA. We hope you enjoy today's session as we listen to Wez Furlong present "Best Practices for Sending Mail from PHP".

There's three options for listening to the show - you can either: listen to it on the page with the built in player, download the mp3 directly or subscribe to the feed to get this and future (and past!) episodes. Perfect for those who weren't able to attend the event...

As mentioned by Derick Rethans on his blog today, there's some new versions of several (five) of the components in the next version of the eZ Components framework:

In the just released alpha versions you can find new features, such as better support for OpenID, a Database backend for OpenID authentication, a validating method for e-mail addresses, SMTP authentication support for DIGEST-MD5, CRAM-MD5, NTLM and LOGIN and encoding support for e-mail headers.

He also mentions other goodies like tree structure handling and functionality to support WebDav connections. Check out their roadmap to get a better idea of what's to come.

As mentioned by the International PHP Magazine, Maksymilian Arciemowicz has posted about some testing he's been doing on the newly released PHP 5.2.4 and has still found some issues with it.

In 30 August PHP Team have released new version PHP with number 5.2.4. We have tested this version and now we can say, that not all issues from PHP 5.2.3 are patched. It is possible bypass safe_mode, open_basedir and disabled_functions.

The issue he describes is the lack of a "mail.force_extra_parameters" setting in the php.ini still making it possible to exploit the mail() function to execute arbitrary PHP code.

Paul Jones has posted a new tutorial about using the mail functionality of the Solar framework - the Solar_Mail and Solar_Stmp packages.

While each of these [PEAR Mail, PhpMailer, SwiftMailer, Zend_Mail] will work with Solar, the new Solar_Mail and Solar_Smtp packages work "natively", in that they support automatic configuration, locale and exception inheritance, and so on. Read on for some examples on how to use them.

In his example he sets up and sends a simple message, setting the contents of the email (sent as an HTML message). Since there's been much talk about the safety of a lot of the mailing systems in frameworks, Paul talks about how it's been secured from header injections, through safe attachments, and from a transport dependency-injection for SMTP.

There's even a method included that lets you take the SMTP information out of the script and put it into the Solar configuration file to use in the entire application.

In a new post on the Dotvoid.com blog today, Danne Lundqvist talks about some of the issues he's had with the mail function in PHP. Specifically, it's about the mails being set but not making it to their destinations.

Instead I have used a PHP class that allows me to send emails using a remote smtp server using an account on that server. This has been a good solution for my setup anyways. A few days ago a friend of mine was asked to investigate the very same problem for a client.

As it turns out, the solution to their problem was pretty simple - a conflict between the sendmail_from in the php.ini and the "From" passed into the mail function call. A simple ini_set resolved the issue and kept the spam filters from catching and blocking the message.

The Zend Developer Zone has posted three new helpful security tips to add to their growing list - one on mailing, one about working with privileges, and the other on the dangers of eval:

• In tip #10, Cal looks briefly at some of the dangers of blindly using form input when sending a mail. One never knows what kind of nasty headers a user might enter.
• Tip #11 recommends the "path of least privileges" when it comes to allowing access to your application. Don't go global when simple will do just fine - even with the best of intentions, the wrong access can lead to big issues.
• Finally, in tip #12, one of the more discouraged functions in PHP is discussed - eval. This one little function, when fed the wrong kind of string, can unravel your application from the inside out and provide a would-be attacker just the opening they might need.

You can check out more great security tips like these on the Zend Developer Zone website.

In his latest blog entry, Ilia Alshanetsky has proposed (and provided) a patch that can help with one of the more abused of the popular PHP functions out there - mail().

One of the problems with solving the mail() abuse is figuring out who is doing it or perhaps what script was exploited to do it, since the mail() function does not offer any logging mechanism.

To address this problem, he's supplied this patch you can apply to your source to add two new options to the mail function:

• enable the addition of the X-PHP-Originating-Script header
• mail.log (takes a filename) allows you to enable logging of every single mail() call

Check out his entry for more details on configuration options and other functionality included with the patch.

Both this post on the Zend Developer Zone and tis post on the International PHP Magazine's website point to a new article over on the IBM developerWorks website by Jack Herrington, Batch processing with PHP.

What do you do when you have a feature in your Web application that takes longer than a second or two to finish? You need some type of offline processing solution. Check out several methods for offline servicing of long-running jobs in your PHP application.

He talks about cron and its role in offline processing (including a basic primer on its format) before getting into the example itself. He looks at three examples:

• building an email queue
• building a generic queue system
• dumping out the database

Each example comes complete with code and descriptions to help you work them up on you very own system.