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

[WordPress Trac]

#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 dmsnell):

 > The problem is that the bureaucrats of these Core sections, have the
 power to hinder these proposals, but they can't hinder other areas like AI
 because those guys have much more power in this project than them, so they
 have to bow their heads and accept the new changes with unease. It's like
 a game of thrones. ;)

 > there's a new group of 19-year-olds in charge who think that everything
 learned before 2025 could not possibly still have relevance…undo these
 asinine decisions

 let’s perhaps take a moment to breathe and recognize that behind every
 username here is a human trying to find ways to improve WordPress. let’s
 also take a moment to realize that, despite the confidence and fervor of
 the proponents of this ticket, //following that confidence// led to
 breakages across different platforms.

 so I don’t know which asinine decisions we’re referring to, but when the
 failures started, a number of us tried to assess the impact and whether
 fixes or reverts would be more appropriate. when we asked, we were unable
 to find people who were willing or able to provide empirical data showing
 the scope of the breakages, and there was already a workaround for the
 sender address issue.

 therefore we reverted. some of the requested fixes were also incomplete
 and would have led to the same kind of breakage if deployed.

 personally, I went out of my way to try and help the efforts pushed here,
 seeing that there was no Core committer championing the work. every week I
 have a thousand different projects, groups of people, and tasks that I
 can’t hope to adequately attend to, but I chose to try and move this one
 forward where I could. I spent that precious time reviewing this work,
 getting second-opinions from people with more experience in email
 delivery, writing a Make post and putting my name on it //to draw public
 flak and reaction to me and not onto others//, and accepting the liability
 for any problems that happened post merge — and guess what, there was a
 huge liability post merge.

 there was a time I was 19, but it’s not now. email systems behave
 differently since the last time this fundamental change was attempted, so
 we gave it another try, and you know what? it //mostly// worked! to the
 best of our collected knowledge, this affected a very specific subset of
 the deployed WordPress ecosystem. we never found the data we were asking
 for though — only received a declaration that because the problem appeared
 “more than 0%” //by a few reported systems//, despite fixing other
 systems, that things were “unambiguous.”

 the decision to revert also broke email delivery for those for whom the
 original patch fixed it.

 if you feel like people like me, and those who took part in helping to try
 and make this thing work, are obstacles with the goal of hindering your
 plans…I don’t know, consider what would have happened if this had gone
 smoothly? would I still be an asinine 19-year-old bureaucrat if email
 //only// got better with this merge rather than //got better more many and
 worse for some//? throwing insults isn’t likely going to help whatever
 your own agendas are or gather cooperation in the community.

 ----

 we should be clear here: AI had nothing to do with hindering this
 proposal. the only thing //hindering// this proposal is the impact that
 the proposed fixes had when they broke real systems for real people. and
 because of that, now, any attempt to redo the change is obviously going to
 be much slower a more effort is being put in place to ensure due-diligence
 before unnecessarily and negatively impacting people again.

 there are open tickets for different parts of the broader issue at play
 here surrounding the sender address. I understand that it can be
 frustrating when things move slower than one wants when a solution seems
 so simple from a given perspective.

 for my part I regret merging this late in the release cycle. I wish I had
 outright said “no” when considering the merge before 6.9, but I wanted to
 help what appeared to be effortful work that was stuck. I have learned my
 lesson and have tried to more carefully push caution in unrelated work so
 that it lands at the start of a release cycle instead of the end. I hope
 that because of that I don’t convince someone else to call me an asinine
 19 year old bureaucrat 🙃

 ----

 > All of these problems boil down to one thing: the lack of a text box to
 type in a usable address in a manner that is consistent with the design of
 WP, the internet, and hosting environments.

 This sounds like a good thing to add in a plugin as
 [https://core.trac.wordpress.org/ticket/60420#comment:16 @desrosj]
 suggested eight months ago. It’s far easier to discuss something that
 exists and is in use than a confusing back-and-forth of hypotheticals.
 Hosts can install the plugin and test it and provide feedback. Anyone with
 email troubles can install it.

 As has been brought up by others in this ticket, even adding the text box
 presents coordination problems when hosts and site admins have different
 understandings of what //should// be set as the sender address.

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