Bug #2152
closedNewsletter plugin: sent email sender listed as "CUNY Academic Commons"
0%
Description
All automated emails originating from the Tribulant Newsletter plugin list "CUNY Academic Commons" as the sender's name in the From field, even though the listed address is correctly identified as xyz@gc.cuny.edu. All of the settings within the plugin are already configured with the sender name specified as the site name or similar. I'm wondering if there is a setting somewhere in the MU interface that might be overriding?
Notes:
-test emails and administrative emails send from the correctly configured email addresses; the problem is only when emails are sent from the wordpress cron tab. this leads me to believe it might be pulling the site name from the wordpress-mu config. if this seems to be the problem I'll open a ticket on the developer's site.
-this is occurring with multiple sites using the plugin, and is tested with multiple email lists
-haven't tried changing the sending options (e.g. using an smtp server or ). is there an smtp server installed on the commons server that we could use instead of the wp-mail function?
In case it's relevant, the email header info is as follows:
Delivered-To: keith.miyake@gmail.com
Received: by 10.76.112.231 with SMTP id it7csp416588oab;
Fri, 28 Sep 2012 01:45:44 -0700 (PDT)
Received: by 10.229.69.31 with SMTP id x31mr4173147qci.101.1348821943935;
Fri, 28 Sep 2012 01:45:43 -0700 (PDT)
Return-Path: <pcp@gc.cuny.edu>
Received: from proofsender.gc.cuny.edu (proofsender.gc.cuny.edu. [146.96.128.225])
by mx.google.com with ESMTPS id u20si4806779qct.172.2012.09.28.01.45.43
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 28 Sep 2012 01:45:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of pcp@gc.cuny.edu designates 146.96.128.225 as permitted sender) client-ip=146.96.128.225;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of pcp@gc.cuny.edu designates 146.96.128.225 as permitted sender) smtp.mail=pcp@gc.cuny.edu
Received: from outmail.gc.cuny.edu ([172.29.28.89])
by proofsender.gc.cuny.edu (8.13.8/8.13.8) with ESMTP id q8S8jXNa009893
for <keith.miyake@gmail.com>; Fri, 28 Sep 2012 04:45:42 -0400
Received: from commons.gc.cuny.edu (146.96.128.200) by WA10A.gc.cuny.edu
(172.29.28.89) with Microsoft SMTP Server id 8.3.279.1; Fri, 28 Sep 2012
04:45:35 -0400
Received: by commons.gc.cuny.edu (Postfix, from userid 48) id A338C174324;
Fri, 28 Sep 2012 04:45:35 -0400 (EDT)
To: <keith.miyake@gmail.com>
Subject: [Center for Place, Culture and Politics] TONIGHT! Project Morrinho: Favela Avatars
X-PHP-Originating-Script: 500:class-phpmailer.php
Date: Fri, 28 Sep 2012 08:45:35 +0000
From: CUNY Academic Commons <pcp@gc.cuny.edu>
Message-ID: <d381b89e941bd3e84680e3a0f37871ff@commons.gc.cuny.edu>
X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/)
X-HistoryID: 5
X-SubscriberID: 651
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Importance: Normal
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_d381b89e941bd3e84680e3a0f37871ff"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000
definitions=2012-09-28_04:2012-09-27,2012-09-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 ipscore=0
suspectscore=12 phishscore=0 bulkscore=99 adultscore=0 classifier=spam
adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001
definitions=main-1209280026
Files
Related issues
Updated by Matt Gold almost 12 years ago
- Category name set to WordPress (misc)
- Status changed from New to Assigned
- Assignee set to Boone Gorges
- Target version set to 1.4.6
- Severity set to Normal
Updated by Boone Gorges almost 12 years ago
- Assignee changed from Boone Gorges to Dominic Giglio
Dom, please have a look. What's probably happening is that one of our network-activated plugins is filtering 'wp_mail_from_name'. I see that BP does this (buddypress/bp-core/bp-core-filters.php:52) and also GES (buddypress-group-email-subscription/bp-activity-subscription-digest.php:419). See if you can reproduce Keith's issue, and then try commenting out these filters and see when it goes away. Once you find it, write a small function that hooks into the filter early, and removes the problematic filter when the email is being sent by the Tribulant plugin.
Given that Keith says this is a problem only with cron, it could also be that when the pseudo-cron is firing, it. pulling up the 'smtpfromname' option from the root blog (id #1) rather than the correct blog. (See wp-mailinglist/wp-mailinglist-plugin.php:2713.) In that case I'm not totally sure what to do.
Troubleshooting WP cron is really tricky, so if the first strategy doesn't solve the problem, let me know and I can try to step in .
Updated by Dominic Giglio almost 12 years ago
Boone,
Just a few quick questions before I get into trying to reproduce this.
In the headers posted in the description, there is a line in the middle:
From: CUNY Academic Commons <pcp@gc.cuny.edu>
Could this issue be something as simple as our email server having the "From:" attribute set to "CUNY Academic Commons?"
My thinking here is this: anyone who's setup multiple email accounts in a mail client (Mail, Outlook, etc) knows that when you're adding an account it asks for Name, Email and Password before moving on to port and server DNS settings. Whatever you enter in that Name field will show up on the receiver's end in their mail client's "From:" column. Could the mail server setup in the GC be causing sent mail from pcp@gc.cuny.edu to show up as being from "CUNY Academic Commons?" Maybe in the Sendmail config, if that's what we're using. Maybe we should add Andre as a watcher to see what he thinks?
Second, how exactly do I reproduce this in a local env? Obviously I haven't even tried yet, but won't I need to be running a mail server to replicate the plugin's conditions on our server?
Updated by Matt Gold almost 12 years ago
Maybe we should add Andre as a watcher to see what he thinks?
I think I set him up as a watcher when I assigned the ticket. . . . André -- thoughts?
Updated by local admin almost 12 years ago
There's nothing on the mail server configuration presetting a "from:" header. I double-checked this by sending and email to myself directly from the server and the message correctly listed the user who sent it (in this case root
).
Updated by Boone Gorges almost 12 years ago
- Target version changed from 1.4.6 to 1.4.7
Updated by Keith Miyake almost 12 years ago
I just got a response from the developer on this issue (still not resolved, however).
Their advice was pretty much the same as Boone's—that there is likely a 3rd party plugin that is intercepting messages and overwriting the headers of mails sent through WP Mail. Buddypress codebase showed exactly this behavior happening (so that it overwrites "Wordpress" as the default sender) so that would be my first guess as to squashing this problem.
Updated by Boone Gorges almost 12 years ago
Thanks for letting us know, Keith. That's a helpful starting place.
Dom:
Second, how exactly do I reproduce this in a local env? Obviously I haven't even tried yet, but won't I need to be running a mail server to replicate the plugin's conditions on our server?
Yes. But if that's too much trouble, either use cdev, or just dump the contents of the $phpmailer object to the screen before it gets sent (wp-includes/pluggable.php, the wp_mail() function)
Updated by Dominic Giglio almost 12 years ago
- Target version changed from 1.4.7 to 1.4.8
Boone,
I've been trying to "cross test" this issue with #2117 (double group announcement notifications), I'm hoping to have some helpful/useful debugging info by the end of this week for both issues.
Updated by Dominic Giglio almost 12 years ago
- File phpmailer_dump.txt phpmailer_dump.txt added
- Target version changed from 1.4.8 to 1.4.9
Boone,
As I said above I've been trying to cross test this issue with #2117. As I began testing by dumping $phpmailer and continually commenting out instances of add_filter( 'wp_mail_from_name', '' )
I noticed I was consistently getting "double output" each time I submitted an Announcement. I thought, maybe I could kill both birds by dumping one stone. :-)
I will be updating the associated ticket with the appropriate debugging results in parallel with this one.
I started by adding:
echo var_dump( $phpmailer ) . "<br /><br />";
to line 449 of /wp-includes/pluggable.php
. This produced a dump of the $phpmailer
stdObject right above the newly added Announcement so I could visibly inspect it.
There are two elements that I focused on: the 6th ["From"]
and 7th ["FromName"]
. There are a total of 4 locations in the entire repo that utilize the wp_mail_from_name
filter. But I believe only 2 of them could be related to this issue:
Line 419 of wp-content/plugins/buddypress-group-email-subscription/bp-activity-subscription-digest.php
Line 1483 of wp-content/plugins/wpmu-new-blog-defaults/cets_blog_defaults.php
The other 2 come from BP Core and the Classipress theme, neither of which I think could be causing this name issue.
I followed your advice and started commenting out the filters one by one.
When both filters are uncommented my local env produces a ["From"]
element of "wordpress@cac.dev" and a ["FromName"]
element of "cac.dev."
When I comment out only line 419 of bp-activity-subscription-digest.php
I get the same results.
When I comment out only line 1483 of cets_blog_defaults.php
I get a ["From"]
element of "wordpress@cac.dev" and a ["FromName"]
element of "CUNY Academic Commons."
This leads me to believe that the cets_blog_defaults plugin may be overriding email sender info. I've already spent a lot of time tracing these mail calls through a bunch of plugins, so I wanted to get your feedback before I keep digging. If you think I'm on the right track, let me know.
I've also attached a txt doc of the dump info I was looking at on my screen so you can see the rest of the info that was generated.
Updated by Boone Gorges almost 12 years ago
Good find, Dom. I agree that the following lines are probably the root of the issue:
add_filter( 'wp_mail_from', 'cets_nbd_from_email' ); add_filter( 'wp_mail_from_name', 'cets_nbd_from_name' );
The inline doc says that the purpose is "the bonus options". Would you mind looking deeper to see what this function is intended to do? I want to have a sense of why it was originally put in there before disabling it altogether.
Updated by Dominic Giglio almost 12 years ago
Boone,
These email settings come from the Network Settings > New Blog Defaults admin page created by this plugin. I've attached a screenshot so you can see, it clearly states that the site name will be used when the input is left blank. Looks like the "Bonus" feature is that no other plugin gets to use it's own name when sending emails while this plugin is active!! Not much of a bonus. :-)
Updated by Boone Gorges almost 12 years ago
- Status changed from Assigned to Resolved
This is a stupid feature. Removed in https://github.com/castiron/cac/commit/c32241ffd2cfb56aaec48f69722638b2521f7b9c and https://github.com/castiron/cac/commit/13756fd5a6e2b84db8d25bd4fda2defe44d98066
Updated by Keith Miyake almost 12 years ago
I saw that 1.4.9 was released, but it seems that this bug is still persistent in emails sent as recently as 2 minutes ago.
Does it take some time before the latest release actually propogates to CAC? Or is this persistence indicative of some other problem? Perhaps a lingering database entry or cache blob?
Thanks everyone for your work troubleshooting this annoying bug!
Updated by Boone Gorges almost 12 years ago
- Status changed from Resolved to Assigned
- Target version changed from 1.4.9 to 1.4.10
I guess that we didn't correctly identify the bug. Sorry, Keith. We'll have another look.
Updated by Raymond Hoh almost 12 years ago
Looks like BuddyPress is causing this.
I'm not sure how the Tribulant Mailing List plugin is coded as I don't have access to this, but what I would try to do is hook onto the 'wp_mail'
filter and check to see if the 'From'
email header is set. If it is, we should unhook BP's 'wp_mail_from_name'
filter.
Updated by Dominic Giglio almost 12 years ago
Ray, Boone,
First, Ray, thanks for chiming in on this issue. I appreciate the help. I have verified that commenting out bp_core_email_from_name_filter()
on line 57 of bp-core-filters.php
does indeed remove "CUNY Academic Commons" from the ["FomeName"] element of the PHP Mailer object when I dump it after submitting an announcement (which is how I've been debugging this issue). That "FromName" element reverts back to the default: "WordPress." Which gets set on line 336 of pluggable.php
.
As I mentioned above, when I first started debugging this issue I added echo var_dump( $phpmailer ) . "<br /><br />";
to the wp_mail()
function right after do_action_ref_array( 'phpmailer_init', array( &$phpmailer ) );
so I could "see" the mail object as I started commenting things out one by one (no local mail server configured).
To try out your idea I decided to add a new function to the end of cac-functions.php
right after Boone's function that removed the CETS Blog Defaults filters. Here's what I started with:
/** * Some third party plugins need to set the "From Name" email header with their own name. * Don't let BP override that email header if it's already set. * * @see http://redmine.gc.cuny.edu/issues/2152 */ function cac_mail_from_name_bypass( $phpmailer ) { if ( $phpmailer->FromName ) { remove_filter( 'wp_mail_from_name', 'bp_core_email_from_name_filter' ); echo var_dump( $phpmailer ) . "<br /><br />"; } } add_action( 'phpmailer_init', 'cac_mail_from_name_bypass' );
That function dumps the $phpmailer
object to my screen when I submit a new announcement from a test group I've been using in my local env. However, the remove_filter()
does not affect the "FromName" element. It remains "CUNY Academic Commons." I'm pretty sure I know why: I'm WAY off on my "timing" - by the time phpmailer_init
fires, all the filters have been applied. What I don't know at this point is when/where to inject remove_filter()
so that it gets rid of that BP filter at the right time.
I added a second function to test out an idea and it worked:
function cac_mail_from_name_bypass2() { remove_filter( 'wp_mail_from_name', 'bp_core_email_from_name_filter' ); } add_action( 'bp_loaded', 'cac_mail_from_name_bypass2' );
Of course, this just removes that filter across the board. This would definitely fix the issue, but I don't think it's what we want. So I'm left stuck in the middle - wondering where to inject the code so it doesn't overwrite the FromName when used by the Tribulent Newsletter plugin. I feel like I'm in a chicken-and-egg situation, we don't know what will be in the $phpmailer
object until it's populated by a plugin, but by the time that occurs the BP filter has already been applied. Does that make sense? It also doesn't help matters that the Newsletter plugin is sending through cron, so removing the filter and dumping in my local env could end up working but then fail on the live site because the cron job is firing at a different point then the filters we identify. The plugin api is powerful, but really annoying sometimes! :-)
P.S. - I'm also a little confused by your advice above to "check to see if the 'From' email header is set." Won't it always be set?
Updated by Raymond Hoh almost 12 years ago
I actually just saw a forum post on the BuddyPress forums that has the same problem with BP being too greedy with Gravity Forms!
P.S. - I'm also a little confused by your advice above to "check to see if the 'From' email header is set." Won't it always be set?
I'm making a guess that Tribulant might have used the fourth parameter in wp_mail()
to add their custom 'From'
header. If they did, this will actually make things easier to code a workaround. If they didn't, then it's a little harder.
If BuddyPress used the fourth parameter in wp_mail()
, we wouldn't run into this issue. (I'll have to make a note of this, so we can fix this in BP.) But for now, is it possible for someone to send me the Tribulant plugin so I can see where we might be able to write a workaround?
Dom, the other approach we can take is to use your disable BuddyPress email filter for all sub-sites that are not the main CAC site. This will ensure that sub-sites like Keith's will work the way they want it to.
Probably try something like this:
function cac_mail_from_name_bypass() { global $blog_id; // do not remove the email filter if we're on the main BP site if ( $blog_id == BP_ROOT_BLOG ) return; remove_filter( 'wp_mail_from_name', 'bp_core_email_from_name_filter' ); } add_action( 'bp_loaded', 'cac_mail_from_name_bypass' );
Note: Untested! :)
The negatives with this approach is this doesn't fix things if we decide to use a plugin like Tribulant or Gravity Forms on the main CAC site. But, I think this will probably not happen (for now anyway!).
Updated by Dominic Giglio almost 12 years ago
Ray,
First, thanks again for the help with this. I've looked through the code you referenced both above and the in the email you sent. I kinda see why the fourth argument is important to this issue. It allows custom headers to be set when using wp_mail()
. What I'm still not putting together is why that makes it easier for us? Does it make it easier to check and correct the From:
header? Does it open up other filtering abilities? Deep inside the filters is still where I get utterly lost. :-)
I also see what you're referring to with Tribulent using the fourth argument when not using Gmail or SMTP, since the code is in the 'else' block. I looked back at the headers in this issue's description and it looks like we're using SMTP.
... smtp.mail=pcp@gc.cuny.edu ... by proofsender.gc.cuny.edu (8.13.8/8.13.8) with ESMTP id q8S8jXNa009893 ... (172.29.28.89) with Microsoft SMTP Server id 8.3.279.1; Fri, 28 Sep 2012
So it looks like we won't be able to take advantage of the fact that Tribulent is using the fourth argument?
Second, I started to try and test out the snippet you included above until I realized that I've been testing the output in a test group by submitting announcements and reviewing the headers from the $phpmailer
dump, which of course won't work because the code checks if I'm running the root blog! :-)
I'm wondering if we should just include this code in 1.4.10 to see if it "patches" this issue. We can then move this to 1.4.11 for further discussion? I don't think the above code could really break anything, but as you said, it is untested.
Boone, please let me (us) know what you think. I can throw this in at the last minute and then we can ask Keith if he's seeing a difference in his newsletters.
Updated by Boone Gorges almost 12 years ago
- Status changed from Assigned to Resolved
Boone, please let me (us) know what you think
Let's go ahead with the non-root-blog fix. https://github.com/castiron/cac/commit/dd99631aeaaeee6eddb9802a1e4dd8de9a6ad8ac
Keith, I'm going to mark this Resolved. Please report back once you've verified this fix one way or another (it'll go live tonight, so you should be able to check when your next newsletter is sent).
Updated by Keith Miyake almost 12 years ago
This issue seems to be resolved finally.
Thanks to all involved!
Updated by Matt Gold almost 12 years ago
Excellent. great work, all, and many thanks.
Updated by Dominic Giglio almost 12 years ago
Glad to hear everything's working. I just updated a forum in our project planning group to make sure everything still looks right from the root blog.
This was in the 'From' field when I received the notification email:
CUNY Academic Commons <wordpress@commons.gc.cuny.edu>
Does that look right to everyone? It does to me.
Updated by local admin almost 12 years ago
Does that look right to everyone? It does to me.
Would we want to use something like no-reply@commons.gc.cuny.edu
or no-reply@gc.cuny.edu
instead?