recreate bug:
go to admin/updates/settings
delete any email address from the textarea titled
"Email addresses to notify when updates are available"
then save

problem :
without any email address in this text field it appears
the update email sends to "noreply@domain.com"

This causes failure and a bounce. see image attached...

why is this a problem?
email smtp providers dont like bounces. it can cause
probation and loss of service at Amazon SES

How to fix?
put a valid email in the field as a default. Perhaps
dummymail@drupal.org or something like that. Better
yet, fix the code so it sends to dummymail@drupal.org
when there is no email in the textarea box titled
"Email addresses to notify when updates are available"
as mentioned above

i did some research, it appears the string "noreply" is being stored
somewhere in the "config_snapshot" table on mysql.

Why is this a problem?
Administrators may have several or even dozens of
drupal dev sites, and do not need the email update reminders
but without an email, it appears Drupal Core (I think its the update module,
but I am not sure) just sends an invalid email to "noreply@domain.com. This
is, in turn, rejected by valid email server "mx.domain.com"

no doubt they would appreciate the fix too.

an even better option would be a checkbox that lets the admin suppress
any update emails being sent.
thanks for all the great work,
James

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jamesd567 created an issue. See original summary.

starlightE’s picture

FileSize
96.75 KB
96.14 KB
40.58 KB
79.16 KB
67.25 KB
59.18 KB
86.32 KB
150.32 KB
127.8 KB

I have some further research:

i found in admin/content/comments, a variety of test comments in the corporate+ theme
that I recently acquired from morethanjustthemes

the earliest comments all show [mail] -> x-default = NULL (blank)
but a coment on 1-27-17 shows "noreply@domain.com" (see pic 5)
Did drupal 8 start shipping on 1-27-17 with noreply@domain.com as a default value?

here is the bug report update
to recreate

put some comments in on an article node using the admin account (drupal 8.4.3 or 8.4.4)
install the devel module
go to admin/content/comments and edit the first comment (most recent) -- see pic1.png
click "devel" - see pic2.png
click "load" - see pic3.png
click variable - see pic4.png
scroll down till you reach "[mail] => array --- you will see "noreply@domain.com" - see pic5.png
see config/basic site settings -- pic6.png

EXPECTED
email address in pic6.png should be what is found in pic5.png (not noreply...)

go to reports/available updates/settings - pic7.png - you will see my email address is not the same as pic5.png

EXPECTED
email address in pic7.png should be ??? same as pic5 ?? not sure about this

also
see pic8.png showing bounced email due to sending to "noreply@domain.com" - pic8.png

also
see pic9.png - i dumped the database with mysqldump and did grep for "noreply" and found this - pic9.png
notice that only the last record has noreply -- i think its most recent although i did not check each timestamp

CONCLUSION
Maybe my theme somehow was using noreply@domain.com at some point for the basic site setting? not sure
Maybe the notification report of new updates in 8.4.4 and 8.4.3 is picking up an email address field for admin
in the comment_field_data table instead of whereever it should be, since that record would be timestamped
before i entered my email addresses.... Not sure.

At any rate, something is wrong. emails should be going to the site email setup in config/basic site settings and it is not
doing this. My only solution so far is to turn off the mail server on my dev machine.

Thanks for all the help. Hope you can solve this soon. Its causing bounces and hassles with Amazon SES service
which a lot of people, including myself, rely on..

regards,
James

cilefen’s picture

Hi James:

The string noreply@domain.com does not exist in Drupal 8 core and never did—I checked. The site address and the update notification addresses may be different. Are you arguing they should be identical? Also it seems that you are suggesting that an email address on a comment became the site update notification address—is my understanding of that point accurate?

P.S. It is not convenient looking through lots of screenshots and blocks of unpunctuated text. It helps to review https://www.drupal.org/issue-queue/how-to now and again. You may not get many responses to this issue because it is difficult to read and to understand.

starlightE’s picture

Thanks,
Site address and update notice addresses should be different if users want,
so def agree on that...

i will try to better condense future bugs. Glad to hear noreply@domain.com never in core!

Based on what you have said, at some point the admin account of
the package I installed must have had noreply@domain.com set as the admin's email address.
(pic9 shows its in the DB...)

then, a comment was made on a node by admin, and that invalid email address was stored in the DB,

then, after I changed the admin email address to a valid email address, the old
email address (noreply@domain.com) was being used by Core to send emails about updates (pic8)
since it was already in the comment_field_data table (PIC9.png) before my update...

I will test it some more and report back...i have a better idea now how to test it that should clarify
further.
regards,
James

Version: 8.4.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Status: Active » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging issues that are marked “Needs steps to reproduce“.

Since there were no specific steps provided since the issue was tagged with “Needs steps to reproduce“, I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".

Thanks!