- This topic has 20 replies, 3 voices, and was last updated 8 months, 3 weeks ago by
.
-
Posts
-
Hi, I will try to be as detailed as possible, but being as succint as possible.
I have Newletter installed and working, along with mail SMTP and this appears to be working correctly. When I send a test email using the setup wizard for Newsletter it send fine and the “from” section appears as it should do.
But when testing the subscription widget added to a page sidebar menu the email that gets delivered has added to the “from” section “xxx@yyy.com sent on behalf of email@domain.com”. The xxx is actually the cpanel username, and the yyy is the server name (not the domain name). During testing with the setup wizard the email that comes through is “email@domain.com” with no added prefix “on behalf of”. I have tried extensively to resolve this and lots of google search, but not finding a resolution. Any ideas or tips would be most helpful.
Hello,
are you using an Smtp plugin / external service to send your emails? This could be caused by a number of reasons, so the more specific on your sending setup you can be, the better.
Thanks,
MichaelI am using the WP MAIL SMTP plugin and it appears to be configured correctly from what I can see. I am using the correct “from” email and using the same email address in all the respective places it shoudl be. then in the Newsletter plugin settings, I am using the same email.
Now if I run the Newsletter setup wizard, and send an email during the running of the wizard, the email comes through with the correct and desired email header without showing the “sent on behalf of” message. However if i add the newsletter widget to a sidebard, or activate the subscribe popup and sign up using either of thise, its only then that I get the “sent on behalf of” message.
If I sign up via a contact7 form using the same credentials, the email thatr comes through is also showing correct. It happens when signing up using the newsletter widget either from sidebar or popup. Has me a little stuck. I did contact my hosting provider and they said the email is bneing sent through php script and not smtp and this is why it is sending from the default account, but I cant see where or how to fix this since i do have smtp setup correctly as far as I can tell, since the C7 emails come through fine, and so does the email in the newsletter wizard, so it seems to be something localised to the newsletter widgets or popup widgets themselves. Is there an extended shortcode I should be putting into the widgets? Should I maybe use a text or html widget instead, if so what should I copy into those widgets as a shortcode? TIA
I am using the WP MAIL SMTP plugin and it appears to be configured correctly from what I can see. I am using the correct “from” email and using the same email address in all the respective places it should be. then in the Newsletter plugin settings, I am using the same email.
Now if I run the Newsletter setup wizard, and send an email during the running of the wizard, the email comes through with the correct and desired email header without showing the “sent on behalf of” message. However if i add the newsletter widget to a sidebar, or activate the subscribe popup and sign up using either of those, its only then that I get the “sent on behalf of” message.
If I sign up via a contact7 form using the same credentials, the email that comes through is also showing correct. It happens when signing up using the newsletter widget either from sidebar or popup. Has me a little stuck. I did contact my hosting provider and they said the email is being sent through php script and not smtp and this is why it is sending from the default account, but I cant see where or how to fix this since i do have smtp setup correctly as far as I can tell, since the C7 emails come through fine, and so does the email in the newsletter wizard, so it seems to be something localised to the newsletter widgets or popup widgets themselves. Is there an extended shortcode I should be putting into the widgets? Should I maybe use a text or html widget instead, if so what should I copy into those widgets as a shortcode? TIA
Hello @JSP,
can you please go to Help > Delivery inside Newsletter and tell me wha you see on “How are messages delivered by Newsletter to your subscribers?” section? A screenshot of the whole page would be helpful too.
Thanks,
MichaelHi Michael, thanks for getting back to me again on this. Just to re-confirm this only occurs when sending via the widget set on a sidebar. When using the test function it delivers with correct header displayed. Here is screen shot. I do also have debug stack traces for both correctly sent via test, and problematic send via widget and they are both significantly different. Good test calls plugin.php:906 (return $mailer->send($message); and send via widget calls plugin.php:954 ($r = $mailer->send($mailer_message);
See how they call different functions.
Also here is hopefully attached the screenshot requested.
Looks like no screenshot.
In how messages are delivered it shows Newsletter>>Wordpress>>Hosting Provider>>SubscriberI have been told by two devs (one that looked into the website as admin, the other a dev that was given good explanation of the problem) and both have said it is a plugin bug as it is directly related only to how the widget interacts with email sending. the test send from Newsletter plugin works fine.
Is there a possible workaround? I have tried with adding a text widget and shortcode, and also an html widget and short code but both these have same issue. It seems shortcode itself maybe?? as this is part of the Newsletter widget too? Maybe a clue there. I would like to get this fixed as the Newsletter plugin is my preferred route to Newsletters and marketing mail shots. HTH and TIA.
Hi, the widget just collects a subscriber, it cannot affect the sending of an email, it’s a core process identical for newsletters and notifications.
Belive me, I wrote the code of the delivery part.
You can use our widget, a shortcode, a custom form and nothing will change. For example, open the newsletter public page, you’ll find the subscription form. If subscribing using that form you find the same problem, that’s a confirm it’s not the form influencing the delivery.So we need to check elsewhere.
1. goto the Newsletter’s main settings, there you have a sender and a return path: what’s in them?
2. share the page where I can test the subscription with my addresses so I can see the messages and I can look at the source of those messages
3. send me a test that does not shows up the to test@thenewsletterplugin.com: from where do you run the test? From our Help/Delivery panel or from WP Mail SMTP?Thank you!
Hi stefano, thank you for your response. I will send you stack trace debug logs for emails initiated by the test tool in the plugin, and through a Newsletter widget added to the sidebar. You will notice they have significantly different stack traces and call different parts of the file plugin.php using two different sending or processing commands.
It may aksi be the case thgat my server settings could be causing an outlier case, or that it is my server at root of problem however I am just going by what a dev told me, however I am aware as mentioned it might be my server hosting that’s an issue and I have requested they look into this too to ensure my smtp is all set correctly. I will send the debug stacks to the email you have provided above.
I run the test from both the widget on a sidebar, and the test tool in the plugin. I have also sent the screenshot of details in the settings page, which show both emails for sender and return are the same.
TIA
Could be when you test from the admin some filters are/are not applied as when you send (subscribe) from the public side? Maybe your theme or a plugin is applying some filters!
It could be, but test with WP Mail SMTP test tool has same sending path, and the stack trace from the faulty send only goes through Newsletter plugin files, doesnt touch theme files from what I can see. If it is an incompatibility issue, again it is an outlier but Flatsome is by far one of the better and most well developed WP themes out there. I would be grateful if you can confirm receipt of the email i sent, and the information within it. Would you be willing to look deeper and resolve the issue with your knowledge and expertise as the author of the code? I would be most grateful since I cant think of anyone who could do a better job. Let me know by reply to the email I sent with stack trace info and screenshots as I really would like to get this resolved and use the brilliant Newsletter pro level plugin if this is fixable and working. Thanks again for your help because my hosting support seems to be rather lacking in relation to resolving this.
Since it could help others, with JSP we checked all the possibilities and the provider is changing the email headers when the site’s public side starts them and not when they’re sent (like tests) from the admin side.
This is done even by other providers, including the originating of PHP scripts and other information to identify if needed, hacked sites. That is a problem, anyway, because the antispam filter does not like too much that added information.
With email headers I mean some meta information that is not visible in the email client, you need to get the email source (for example with Gmail or Thunderbird).
Stefano you have been incredibly helpful and I am very grateful for this. I have a further question.
Is it possible that Newsletter front end signup bypasses WPMailSMTP plugin to send via SMTP?
The CF7 signup form delivers an email without issue, and this sends through WPMailSMTP.
I have been looking at the email trace stacks between the two different instances and this appears to be a notable difference. Might I need to use the Newsletter SMTP plugin to correct this, or could an update to Newsletter accomodate this difference and call WPMailSMTP if it doesnt already?
Is it possible I have something not configured correctly in Newsletter that would casue this? I have triple checked everything but as we can see, my level of ability is actually dangerous to me alone 🙂
[SOLVED]
In case this helps anyone else.By installing the “external SMTP” add-on I now have test emails coming through without the “on behalf of”, appearing as they should as originating from the designated email address.
Stefano I would just like to re-iterate my thanks for your assistance on this.
Hi, the Newsletter plugin uses WP to send email IF no delivery addons are installed. Please check if you have the Newsletter – SMTP addon active, and remove it.
Hi Stefano,
I am now confused. I added the Newsletter-SMTP add-on and it fixed the issue I was having.
I noticed underlying issue that I think is server related. I use WP-Mail-SMTP on the site and all emails sent by the site arrive to customers and users correctly with a normal and desirable header….except for wordfence which also sends with this “on behalf of” header.
By using the Newsletter-SMTP add-on I was able to get emails sent by Newsletter from the front end to arrive with the correct header. Removing this add-on will just put me back to the unwanted header.
I did test Newsletter sending without the add-on to double check, and the SMTP add-on definitively fixes the problem. Please clarify.
I have just now also bought the full version of Newsletter.
Hi, you don’t need the Newsletter SMTP addon, just keep wp mail smtp (or fluent smtp) and set it to use the SMTP service. Newsletter automatically uses that plugin.
WordFence could use a different method to send emails than the standard WP method (so the SMTP plugin would be activated), but is shouldn’t.Since you have come problems with the provider, I suggest to have a single plugin connected with the SMTP: this way all communication generated by the blog (notification, newsletters, ..) should be managed directly by the SMTP plugin.
There is even a maillogging plugin, if I remember well, so you can check what’s happening (there is no need to use the pro version of wp mail smtp).
Sorry I was perhaps not clear in my previous post. I have the full version of TNP 🙂
I am using free version of WP-Mail-SMTP.
At this moment it is all working so I am inclined to leave it as is for now.
If you recall TNP was correctly sending email from back end test sending tool differently than from front end widget which resulted in the unwanted header “on behalf of”. For some reason TNP front end email was sending through my domain default system account. It was mail from front end widget signup that came through with the unwanted header. Mail from a CF7 signup widget came through with normal header.
If I set TNP to use its own sending, or the WP sending, (ie not using the TNP SMTP add-on) it sends with the unwanted header. I did try all settings before using the addon and nothing worked. Using the TNP-SMTP add-on instantly fixed the problem.
Hi, you need to check WP Mail SMTP, probably it is sending using the standard mail() function of PHP and it is not configured to use an SMTP. WP Mail SMTP, if not configured, does nothing.
I suggest to copy the configuration you set on Newsletter – SMTP to setup WP Mail SMTP so it will use there SMTP.
Then no other problems of bad headers. 🙂
WP-Mail-SMTP is setup and working correctly and always has been for many years, no problem there. It sends mail as should be expected. I use the SMTP settings that are in wp-config.php, (which are the correct settings for my mailserver smtp).
I used the settings from WP-Mail-SMTP (ie same as from wp-config.php) to setup TNP-SMTP addon and everything working fine instantly.
For some reason TNP on my site did not send mail through SMTP from the front end widget until I added and setup TNP-SMTP addon using those same details. Now everything is fine.
For me this is good enough as it is working. I am not a web developer so cannot keep debugging something i dont fully understand. In the end the solution for my case was simple. If this is not the way it should behave, I will happily provide you admin role to look in the admin area to understand better or attempt setup the way it should be done to test if it works.
Thanks for your assistance and a great plugin.
- The topic ‘Remove “on behalf of”’ is closed to new replies.