Fixed bug where transport object is reused across stores containing wrong authentication info

[ryanpalmerweb]

There is a bug in the current version of the mail relay module, where if mail is queued for multiple store views, the transport object is created in the first store view and then re-used in the next store view.

This causes intermittent issues for one of our clients where mail would sometimes go out through the wrong mail relay account, causing it to fail DMARC authentication on the DKIM key which is set per account.

This would be triggered both in core Magento, for example in the order emails, and also in any modules which iterate through the store views using store view emulation.

Description (*)

The function getTransport($storeId) implies that the transport object will be fetched for that store ID, however the implementation in the function is that the transport object is saved and re-used for next time.

public function getTransport($storeId) { if ($this->_transport === null) {

This has been replaced so that it fetches the specific transport object relating to the store view, with any other instances of the transport variable in the class also being made store view specific.

public function getTransport($storeId) { if (!isset($this->_transport[$storeId])) {

Questions or comments

To replicate the original bug :

1. Set up a service such as Mailgun with each store view configured to use a different account

2. Turn off the Magento cron, and make sure email is asynchronous

3. Place orders from 2 different store views

4. Now re-enable the Magento cron.

5. Both emails would have likely gone through the mail relay associated with the first store view.

6. This bug was apparant when using Mailgun across multiple store views

[vpodorozh]

Faced the same bug and came up with the same solution and created PR :)
just closed it as duplicated: #406