Proposal: Use Full PHPMailer library

[Ipstenu]

Currently we're using a customized version of phpMailer that strips out some features. This is most evident when you compare class.smtp.php:

Ours: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-smtp.php#L465

Official: ​https://github.com/PHPMailer/PHPMailer/blob/v5.2.21/class.smtp.php#L465-L527

We're missing sections which plugin developers are using to support extended features (oauth, ntlm, etc). By leaving this out, we introduce a reason for them to include versions of PHPMailer which they then have to update in the case of security issues (such as the sort that predicated the 4.7.1 core release).

If we were to include the full library, it would be easier (and faster) for core to update in case of security issues, and it would provide more flexibility and security for plugins and (by extension) users of WordPress.

[lukecavanagh]

@Ipstenu

Seems like it is worth doing, with the number of SMTP or related plugins which did include their own version of PHPMailer.

[Ipstenu]

The majority of plugins included their own copy in order to include it period. It was merely an educational issue that caused that situation. The point of this ticket is that those who have a legit reason for the un-forked version of the library should not be excluded and put more at risk :)

[dd32]

I'm +1 for this. Merging a pristine copy of PHPMailer and not having to remove features for security updates is beneficial for all.

I can see arguments for keeping our current "slimmed down" version, as 99.99% of sites never use some of the functions we currently ship with (SMTP for example, or the SMTP authentication methods), but the fact it's not an official upstream version we can copy-paste irks me, and isn't good for security/file modification scanners.

[Otto42]

Seems like a good idea. We should investigate why these additional pieces were originally removed and figure out if that makes sense in the current circumstances.

If we can include upstream libraries unchanged, then we should. If we need to push things upstream to make that easier or better for all involved, then bonus points.

[JeffMatson]

I dropped in PHPMailer and things seem to be fine so far. Obviously, it would need a lot more testing. Diff attached.

At the moment, I left in the existing classes for backwards compatibility for anyone who might be calling them directly.

[JeffMatson]

PHPMailer drop-in

[JeffMatson]

Diff including new files.

[Ipstenu]

Update PHPMailer to 5.2.2, no longer fork library

[Ipstenu]

I think the drop-in fix would be better. The second patch has _everything_ and we don't need all that :) Yet.

I simply updated the two files to the full version of the phpMailer source for 5.2.22 (the current stable)

[MattyRob]

The reason these blocks of code are removed is because we don't include the necessary 'extras' used by PHPMailer to make these work.

For example the NTLM code block contains the following line:
require_once 'extras/ntlm_sasl_client.php';

This library file is not bundled with WordPress so this would result in an ugly looking failure.

In a similar way, the 'XOAUTH2' authentication method calls the $OAuth->getOauth64() function and as the class.phpmaileroauthgoogle.php library is also not included, this would fail.

To include these methods would require bundling these extra files from the PHPMailer package.

[desrosj]

It's been quite a bit of time. This one definitely will need a refresh and reevaluation with today's code base.