Since T13227 has an actual realtime deadline, that's probably a good time to take care of this, too.

This can be implemented as a third-party extension. We're unlikely to ever pursue it upstream without customer interest.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella. That is, the future for these use cases mostly looks like "lightweight/external users interact with Nuance, then staff triage issues into other objects like Tasks that only real users interact with", not "lightweight/external users interact with every application and every application gains support for email/external/grey interactions".

I ran a query against a subset of instances to see if any instances had configured metamta.insecure-auth-with-reply-to, to get a sense of how safe it is to remove this option.

In moving forward here, we're generally moving from manually-configured HMAC keys to automatic ones. This is generally good: it's simpler (less configuration); and I believe almost no one configured the old ones, so installs now actually get unique HMAC keys; and the new keys have more entropy, too.

See a note in T12509 about HMAC key regeneration.

For the record: I'd like us to get away from maintaining our own phab fork, and I agree that means probably migrating to a different system at some point.

FWIW, I think describing these as "non mainstream" and the entire description of these communities sounds to me ... somewhere between biased and pejorative. Makes it hard for me to keep engaging in the discussion.

Does anyone have experience with an existing Push Notifications As A Service provider? I would naively suggest AWS SNS, because we already depend on other AWS services and it's free for the first 1m pushes, and then $0.50/1m pushes after that. It also wouldn't raise any new data privacy issues for Phacility customers since we wouldn't have to deliver pushes outside of our existing VPC infrastructure. List of supported push targets:

See PHI500 and T13179. Recent versions of SSH support passing the key fingerprint to the AuthorizedKeysCommand by specifying it like this:

D19935 prepares for multiple MFA provider types.

Maybe worth a mention -- GHC is another somewhat-similar project and moving to GitLab (e.g., https://mail.haskell.org/pipermail/ghc-devs/2018-October/016425.html). It sounds like GitLab is currently better able to spend resources to support free users with relatively non-mainstream use cases than we are.

For the record, yes, FreeBSD is quite similar and what @chandlerc wrote is very much applicable to our community as well.

I think a lot of this behavior may be fairly unique to the LLVM project, since we've never really received this general class of feedback from other installs (except, perhaps, FreeBSD, which I think is somewhat culturally similar).

For the record, while the rationale can be flippantly described as "I don't like clicking things", I'd like to give it a serious description.

This is the most upsetting bug in the software.

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 expect Google to expose a similar solution to Duo soonish (if you use Android and try to login to Google, MFA is just like Duo now).

Some of these things are supposed to be implemented in a reasonable way via browsers "eventually" (offline push notifications have a bunch of attempts, Screenshots use case has some solutions that sometimes work, and there's rumor about MFA and NFC floating around.)

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: