Make WordPress Core

Opened 10 years ago

Closed 8 years ago

#28039 closed defect (bug) (fixed)

PHPMailer Header Encoding

Reported by: jeremeylduvall's profile jeremeylduvall Owned by: wonderboymusic's profile wonderboymusic
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.9
Component: Mail Keywords: has-patch needs-refresh
Focuses: Cc:


A support ticket I came across raised some issues with the header encoding (“RFC-violating Content-Transfer-Encoding header”). User states that our header ends with:

Content-Type: multipart/alternative;
Content-Transfer-Encoding: quoted-printable<br/>

And quotes:

"The RFCs state that the only allowable C-T-Es for multipart/alternative are 7bit, 8bit, and binary; Q-P is invalid. This causes my MUA to refuse to display the email. See"

Public forum post:

Attachments (3)

28039.patch (1.8 KB) - added by rzen 10 years ago.
28039-test.php (751 bytes) - added by mdawaffe 10 years ago.
php 28039-test.php
28039.2.diff (2.9 KB) - added by mdawaffe 10 years ago. + UTs

Download all attachments as: .zip

Change History (25)

#1 @Denis-de-Bernardy
10 years ago

  • Keywords reporter-feedback added

Fwiw, email-related RFCs are very much like HTML: where standards-compliant HTML in euphemism for whatever tag soup the most common browsers will accept to render, standards-compliant email is euphemism for whatever stream of garbage common email servers and clients will accept to route and render.

In practice, there's a gazillion means to validate an email address — all of them incorrect, btw — and another gazillion means to validate an email message's format and what not. The entire thing is plagued with string encoding bugs and software bugs and what not from one end the other. What ultimately counts for emails is if its recipient will ultimately manage to read it, valid email address and format be damned.

I wanted to stress the above points because if e.g. gmail, hotmail, yahoo, Outlook, OSX Mail, etc. all render the same WP email correctly, then we also need to be pragmatic. For much the same reason that StackOverflow recently fixed its standards-compliant url encoding, if everyone else accepts WP email formats then methinks this bug should probably be reported upstream to the email client that does not — or to PHPMailer, for that matter.

Conversely, if hardly anybody accepts them, it's a valid bug that WP should fix.

Version 3, edited 10 years ago by Denis-de-Bernardy (previous) (next) (diff)

#2 @westi
10 years ago

Upstream bug report:
Upstream fix:

The Upstream fix needs more investigation because all it seems to do is just suppress this behaviour and not really specifically fix the issue.

#3 @westi
10 years ago

  • Keywords needs-patch needs-unit-tests added; reporter-feedback removed

#4 @mdawaffe
10 years ago

Note that the issue here is the Content-Transfer-Encoding header of the top-level message (the thing with the multipart Content-Type).

The issue is not the Content-Transfer-Encoding header of the individual entities (the parts of the multipart message).

#6 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.9.2

#7 follow-up: @michalzuber
10 years ago

Should be fixed via [27385]

#8 in reply to: ↑ 7 @westi
10 years ago

Replying to michalzuber:

Should be fixed via [27385]

How, this is the commit that introduced 5.2.7 to WP core which is the phpMailer version with the bug.

#9 @michalzuber
10 years ago

I apologize, overlooked it. Thank you very much @westi, next time I'll be more patient.

#11 @helen
10 years ago

  • Milestone changed from 3.9.2 to 4.0

We punted on #28909, but this was milestoned for 3.9.2, so moving to 4.0 for the time being so we don't lose track.

10 years ago

#12 @rzen
10 years ago

  • Keywords has-patch added; needs-patch removed

Assuming the people behind PHPMailer ran their due-diligence (and I introduced no typos), 28039.patch should solve this issue. This uses the exact same upstream fix applied in which closed upstream issue

This is a good stepping stone until we can move forward with #28909.

Hello from WCGR 2014 :)

This ticket was mentioned in IRC in #wordpress-dev by rzen. View the logs.

10 years ago

#14 @helen
10 years ago

  • Milestone changed from 4.0 to Future Release

Concerns from a lead dev in comments above, no unit tests, therefore punting.

10 years ago

php 28039-test.php

#15 @mdawaffe
10 years ago

  1. Put attachment:28039-test.php in your WordPress installation's ABSPATH.
  2. Do php 28039-test.php.
  3. Copy output to and submit
  4. See ERRORs
  5. Apply attachment:28039.patch
  6. Do php 28039-test.php.
  7. Copy output to and submit
  8. See no ERRORs

I can work on some unit tests.

#16 @mdawaffe
10 years ago


I'm going to try and get this deployed to for some real word testing.

#17 @johnbillion
10 years ago

  • Version changed from trunk to 3.9

#18 @mdawaffe
9 years ago

This has been running on for 6 months. I know of no problems. It fixed some encoding issues involving non-ascii characters for us. (Our use of PHPMailer differs a little from that of core's, so core probably doesn't suffer from the same non-ascii character encoding issues we used to.)

#19 @mdawaffe
9 years ago

  • Keywords needs-unit-tests removed

#20 @wonderboymusic
9 years ago

  • Milestone changed from Future Release to 4.4

#21 @DrewAPicture
8 years ago

  • Keywords needs-refresh added

28039.2.diff needs a refresh.

#22 @wonderboymusic
8 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 35617:

Mail: after [33124], add unit tests.

Props mdawaffe.
Fixes #28039.

Note: See TracTickets for help on using tickets.