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

I'm satisfied that we aren't violating our commitment to our customers by continuing to use Mailgun as a service provider...

Purely venting, but the advanced version of "click here to schedule a mysterious meeting" is to outright lie -- pretending that you deeply respect the recipient's achievements -- before asking them to schedule a mysterious meeting.

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.