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've been wanting to make a "giant emoji" task since emoji were added but was too afraid...

In T5726#88706, @epriestley wrote:

One concern about this is that this information is policy-bypassing.

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.

If all you're going for are emails, why not spin up your own Exchange server (or whatever the kids use these days)? With maybe forwarding to a epriestley-phacility@gmail.com so you remain compliant?

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:

In T13053#235208, @epriestley wrote:

Hrrrm...

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.

We received our first credit card dispute on January 31st.

See some additional discussion in T13060 and T7339. Pretty much everything here remains unchanged, but those tasks discover an additional constrain: a parent process has LANG=POSIX (or similar, some non-UTF8 locale), it can not pass UTF8 to subprocesses in argument lists.

See T13060 and T7339 for followups and additional discussion.

D18988 addresses the issue from D18105 (git grep 🐑 fails) more directly by calling @setlocale(LC_ALL, 'en_US.UTF-8') unconditionally during startup. The motivating case in T13060 is:

(Future me, see also PHI343.)

The above workaround is not reliable since it skips the files entirely vs checking the remaining characters.

I think I didn't kick Apache hard enough since I eventually rammed this through with setlocale().

setlocale(...) doesn't (?) appear to work from within Apache (?).

Thankfully, it seems that setlocale(LC_ALL, 'en_US.UTF-8'); from within PHP does work, so we don't need to figure out what PAM initialization cache file Ubuntu is actually reading LANG settings from.

sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 also does not work, although this is apparently just a Perl script that rewrites /etc/default/locale for you.

Setting LANG in /etc/environment had no effect on anything.

I now strongly believe this is some kind of terminal environment problem. This script has different behavior in production and on my laptop:

No luck, I don't even see any bugs in Differential locally with that change (the en-dash decodes and renders properly). So this might be in the realm of T7339.

Same result.

Same results for spaces.

To try to reproduce this, I did this:

Vaguely related, the subject line for this mail is currently something like:

🐱 🐟

We have also found legitimate users who have valid email addresses (Irish users) that are not accepted.

For those visiting from the future via search, I have decided to publish an unofficial bug patch in a github repo, as it breaks once in awhile due to upstream changes.

For those visiting from the future via search, I have decided to publish the unofficial patch in a github repo, as it breaks once in awhile due to upstream changes.

Thanks @mcorteel, I'll take a look.

contains complex HTML elements (like inline comments) which would also need to be stored in a structured way and then rendered just-in-time

While it's on my mind -- these messages link to /mail/whatever/123/ right now, but that page doesn't hyperlink links in the mail body, which is a fairly significant usability issue since the workflow is: click the link to go to the mail, read the mail body, copy paste the link in the mail body into your address bar.

This report doesn't include working reproduction instructions so we can't move forward.

I can't reproduce this; it may have been fixed by D18776 + D18778.

My call with Mailgun was generally reassuring. Based on an uncharitable reading of the January 5th disclosure, my major concern was that they might be starting from a cultural position which was blind to internal actors as threats and everyone just used root / hunter2 written on a sticky note to log in to everything or something like that.

I am also interested in this; it's not uncommon that an engineer is testing a regression somewhere and wants to trigger a full CI build of an old revision. Today, their options are (a) have admin access to the Harbormaster Build Plan, which requires a large amount of trust or (b) bother someone who does have admin access to press buttons.

I would also be interested in this feature; here's our use-case if you possibly find it more persuasive than OP's:

I suppose another reasonable attacker is "laptop thieves", but deleting any locally stored mail which was accidentally transmitted in the open seems like a reasonable way to recover from any confusion that arises until we figure out how foolproof the behavior needs to be.

The intended trigger for "Must Encrypt" is Herald rules like this: