[wp-trac] [WordPress Trac] #60420: Default wordpress at site.com sender address can be problematic

Wed Aug 6 22:04:02 UTC 2025

#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by desrosj):

 Replying to [comment:18 SirLouen]:
 > The idea was the following:
 >
 > - I was planning to leave this report closed, mainly because the idea
 was to do a new summary with all the information retrieved and create a
 new clean report focusing on this specific target, building the Health
 Check.

 Whenever possible, it's best to continue using the same ticket. This
 ensures that past participants and watchers on the original ticket
 continue to receive notifications for new activity.

 > - This was already in process, I already sent the
 [https://github.com/WordPress/Advanced-administration-handbook/issues/406
 report upstream] to Hosting and [https://github.com/WordPress/Advanced-
 administration-handbook/pull/407 the corresponding PR] to activate this.
 After this, I might be probably improving a bit the docs to make this
 clearer.

 Thanks for following up on this outside of this ticket! Please make sure
 to cross-reference any related actions that are taken outside of a ticket
 in the future, especially ones outside of this Trac or `wordpress-
 develop`. It helps contributors follow all of the work that was performed
 as a result of a ticket's discussions.

 I dug a bit deeper into the history of the `From:` address before [3214]
 and traced the addition of `From: <admin_email>` to [2415]. Prior to that,
 there was no `From:` email defined at all. The
 [http://mosquito.wordpress.org/view.php?id=980issue tracker used then was
 mosquito, but it's unfortunately no longer accessible]. So any discussion
 around why can't be followed.

 I next looked through
 [https://core.trac.wordpress.org/query?component=Mail&summary=~From&order=id
 all tickets mentioning] `From` in the summary within the Mail component.
 Here are a few that were notable.

 #14586: This one removed the `wordpressmu_wp_mail_from()` function, which
 hooked to the `wp_mail_from` filter and returned the `admin_email` when
 the email being used did not contain `wordpress@` (see [15678]). The
 ticket notes that using the `admin_email` can "have delivery problems
 (which is why we do wordpress at server)" and exposes the admin email
 address, which implies that the `admin_email` is meant to be kept private.

 Next up is #25239. This one is quite long and got off track, but there are
 some comments that are very relevant to this discussion related to why
 `admin_email` is not used as the `From:` address:
 - "system generated messages (like password resets or notifications)
 aren't really from the blog author, but from the backend"
 (ticket:25239#comment:67)
 - "emails like password resets that shouldn't come from the admin,
 actually touches back on why this is considered a security issue. Admins
 shouldn't get the bounced email with the link to password reset."
 (ticket:25239#comment:69)
 - "some servers block emails sent FROM anyone but the domain WP is
 installed on. So your personal email of foobardancingfox at gmail.com
 wouldn't get the messages :( Oh and lets not think about the spoofing of
 emailing from gmail while actually not being from gmail. Fast track to
 being blacklisted :(" (also ticket:25239#comment:69)
 - "since it isn't human, then presumably the idea is that it's effectively
 a "noreply@" address? i.e. An address that isn't really intended to get
 replies" (ticket:25239#comment:70)

 After that, the ticket was refocused on the original intent, which was to
 address potential insecure scenarios with `$_SERVER['SERVER_NAME']`.

 Honorable mention is #17001: Mentions that "Many ISPs block a from address
 that is off domain."

 The last ticket I found that had points relevant to the discussion was
 #23365. This ticket proposed the addition of a new option for configuring
 the `From:` email. From ticket:23365#comment:4:
 > The main issue with providing a UI option for this, is it requires
 configuration beyond the option. Something still needs to be done, outside
 of WordPress, in order to make it work. The user still needs to do some
 outside configuration they probably don't understand (see the next
 paragraph for a fairly onerous and confusing process some must go
 through). That's not very good when you offer an arbitrary input. If any
 email worked, we would have been using admin_email all this time.
 >
 > I think something more effective would be to encourage hosts to set up a
 default email address of wordpress at domain.com in their own systems
 whenever a user installs WordPress, to allow the local SMTP server to send
 it. Even if MX records to not go to the host, some hosts do whitelist
 outgoing mail based on their own systems.

 I had not seen this prior to my comment above, but I strongly align with
 this and it better captures what I was recommending in my third suggested
 action item. While it's good to surface the documentation that you noticed
 had been written but not presented in the handbook @SirLouen, I think that
 it does not accomplish the third point. It does a
 [https://github.com/WordPress/Advanced-administration-
 handbook/blob/main/server/mail.md#ensuring-deliverability great job of
 outlining the technical reasons why] certain `From` values may be
 problematic and how to fix them, but this is still a handbook aimed at
 advanced administrators. The majority of WordPress users (who are non-
 technical) would have no idea what to do after reading this.

 My vision is something more like what was recommended by @nacin where
 hosting companies just handle this for the user and they can change it if
 they'd like. As an employee at a hosting company, I am going to do some
 research here to see if this has been attempted before and raise it as a
 discussion with the broader hosting team.

 Next, I also took a look at how the `admin_email` field is presented tot
 he user.
 - General Settings: The field is labelled "Administration Email Address"
 and the description is "This address is used for admin purposes. If you
 change this, an email will be sent to your new address to confirm it. The
 new address will not become active until confirmed."
 - Network Settings page: The field is labelled "Network Admin Email" and
 the description is the same as on the General Settings page.
 - Installation Page: The field on this page is labelled "Your Email" and
 the only description is "Double-check your email address before
 continuing."

 If the email was meant to be surfaced and used within email communication
 from the site, I think that the context provided to the user would be much
 more descriptive. Especially on the installation page where it reads as if
 you are entering an email for your own user account on the site.

 With all this in mind, I think that it's safe to answer your question
 @michaelorlitzky: The `admin_email` is only intended to be a "to" address
 (option 3).

 > using the site admin address as the "From" address are using it wrong.

 I also agree with this, though I can't speak for how each individual
 plugin explains this to the site owner. It's possible that some do
 adequately explain the reasoning and consequences of using that field as
 the `From:` sender instead of the default so that the user can make a
 truly informed choice. I'd be curious how they are working around the
 other related factors described above that will potentially result in the
 emails being flagged as suspicious. But that's a discussion for a
 different day.

 I've also reconsidered whether a canonical plugin would be useful in this
 situation and I've decided that I don't think it would be appropriate
 here. Even if the `From` email is changed through the use of a filter,
 that alone would not be enough. "Something still needs to be done, outside
 of WordPress, in order to make it work," as stated above. This would just
 result in a confusing scenario for the user.
 - Activate canonical plugin
 - Change `From` email
 - Experience varying levels of email reliability depending on the email
 that's used, the policies associated with that email service and/or the
 ISP. This also won't be immediately obvious, if it's ever noticed at all.

 This leaves #62129 for implementing a check and educating the user about
 possible issues related to the default choice in Site Health, the pull
 request that @SirLouen created, and the outreach I described above with
 the hosting team. I'm going to mark this as `close` to allow time for any
 additional thoughts in response to this. I think that this is actually a
 duplicate of #23365. Even though that ticket explicitly asks for a new
 option for the `From` address, this ticket is essentially asking for the
 same thing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60420#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform