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.

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).

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...

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.

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.

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.

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.

• 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.

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

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