Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return path e-mail variable system/smtp/return_path_email not used anywhere? #6146

Closed
flecxie opened this issue Aug 13, 2016 · 48 comments
Closed
Assignees
Labels
bug report Component: Framework/Mail Issue: ready for confirmation Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch stale issue

Comments

@flecxie
Copy link

flecxie commented Aug 13, 2016

Trying to configure the return path e-mail as described on https://docs.nexcess.net/article/how-to-set-the-return-path-email-in-magento-2.html on Magento CE 2.1.0 but failing to do so.

I can see that both system/smtp/set_return_path and system/smtp/return_path_email are configured correctly in my core_config_data table but when I look for these variables in the source I don't seem them used anywhere. The only references I could find for return_path_email are these:

vendor/magento/module-email/Model/Template.php:    const XML_PATH_SENDING_RETURN_PATH_EMAIL = 'system/smtp/return_path_email';
vendor/magento/module-backend/etc/adminhtml/system.xml:                <field id="return_path_email" translate="label" type="text" sortOrder="80" showInDefault="1" showInWebsite="0" showInStore="0">

Const XML_PATH_SENDING_RETURN_PATH_EMAIL doesn't seem to be used anywhere either. Could someone please confirm that these settings are in fact used in Magento CE 2.1.0 & if so point me to the correct file for debugging?

Preconditions

  1. Magento CE 2.1.0 on Debian jessie

Steps to reproduce

  1. Configure return path as described on https://docs.nexcess.net/article/how-to-set-the-return-path-email-in-magento-2.html
  2. Place order

Expected result

  1. Return path being set correctly

Actual result

  1. Return path remains www-data@domainname.com
@SchumacherFM
Copy link
Member

SchumacherFM commented Aug 15, 2016

We have the same problem in 2.1.0 and some customers (e.g. those with a GMX account) don't get any emails.

Magento does not set the return path because the the configuration will be not be used because it's not implemented.

Will this fix be included in 2.1.1 ?

Edit: Work around in php.ini:

sendmail_path = "sendmail -t -i -F webmaster@example.com -f webmaster@example.com"

@SchumacherFM
Copy link
Member

This bug or missing feature has not been fixed/added in 2.1.1

@MarkB42
Copy link

MarkB42 commented Oct 5, 2016

Also having this issue and unable to get emails through.
Mage 2.1.1

@MarkB42
Copy link

MarkB42 commented Oct 6, 2016

I have spent some time looking at this and based on the following I think Magento is not setting the php mail options anymore because the return path refuses to change.

  1. Hard coded a call to $this->setReturnPath("myreturn@domain.co.uk"); in the constructor of vendor / magento / module-email / Model / Template.php

  2. Call setReturnPath() when the setReplyTo() method is called

  3. Finally thought maybe the setReturnPath() is being called somewhere and it's just being set wrong so I modified the setReturnPath() method to always set the return path to myreturn@domain.co.uk and still no changes.

Can this get bumped up the list? We literally cannot use Magento in a multi store mode as the emails are getting classified as spam, predominately by SPF.

Mage 2.1.1
Ubuntu
PHP 7.0.11

@PascalBrouwers
Copy link
Contributor

Same for 2.1.2

@paales
Copy link
Contributor

paales commented Nov 18, 2016

@victor-v-rad Can you please check this issue? :)

@PascalBrouwers
Copy link
Contributor

I see there is a function setReturnPath(). Maybe we can use that in Magento\Sales\Model\Order\Email\SenderBuilder->send() and then do $this->transportBuilder->setReturnPath() ?

@heldchen
Copy link
Contributor

heldchen commented Dec 2, 2016

ran into this issue as well today.

@ktruehl
Copy link

ktruehl commented Dec 13, 2016

The problem lies with the Zend_Mail_Transport_Sendmail class. It requires the return path as a parameter in its constructor (see https://framework.zend.com/manual/1.12/en/zend.mail.introduction.html#zend.mail.introduction.sendmail). So using the setReturnPath() method won't work.

Now the return path must be set in the constructor of \Magento\Framework\Mail\Transport. The constructor of Transport has a paramter called $parameters. One option would be to use dependency injection to inject the necessary parameter. However, that does not allow specifying a different return path for each website or store. Admittedly that is currently not possible anyway, since the system/smtp/set_return_path and system/smtp/return_path_email both have global scope. However, in a multi-website environment it is easy to conceive of a need to have different return paths per store.

So, I suggest getting the necessary settings in the constructor of \Magento\Framework\Mail\Transport and handing them to the parent constructor. The following patch does just that:
fix-setting-return-path-according-to-settings.diff.zip

@dooblem
Copy link

dooblem commented Jan 3, 2017

Same here.
To my mind this is an important issue !
Many store are sending mails that are classified as spam without knowing it...

@schmengler
Copy link
Contributor

Looks like the feature has been removed intentionally (see:

['XML_PATH_SENDING_SET_RETURN_PATH', 'Mage_Newsletter_Model_Subscriber'],
) but they missed removing the configuration field.

On a plus side, Magento 2 should be unaffected by the current exploit ZF2016-04

@tecjam
Copy link

tecjam commented Feb 1, 2017

I agree with @dooblem
I can't see any reason why it should be removed. Having www-data@yourserver as your Return-Path in your email header makes it pretty certain it will be classified as spam by the majority of email providers.
Issue still persists in 2.1.3

@heldchen
Copy link
Contributor

heldchen commented Feb 1, 2017

removing it is a bad idea. our larger shop owners have dedicated return-path and reply-to addresses that are screened by their staff - set on the store level so that return mails from the german storeview can be screened by the german team, french by the frenchs etc.

using the common base os sender email is not an option.

@bh-ref
Copy link
Contributor

bh-ref commented Feb 21, 2017

issue is still present in 2.1.4

@Noewt
Copy link

Noewt commented Apr 19, 2017

Used @ktruehl solution, but seems it stopped working in 2.1.6. It worked perfectly for all e-mails in 2.1.5
Currently all e-mails have the same Return-path which is set on server side. Magento configuration to set a specific Return-path is not working.

@ktruehl
Copy link

ktruehl commented Apr 19, 2017

Good to know, @Noewt. We haven't upgraded to 2.1.6 yet. Sounds like fun. Once we upgrade and I have to port my patch, I will post the new patch here.

@justanewbie00
Copy link

So I upgraded from 2.0.3 to magento 2.1.6, it seems that the customer is no longer receiving email. Like New Order or Registration Email.

@matin73
Copy link

matin73 commented Jun 29, 2017

same problem in 2.1.7 - any solution yet?

@Joker2099
Copy link

Bump. Did anyone find a workaround?

@Joker2099
Copy link

Anyway, I went ahead and added this line
$parameters .= "-f me@mydomain.com";
Right before:
parent::__construct($parameters);
in Magento/Framework/Mail/Transport.php

It's really dirty but does the trick for now.

@magento-engcom-team magento-engcom-team added 2.1.x bug report Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed labels Sep 11, 2017
@Krielkip Krielkip added the Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed label Dec 30, 2019
@magento-engcom-team magento-engcom-team added this to Dev in Progress in Community Backlog Mar 24, 2020
@sidolov sidolov added this to Ready for Grooming in Low Priority Backlog Sep 3, 2020
@m2-community-project m2-community-project bot moved this from Ready for Grooming to Dev In Progress in Low Priority Backlog Sep 3, 2020
@sidolov sidolov added this to Ready for Grooming in Low Priority Backlog Sep 23, 2020
@m2-community-project m2-community-project bot moved this from Ready for Grooming to Dev In Progress in Low Priority Backlog Sep 23, 2020
@sidolov sidolov added this to Ready for Grooming in Low Priority Backlog Sep 24, 2020
@m2-community-project m2-community-project bot moved this from Ready for Grooming to Dev In Progress in Low Priority Backlog Sep 24, 2020
@sidolov sidolov added this to Ready for Confirmation in Issue Confirmation and Triage Board Oct 20, 2020
@ghost ghost removed this from Dev in Progress in Community Backlog Oct 20, 2020
@ghost ghost removed this from Dev In Progress in Low Priority Backlog Oct 20, 2020
@ghost ghost added Issue: ready for confirmation and removed Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development labels Oct 20, 2020
@Krielkip
Copy link
Contributor

magento/zf1#26
This is still open for this issue. 😺

@stale
Copy link

stale bot commented Mar 3, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!

@stale stale bot added the stale issue label Mar 3, 2021
@dverkade
Copy link
Member

dverkade commented Mar 3, 2021

Ready for work and reproduced issues should not be closed automatically. Posting her to remove stale bot.

@stale stale bot closed this as completed Mar 17, 2021
@m2-community-project m2-community-project bot removed this from Ready for Confirmation in Issue Confirmation and Triage Board Mar 17, 2021
@dverkade
Copy link
Member

@magento-engcom-team don't close confirmed and ready to work tickets. This is reproduced on 2.4.X and needs to be solved.

@Joker2099
Copy link

@dverkade agreed

@schmengler
Copy link
Contributor

Looking forward to celebrate the five year anniversary of an issue that should have been a simple fix for an essential core feature because what? We're still waiting until migration from legacy ZF1 to legacy ZF2 is done?

Oh boy....

@gewaechshaus
Copy link

Der war gut @schmengler, endlich mal einer der es offen anspricht.

@Krielkip
Copy link
Contributor

And yet the MR is open for this to be fix before the migration 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Component: Framework/Mail Issue: ready for confirmation Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch stale issue
Projects
None yet
Development

No branches or pull requests