Return-Path is set blank in MimeMailFormatHelper::mimeMailHeaders

The code comment about the MTA is actually noting (correctly) that the local MTA (sendmail / postfix et al) might rewrite any value set in this code, so this value could be ignored. The code is left there because it is also true that the MTA might not do that.

I see the intent of your patch is to stop mimemail overriding the From/Sender/Return-Path headers unless their value is the default value, which is IMO a useful improvement. I would, however, think that a version that overrode whichever of those headers were actually set would be better.

I have triggered a new build, hoping that it doesn't fall over again. It would be good to take this patch forward or close it out.

I see the build passed, which is good, but I do think this patch needs more thought. While it may well be good for particular use-cases, it is important to know it is good for all use-cases.

I think the next step should be to describe what the desired behavior of the module is with respect to the Return-Path setting.

@rivimey,

I think the next step should be to describe what the desired behavior of the module is with respect to the Return-Path setting.

We're using MIME Mail in a few of our projects and I'm actually wondering why MIME Mail sets certain headers at all. I'm interested in the history of why they were included, but presumably it was to help make sure email works out of the box in earlier versions of Drupal.

I see mimeMailHeaders() can modify From, Sender and Return-Path headers. These aren't related to MIME and could potentially interfere with email generated by another module.

If these headers need to modified further downstream then the relevant sending/SMTP module would be the place to do it.

See IANA's list of Message Headers for what protocol is responsible for what headers.

In the case of Drupal, the Return-Path header shouldn't be set at all, but Drupal core does set it and has done for some time therefore most modules will try to maintain compatibility.

We actually already have a Kernel test for MimeMailFormatHelper::mimeMailHeaders(), so that test should be modified to demonstrate the problem in this issue and thereby demonstrate that the proposed solution fixes the problem. Doing this is going to be the fastest way to get any changes put into the code.

The same patch working for 8.x-1.0-alpha4.

The same patch rerolled for 2.0.1, in case anyone else needs it.

Based on the direction indicated in Drupal core on #3055296: Setting the "Return-Path" header doesn't follow RFC 5321, it seems to me that the business logic regarding the Return-Path in mimemail should be as follows:

1. If the headers already have a Return-Path, make sure that is passed along unmodified.
2. If the headers do not have a Return-Path, do not generate one.

The merge request implements this logic and adds test coverage, demonstrating that an existing Return-Path is preserved and an absent one does not result in generation of a Return-Path. This second assertion matches the exact test assertion in #3055296: Setting the "Return-Path" header doesn't follow RFC 5321