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:

The "Must Encrypt" change will necessarily link into the existing /mail/ web UI so users can read the mail content, so it's probably worth considering possible improvements.

Although I'm suppressing the X-Phabricator-To and X-Phabricator-Cc headers for "Must Encrypt" mail (and the "To: ..." and "Cc: ..." footers in the body), the recipients will still be visible in the actual "To" and "Cc" lines if metamta.one-mail-per-recipient has been configured to false instead of the default (which is true).

On Thread-Topic, this very old thread suggests that Outlook can show the header in some cases: https://bugzilla.mozilla.org/show_bug.cgi?id=411601

@cmmata here is my diff. It can probably be improved, but it works for me:

@mcorteel I have the same problem, arc unit only works with phpunit 5.7. If I use 6.5, it fails. Do you have that patch anywhere with public access so we can use it while it's not published?

Here I was thinking I found a helpful public bug.

From rereading D18600, maybe "ridiculously strong" is an understatement and it was actually so powerful it took effect even if you didn't enable it.

Locally, seems like "No Notifications" correctly has no effect on the "Upload" bubble being shown at HEAD of master.

Hm, actually the problem here is that the notification bubble doesn't show up for any file uploads on our current version. I suppose it could actually be "on our current version + extensions". I'll get a reproduction matrix together tomorrow.

Not unless something super weird/buggy is going on.

We don't have a notifications server, does that make it like that?

It's possible that adjusting Settings → Notifications to No Notifications disables this bubble, if that's a compounding factor here. D18600 pulled back some of the aggressiveness of that setting but I'd guess it might still be hitting the upload progress bubbles.

Ok I actually get a dialog on secure., it's probably because we're out of date with the upstream.

What browser are you using? I get a progress bubble in the lower left immediately. Here's a screenshot -- note the blue upload progress element in the lower left corner.