I'm not sure how to reproduce whatever remaining issues are described here so I don't see how to move this forward.

D19030 marks this as fixed: it removes this documentation.

I'm going to merge this into T10448, which exposes this information in an X-Header and optionally in mail bodies.

(I think everything actionable here was addressed, or survives in followups.)

I've marked D19029 as resolving this since it fixes the last one of these that I'm aware of. HTML mail has been the default for a long time now so this presumably isn't really causing problems even if there are other cases.

As it turns out, I wrote a bit of {icon ... size=72} yesterday but ran into a related issue: it's hard for us to tell if the X in {icon X} is a single character or not.

See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway.

If D19012/D19013 turn out badly this table should be <objectPHID, mailKey, firstSubjectWeSentMailWith> so there's some vague argument for waiting until those are in the wild for a little bit or naming the table in a more generic way (MailObjectMetadata instead of MailObjectKey).

Presuming this is a version issue or evil spirits or something until some contrary evidence surfaces.

Some other possibilities:

It's a real tragedy. The biggest header is definitely unacceptable for huge emoji.

Yeah, the only reason I pursued this was for giant emoji. I was just going to do {huge 🐱} or something first, but then I figured {drop-cap 🐱} was a little more defensible as a general feature while still solving the huge emoji problem.

I'd either want to pay some service to deal with this or run an open source server that I was confident it was possible to fix, but one option is definitely to run Postfix/Dovecot/Exim/whatever the kids use these days.

The "From" address should also probably be anonymized for flagged mail.

Who knows what the Bad People would have one if they'd intercepted it!

When an object is updated via an "inverse edge" change (normally: when it is mentioned, or when another object is linked to it) we currently do not fire Herald rules. The corresponding block in the code has this comment:

Hrrrm...

🎉🎉🎉 I RECEIVED AN EMAIL AND CLICKED A LINK CONTAINED INSIDE IT 🎉🎉🎉

Ah, it looks like Google Groups spam filtered some of the Twitter verification mail!

Some of this seems to be that messages sent from my @phacility.com address are sometimes eaten entirely (?) or just not delivered to me (?), presumably because I'm a recipient. I still haven't been able to get the confirmation link from Twitter, but it's possible that's on Twitter's end.

I figured some of this might be Safari vs Chrome, even though there's no obvious indication that Safari is having issues (e.g., I didn't catch any JS errors in the console).

There's an hourglass icon in the header menu. I don't know what this is for. When I click this, I get a "Loading..." menu which never loads. I reloaded the page, too. There's nothing pertinent in the console error log.