I'm generally very hesitant to "nag" users, and this conflicts with T7477 (which wants email to a group of users, including an application email address, to work). Of the two, I think T7477 is significantly more valuable. And, some day, many years from now, I'd theoretically like to make metamta.one-mail-per-recipient the only supported mode, which fixes this anyway.

This is a big chunk of work with no current customer interest. It could be implemented as a third-party extension today; otherwise I think it's unlikely to move forward without customer interest.

These are so niche that I think we probably don't want to formally support them in the upstream.

I don't plan to change this without a better understanding of what problem we're solving. New users can click the link in the email to review the discussion, summary, and patch.

See also PHI1011. I think the fix here is likely easy, but I'd like more clarity on:

(Must Encrypt Mail is a magic meta-tag for testing the feature, not an organizational tag.)

See T8962, somewhat. When receiving inbound mail, we could decrypt PGP messages and verify PGP signatures.

It sounds like behavior here is basically correct/expected (content is treated as content; attachments are treated as attachments) and the original report was a top-posting vs quoting issue perhaps (see also T5181), just not ideal (preferable would be validating the signature, or at least discarding these attachments).

The existence of alternate ... code signing standards would motivate

It seems like any client which has this behavior must always break when a user is added to an existing thread (via, for example, "Reply All" + add them as a "Cc"). I think we're either missing something significant, or those clients (possibly just KMail?) aren't handling this situation correctly and this is a bug which should be fixed in those clients rather than Phabricator.

I'm not confident there's really a path forward here even for the subset of mailers where we have full control of the SMTP envelope and can generate Message-IDs, which is only a small subset of mailers today. Even if it does work, it makes the "Reply All" problem worse.

Not clear that "Sender" is worth pursuing, even if it does give us more flexibility around configuring the "From" header in some cases.

This is years old and I have no idea how to reproduce it. (I use Mail with "Organize by Conversation" as my primary mail client, and have for about a decade.)

This logic should probably look more like this [differentiating between explicit senders and receive-as-users].

As tends to be par for the course, this is turning into a bit of a rabbit hole.

I'm considering pushing this forward since MFA is getting an update (see T13231 and adjacent tasks).

I expect to make TOTP configuration a concrete object, then pursue Yubikey/U2F (T8787) and Duo (PHI912).

• Also, comment interactions should get a warning when you'll be required to MFA on submit, especially when you don't have MFA on your account.

...it is virtually inconceivable to me that this is something we would ever bring upstream in any form.

Also, just so I don't forget:

The original request focused on OTP, not U2F, but I think the amount of configuration required by OTP and the lack (?) of a pathway on mobile make it a better candidate for third-party integration than first-party integration. If we were supporting OTP in the upstream I'd want to run a first-party verification service so we aren't dependent on Yubikey's service, but the whole thing seems very messy and very bound to the Yubikey stack. It also looks (?) like Yubikey OTP and Yubikey U2F aren't linked to the same key (I think?) so you can't use U2F on one device and then fall back to OTP on mobile, even if you want to type in 44 characters? You have to enroll OTP and U2F separately.

This browser doesn’t support the FIDO U2F standard yet.

The bit-strength change above should still happen.

$table = new PhabricatorUser();
$cache_path = 'progress.json';

I just deleted the users above and am backing away from D19933, at least for now, since it doesn't feel like an especially great fit for either secure or admin.

On admin, basically every user with a blurb is abusive. I've just disabled the field as a coarse reaction.

I'm planning to banish these users from secure. This is mostly: polish (?) SEO bots; printer fax spam; and "security researchers":

There's some ephemeral data on this host and my house doesn't currently burn down if the associated services are unavailable, so I'm just going to let AWS restart it when the time comes.

• We still need to key the Image table in Pholio (see D19914) although the right key looks like just <mockPHID>.
• instances/ should get some cleanup for the changes to transactions.

Oh, this is on my personal AWS account. Oops!

I'll get this actually landed, but here's the patch I'm using for ForceUser until I get there:

(Please use Discourse for this sort of discussion.)

@amckinley, for general context on where I'm headed here: