Security

Emails are a target for hackers. The single largest target is forms.

So many website process their user submitted forms with simple PHP code that uses PHP's Mail() function to get the data to their inbox.

I'll join all the other email transport developers in making it as clear as possible: PHP Mail() is seriously flawed and extremely difficult to work with. It's not that complex, it's just difficult. As I write this, PHP Mail() is broken. I'm not sure which version of PHP caused the problems, but it's after PHP v8.0.0.

There are a number of problems. The most obvious is that inline images will not display when created by PHP Mail() ... the exact same message will display properly when using SMTP, Sendmail and even IMAP.

Another problem is the change in how header line endings are handled by PHP Mail(). Take an email that works with SMTP, Sendmail and IMAP, transport it through PHP Mail() and it generates errors.

This is very strange ... PHP Mail() is nothing more than a wrapper for Sendmail. It's functionality is very much like your own script that would use Sendmail. Why PHP Mail() even exists today is a mystery. There are so many better solutions available.

Consider that PHP Mail() is also the source of security breaches. That may be, in part, due to the fact that PHP Mail() is the most widely used transport. The original version of PHPMailer started out back in 2001 supported PHP Mail() transport by default. Problem is that it continues to support that as a default today ... despite all the negative ranting from the developer about PHP Mail().

Two of my three email classes, PHPMailer Pro and PHPMailer Lite will not support PHP Mail(). The third, PHPMailer MIni, will support PHP Mail() with plain basic emails. That includes text and HTML messages, with single or multiple simple file or image attachments. No inline graphics, and HTML has to be in string format (will not read files containing HTML).

The scope of handling data is narrowed considerably. For example, there are no more include() or require() from inside the class. Any file access is through reading the file and processing as string data.

It's the same with file uploads passed to the class. PHP has a built-in process to handle file uploads. All are saved as temporary files to the /tmp/ folder. That's where we look for files that are not in the web directory tree of the current domain. We will not process any files outside the file storage tree of the current domain.

There's a simple process for website developers to pass file data for emailing. Read the file in advance and pass it as a string. There are alternatives for binary files that can't be passed as strings ...

Why are these changes necessary? To hackers, it's a game, a rite of passing, a way to show off, a way to delivery garbage payloads.

Everyone involved in the process, from the developers of email transport classes to the developers using them need to be more diligent at parsing the data before trying to send it in an email. Don't just pass file uploads ... verify their contents and types ... then pass the data. Don't just accept data, very it is a file, can be read, and doesn't contain exploits.

Sounds simple, but it isn't One of the more common exploits is to check file mime types by simply looking at the extension. One of the most popular email transport classes relies on this method ... yet it is so simple to change the file extension of a file designed to exploit that would trick that email transport class to delivery a garbage payload.

There are more robust ways to verify mime types. They aren't 100% fool-proof, but they are better than fooling yourself into thinking a file extension properly represents the file contents.

PHPMailer Pro, PHPMailer Lite and PHPMailer Mini use alternative methods and do not rely on file extensions.