WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#4296 closed defect (bug) (fixed)

wp_mail removes the Content-Type

Reported by: morty Owned by: rob1n
Milestone: 2.3 Priority: high
Severity: major Version: 2.2
Component: General Keywords: has-patch
Focuses: Cc:

Description

wp_mail() removes the Content-Type. This breaks _all_ plugins not sending text-mails. Content-Type should be filtered just like the From headers.

Attachments (4)

PN_mailfix.php (2.6 KB) - added by morty 7 years ago.
Plugin which fixes the problem.…
wp_mail-rewrite.diff (6.3 KB) - added by rob1n 7 years ago.
wp-mail.fix.diff (3.3 KB) - added by rob1n 7 years ago.
4296.diff (1.2 KB) - added by Nazgul 7 years ago.

Download all attachments as: .zip

Change History (35)

morty7 years ago

Plugin which fixes the problem....

comment:1 filosofo7 years ago

You just need to use the PHPMailer API

$phpmailer->ContentType = "text/plain";

comment:2 rob1n7 years ago

Heh...

comment:3 rob1n7 years ago

  • Owner changed from anonymous to rob1n
  • Status changed from new to assigned

comment:4 rob1n7 years ago

This will fix this ticket and add filters galore.

comment:5 rob1n7 years ago

  • Keywords has-patch added

comment:6 rob1n7 years ago

  • Keywords commit added

comment:7 follow-up: mattyrob7 years ago

I'm not 100% sure how phpmailer works but some of this code may be contradictory.

We are checking for Content-Type and setting it as text/plain if it is not set.

However, I have a plugin that passes some mail via wp_mail() that sets the Content-Type as text/html. With his diff the Content-Type will be left alone but the code still invokes $phpmailer->IsHTML( false ); which presumably tells phpmailer that the email isn't html when in fact it is!

Something like this might avoid this problem (if indeed it is still a problem after the patch.

if ( !isset( $content_type ) ) {
	$content_type = 'text/plain'; 
	$phpmailer->IsHTML( false );
} elseif ( isset( $content_type) && ($content_type == 'text/plain' ) {
	$phpmailer->IsHTML( false );
} elseif ( isset( $content_type) && ($content_type == 'text/html' ) {
	$phpmailer->IsHTML( true );
}

comment:8 in reply to: ↑ 7 derjohng7 years ago

... but the code still invokes $phpmailer->IsHTML( false ); which presumably tells phpmailer that the email isn't html when in fact it is!

I have the same problem. My "DJ-Email-Publish" plugin sends the post via wp_mail().

It works not well since 2.2, because wp_mail will be sent HTML mail ($phpmailer->IsHTML( false );).

rob1n7 years ago

comment:9 rob1n7 years ago

Okay, new logic that should fix that issue.

comment:10 rob1n7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [5639]) wp_mail() rewrite that handles HTML mail. fixes #4296

comment:11 ryan7 years ago

I'm getting some reports of funkiness with mail when using the latest from the 2.2 branch.

I'm seeing weird stuff in my comment e-mails - escaped quotes and the
mime info in the msg body.

comment:12 rob1n7 years ago

Any examples?

I'll look through the code even so.

comment:13 rob1n7 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 rob1n7 years ago

  • Keywords has-patch commit removed

comment:15 ryan7 years ago

Here's an example of mime being in the body. I removed personal info from the headers.

From: xxx
Date: June 4, 2007 10:48:39 AM MDT
To: xxx
Subject: [foo.bar] Comment: "Foo is the new Bar"
Reply-To: xxx

:
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"

I asked the original reporters to drop a note on this ticket.

comment:16 technosailor7 years ago

Rob1n? ;)

comment:17 rob1n7 years ago

I've taken a look through the code, and upon visual inspection I can't find anything faulty, but I'm now going to be running specific debugs and tests.

See where that gets me.

rob1n7 years ago

comment:18 follow-up: rob1n7 years ago

Okay, I found some errors in my coding, but any extra headers I called wp_mail() with, nothing showed up in the body.

How did they call the wp_mail()?

comment:19 in reply to: ↑ 18 technosailor7 years ago

Replying to rob1n:

How did they call the wp_mail()?

I'm not sure I understand the question. Would be happy to provide more info from my end if I know what you are asking for. :)

comment:20 rob1n7 years ago

Like, what was the function call and the arguments?

I tried variations on the headers argument, but I still couldn't find the issue of headers in the body.

comment:21 technosailor7 years ago

As far as I can tell, it's every instance. For days, any notifications for moderation or new comments all have the weird headers that display into the message itself.

comment:22 rob1n7 years ago

Okay, I'm just going to yank this out of 2.2 and leave it in 2.3, where I will commence debugging. The only reason why I put this patch in 2.2 is because the reporter says it breaks HTML emails, but I guess it's plain text for now?

comment:23 rob1n7 years ago

(In [5668]) Revert [5639] for 2.2 branch, it's causing problems. see #4296

comment:24 rob1n7 years ago

  • Milestone changed from 2.2.1 to 2.3 (trunk)

Okay, bumping milestone to 2.3.

comment:25 mattyrob7 years ago

Just for information I was getting reports back from some WordPress 2.2 users of my plugin that Content-Type was being added as a header defined as text/plain and was also being added as text in the body of the email as text/html when my plugin was sending HTML emails.

If you want to see who my plugin constructs the emails see the publish (starts at line 327) and mail (starts at line 232) functions here:
http://dev.wp-plugins.org/browser/subscribe2/branches/WordPressMuand2.1/subscribe2/subscribe2.php

comment:26 mattyrob7 years ago

Further update. I think the issue with my plugin was I was using Content-type with a small 't' whereas the wp_mail looks for Content-Type with a big 'T'. on not finding it the new header is added.

The problem here is that both may be valid depending on which document you read :-( For strict coding though it should bt 'T' - so my bad.

comment:27 rob1n7 years ago

I believe those headers are case-sensitive. There was a ticket that I committed in the last month or so that changed all mentions of "Content-type" to "Content-Type" in the WP source.

comment:28 markjaquith7 years ago

Like HTTP headers, MIME headers are not case sensitive. See section 1.2.2

WP should be comparing such headers in a case-insensitive way. If we're requiring a header to have a certain type of capitalization, that's a bug!

Nazgul7 years ago

comment:29 Nazgul7 years ago

  • Keywords has-patch added

I've attached a patch which makes the relevant MIME header compares case-insensitive.

I've also made sure that that mime header is actually used, because the current code always adds a Content-Type: text/plain, whatever the input.

comment:30 markjaquith7 years ago

(In [5763]) Don't add MIME-Version header twice (PHPMailer already adds it). see #4296

comment:31 markjaquith7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [5764]) Correctly grab Content-Type from old-school headers, skip blank headers. fixes #4296

Note: See TracTickets for help on using tickets.