RFC-violating Content-Transfer-Encoding header
The “Activate ralphcorderoy” email I just received from (email redacted) ends the headers with
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 redacted).
Foiled by lack of preview. Here’s those two headers again.
Content-Type: multipart/alternative; boundary=”b1_d6f7a7912dabccf69ce9130965f76239″
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.
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:
It might be a PHPMailer issue, see https://github.com/PHPMailer/PHPMailer/issues/219
I tagged it for staff attention.
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.