Problem/Motivation

The system.site:mail address is a required setting since ages. Still, there is a fallback to ini_get('sendmail_from') in various places.

Steps to reproduce

Proposed resolution

  1. Remove the ini_get('sendmail_from') fallback. It doesn't have any benefit.
  2. Do not touch the PhpMail plugin. The sendmail_from ini settings is not used as a fallback there.

Remaining tasks

  • Implement
  • Write change record
  • Review
  • Commit

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3579153

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

znerol created an issue. See original summary.

znerol’s picture

Tagging as novice issue. Staying by for reviews.

znerol’s picture

Issue summary: View changes
scontzen’s picture

Assigned: Unassigned » scontzen

scontzen’s picture

Assigned: scontzen » Unassigned
Status: Active » Needs work

Removed the ini_get('sendmail_from') fallback from four files.

Did not touch PhpMail.php as stated in the issue summary.

There is one remaining mention of sendmail_from in testing_site_config.install, just a comment describing the test's intent, not a fallback.

Setting to Needs review.

scontzen’s picture

Status: Needs work » Needs review
znerol’s picture

Thanks! I'm trying to figure out whether this requires a change record.

znerol’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Added a change record. This is good to go. Thanks @scontzen

kt2026’s picture

Assigned: Unassigned » kt2026
Issue tags: -Novice +#dcd2026
StatusFileSize
new79.64 KB

I am a first time contributor who was learning around drupal contribution and issues today, i did not realised that i have a no further action on this issue

kt2026’s picture

Issue tags: -#dcd2026 +Novice
sivaji_ganesh_jojodae’s picture

+1 for the MR.

In the change request would it make sense the add the following?

Action required

Modules should not rely on the PHP `sendmail_from` ini setting as a fallback for the sender address. Instead they should ensure that the `system.site:mail` configuration value is set and use that value when sending mail.

znerol’s picture

Modules shouldn't actually set the From address at all. This is the responsibility of MailManager. And system.site:mail is a required config value. It's difficult for a site owner to unset/blank it.

longwave’s picture

Is the fallback worth keeping in the installer form? At that point I think it's possible that it's not set yet, because that's the first time that the choice is offered to the site owner?

znerol’s picture

I do not think so. Looking at the PHP docs, I have the impression that this setting is only really expected to be in use on windows (because there is no sendmail binary, PHP is forced to use SMTP).

longwave’s picture

Status: Reviewed & tested by the community » Needs work

Added a suggestion to simplify the code further, and a question too.

mehak22’s picture

I reviewed the MR and the recent suggestions from @longwave.

Removing the fallback to ini_get('sendmail_from') looks correct and aligns with the issue goal. I also verified that PhpMail was not modified, as required.

Regarding the suggestion to inline the variable: using `$this->config('system.site')->get('mail')` directly in `#default_value` makes sense and simplifies the code, so I support that change.

On the question of whether to remove the default value entirely: since `system.site:mail` is a required configuration and there are profiles that already set it, keeping it as the default value seems safer for now to avoid any unexpected issues during installation.

Overall, the approach looks good to me 👍

mehak22’s picture

StatusFileSize
new1.96 KB

Applied suggested changes:
- Removed fallback to sendmail_from ini setting
- Inlined default site mail value as suggested
- Updated outdated comment

Ready for review.

znerol’s picture

Thanks. The patch workflow is outdated. You find docs on how to update an existing merge request here.

znerol’s picture

Assigned: kt2026 » Unassigned
scontzen’s picture

Status: Needs work » Needs review

Applied the suggested change to inline the variable.

znerol’s picture

Thanks @scontzen.

I'm leaving this on needs review for a little while just in case a novice likes to review this (see the docs).

znerol’s picture

Status: Needs review » Reviewed & tested by the community

Feedback from @longwave is addressed, MR comments are resolved, this is good to go.

poker10’s picture

Status: Reviewed & tested by the community » Needs review

Re: #15 - are we sure that the default value in the SiteConfigureForm does not have any benefit for Windows users using for example Apache? If nothing else, at least as a hint? We have not dropped the whole Windows support, just support for IIS on Windows (see: #3358248: [policy, no patch] Drop support for IIS in Drupal 11). Windows with Apache/Nginx is still supported and also mentioned here: https://www.drupal.org/docs/getting-started/system-requirements/web-serv... .

The \Drupal\Core\Mail\Plugin\Mail\PhpMail plugin is also using the directive, see: https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Co... , but yes, it is for a different purpose.

I looked when this default value was added to the SiteConfigureForm or other places , to check if there was any explicit explanation, but have not found a specific mention about it in issues. Relevant commits were https://git.drupalcode.org/project/drupal/-/commit/258c653f56ce7dd7dddcb... and https://git.drupalcode.org/project/drupal/-/commit/64c1b5f1106136964cfb3... .

That said, I am not sure if we should remove it in the installer - if yes, then I think it would probably be beneficial to add some additional explanation for Windows users to the CR.

Moving to NR based on these. Thanks!

znerol’s picture

Issue tags: -Novice

Removing the novice tag. I do not see any obvious next step here which could be performed by a novice developer / reviewer.

znerol’s picture

#24 is basically the same question as #14. My answer in #15 was clearly too terse. So please allow me to try again.

It would be clearly beneficial to keep the default value in the installer if the sendmail_from ini setting contains a useful value in many cases.

On the other hand it would be clearly beneficial to remove the default value in the installer if the sendmail_from ini setting contains a bogus value in many cases.

I expect that the sendmail_from ini setting is empty for almost everybody. There is a slight chance that the sendmail_from ini is set to some value in some special environments.

One of those environments could be a windows box where somebody had to configure it for a different preexisting PHP application which relies on the PHP mail() function exclusively.

Another environment could be some hosting provider / platform which sets the sendmail_from ini value to some half way sane default value. I tried to asses whether that could be the case, but only found a vague mention in Plesk docs. I think that Drupal centric PaaS/SaaS providers tend to inject config on the application level - not the ini level.

To conclude, there is no really strong reason to keep it and there is no really strong reason to remove it. The default value is neither beneficial nor is it bogus. Neither for unix nor for windows users.

For consistency reasons, I'd still prefer to remove it. If other people think that there is a benefit to keep it, then I'm okay with that too.

znerol’s picture

Status: Needs review » Reviewed & tested by the community

I guess no answer means no objections?

dries’s picture

I reviewed this and it looks great to me. 👍

  • longwave committed 9a04a208 on main
    task: #3579153 Remove fallback to sendmail_from ini setting when sending...
longwave’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed 9a04a208991 to main. Thanks!

The CR only mentions 12.0, this is an unlikely codepath and just a cleanup so not sure it's worth backporting.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.