Opened 11 years ago
Closed 9 years ago
#28039 closed defect (bug) (fixed)
PHPMailer Header Encoding
Reported by: | jeremeylduvall | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | Keywords: | has-patch needs-refresh | |
Focuses: | Cc: |
Description
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:
<br/> Content-Type: multipart/alternative; boundary="b1_d6f7a7912dabccf69ce9130965f76239" 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 http://tools.ietf.org/html/rfc2045#section-6.4"
Public forum post: http://en.forums.wordpress.com/topic/rfc-violating-content-transfer-encoding-header?replies=7
Attachments (3)
Change History (25)
#2
@
11 years ago
Upstream bug report: https://github.com/PHPMailer/PHPMailer/issues/219
Upstream fix: https://github.com/PHPMailer/PHPMailer/commit/9bdda8c8cb926a7676974f24fe308f58146f0e3d
The Upstream fix needs more investigation because all it seems to do is just suppress this behaviour and not really specifically fix the issue.
#4
@
11 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).
#5
@
11 years ago
Introduced in PHPMailer 5.2.7 at https://github.com/PHPMailer/PHPMailer/commit/8825b159d320bcd2017585e933c805e8a3572b04
#8
in reply to:
↑ 7
@
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
@
10 years ago
I apologize, overlooked it. Thank you very much @westi, next time I'll be more patient.
#11
@
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.
#12
@
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 https://github.com/PHPMailer/PHPMailer/commit/9bdda8c8cb926a7676974f24fe308f58146f0e3d which closed upstream issue https://github.com/PHPMailer/PHPMailer/issues/219
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
@
10 years ago
- Milestone changed from 4.0 to Future Release
Concerns from a lead dev in comments above, no unit tests, therefore punting.
#15
@
10 years ago
- Put attachment:28039-test.php in your WordPress installation's
ABSPATH
. - Do
php 28039-test.php
. - Copy output to http://tools.ietf.org/tools/msglint/ and submit
- See ERRORs
- Apply attachment:28039.patch
- Do
php 28039-test.php
. - Copy output to http://tools.ietf.org/tools/msglint/ and submit
- See no ERRORs
I can work on some unit tests.
#16
@
10 years ago
I'm going to try and get this deployed to WordPress.com for some real word testing.
#18
@
10 years ago
This has been running on WordPress.com 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.)
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.
Conversely, if hardly anybody accepts them, it's a valid bug that WP should fix.