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

[flecxie]

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 [email protected]

[SchumacherFM]

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 [email protected] -f [email protected]"

[SchumacherFM]

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

[MarkB42]

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

[MarkB42]

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("[email protected]"); 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 [email protected] 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]

Same for 2.1.2

[paales]

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

[PascalBrouwers]

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]

ran into this issue as well today.

[ktruehl]

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]

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

[schmengler]

Looks like the feature has been removed intentionally (see:

magento2/dev/tests/static/testsuite/Magento/Test/Legacy/_files/obsolete_constants.php

Line 189 in b1e56ed

['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]

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]

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]

issue is still present in 2.1.4

[Noewt]

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]

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]

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]

same problem in 2.1.7 - any solution yet?

[Joker2099]

Bump. Did anyone find a workaround?

[Joker2099]

Anyway, I went ahead and added this line
$parameters .= "-f [email protected]";
Right before:
parent::__construct($parameters);
in Magento/Framework/Mail/Transport.php

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

[ghost]

✅ Confirmed by @Krielkip
Thank you for verifying the issue! 👍 Your confirmation will help us to acknowledge and process this report.

[Krielkip]

😱 something with fix commit and close ticket..

[Krielkip]

Can be closed if this is merged: magento/zf1#26

[m2-assistant]

Hi @Krielkip. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[Krielkip]

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

[stale]

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!

[dverkade]

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

[dverkade]

@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]

@dverkade agreed

[schmengler]

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]

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

[Krielkip]

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