each is usually easy to replace and I'm happy to accept a change to replace it if someone wants to reproduce/test it. I believe this (totally ridiculous) construction:

From https://discourse.phabricator-community.org/t/sending-emails-causes-an-exception/4966, it appears that both class.smtp.php and class.phpmailer-lite.php have calls to each which is removed in PHP 8.

After recent changes, only DifferentialRevision and ManiphestTask still have onboard mail keys.

When users are @mentioned on an object, render their name in a disabled style if they've been muted.

This presumably worked. T12404 survives it, but that task captures everything remaining here.

Recently smtp-relay.gmail.com stopped accepting email from our Phabricator instance because it turns out Phabricator was sending HELO localhost.localdomain instead of HELO smtp-relay.gmail.com when doing the SMTP connection.

I've marked D21461 as resolving this, since the new errors surface the particulars:

I think every other AWS interaction already uses v4, since D14978 (January 2016).

I am running through GPG for the first time:

This is sort of generically concerning to me:

Aha! This user very cleverly added noreply@admin.phacility.com to their user account before they were disabled.

See D20419 and T13277.

I also vaguely think some mailer API historically rejected mail with a "Message-ID" header with an actual error ("You can't set this header, we're going to set it for you.") rather than just ignoring/replacing it (maybe SendGrid?), but I might be misremembering or that behavior may have changed. We could still always set the header and drop it in the Adapter nowadays, this whole thing is just a nest of hornets and kicking it has pretty limited upside.

I was imagining keeping the Message-ID, while having the first email also include the same value for In-Reply-To — I completely agree that removing the Message-ID would not work out. If the first email always included both fields, thus referencing itself as a reply to itself, I suppose there could be MUAs that would go into infinite loops. So, maybe too risky.

I can imagine that cases like this may exist:

The only effect I can imagine of always setting the In-Reply-To would be to encourage threading where it's not currently happening, so removing the behavior and deleting all these little methods would be very attractive to me if it were my project. :)

There's probably some argument here for removing this behavior and assuming we can never generate a "Message-ID", but I'm hesitant to make changes like that since client threading is largely unknowable black magic which we can not test, and the current approach seems to generally produce acceptable results without an overwhelming amount of collateral complexity.

A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.

FWIW I appreciate and use the mute feature (though only occasionally)