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.

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)

I believe D19969 has now fixed this, although I'm not entirely certain, since it was never reliably reproducible in production so there's no way to really test or verify it.

D19968 got us closer here, but the link targets aren't actually rendering properly.

When the time comes, this should almost certainly also handle contact numbers for non-email media (T920 / D19988).

D19955 has how I think this likely breaks down, I'm not planning to touch it in this iteration since the badness, while bad, is mostly in a box (hopefully) until the next PHPMailer CVE. All yours!

When I was messing around with SMS sending last week, I put a rough cut of this together that is capable of sending an SMS using SNS, which has almost the same API as SES: D19982. I can tackle this unless you're already in the middle of it.

(I'm not 100% sure that D19972 fixes this completely, but it appeared to locally. In the future, "Mail Stamps" should include this information in a more reliable format, although they do not currently include transaction information. See T13069.)

PhabricatorObjectRemarkupRule->renderObjectEmbedForAnyMedia() currently calls renderObjectTagForMail() unconditionally when we're in HTML mail mode. This always renders a (F123: Xyz) element.

Performing this "attack" requires administrator privileges and probably some weird social engineering around making the "Reply All" happen.

This isn't trivial to resolve. The inverse transaction goes through standard "old value / new value" logic, so if we just move the entire "apply inverse transactions" block to later on, the transactions automatically no-op themselves: they do nothing by the time we apply them.

I made this edit:

Unsurprisingly, I think this is a race condition.

The replacement should also setTimeout(...), per T5969.

See also https://discourse.phabricator-community.org/t/suggestions-show-failed-email-in-ui-send-test-error-console-output/1844.