RFC-violating Content-Transfer-Encoding header
-
The “Activate ralphcorderoy” email I just received from (email visible only to moderators and staff) ends the headers with
Content-Type: multipart/alternative;
boundary="b1_d6f7a7912dabccf69ce9130965f76239"
Content-Transfer-Encoding: quoted-printable
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
I first noticed this problem with “New comment” emails from the Random ASCII blog, sent by (email visible only to moderators and staff).
-
Foiled by lack of preview. Here’s those two headers again.
Content-Type: multipart/alternative; boundary=”b1_d6f7a7912dabccf69ce9130965f76239″
Content-Transfer-Encoding: quoted-printable
-
Does this forum thread count as reporting a bug in WordPress’s eyes or is there a formal bug tracker somewhere? I’d like to see agreement that it’s wrong even if it takes a while to fix.
-
Hi there,
I’m not quite sure which part of WordPress is causing the issue, whether it’s from the code that’s custom-made for WordPress.com, or a generic code available in any installation of WordPress. In fact, I’m not quite sure where/how this issue happens.
From your mention of “New comment email”, it seems to me that you’re referring to WordPress’s email notification function. If that’s the case, it *might* be a common WordPress issue, for which you can submit bugs via the steps mentioned in the Codex:
-
-
-
Hi there,
I have brought this to the attention of our developers for further review. I’ll let you know as soon as I know more!
- The topic ‘RFC-violating Content-Transfer-Encoding header’ is closed to new replies.
WordPress.com Forums 