When Phabricator receives the mail, it doesn't know which "To" or "Cc" actually caused delivery

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.

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.

(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].

I would like to add another use case where this would be beneficial.

To pull the list down (this takes a while since we can only grab 100 results at a time and the API takes a while to respond):

See PHI926, where a GSuite-backed install has seen multiple "550 No Such User" bounces to the same address even though the address exists. It's currently unclear if this is an issue in Mailgun, GSuite, the series of tubes between the two, or elsewhere.

In my case (using GMail) it appears to thread properly as well however apparently some clients (KMail) rely on these headers more heavily than others.

In order for threading to work in email clients, the Message-ID header needs to be set on the initial email, with following emails having In-Reply-To / References set to that same Message-ID.

I can't reproduce this: mail threads properly in my client.

@epriestley T7468: No way to disable web notifications for token awards was marked as duplicate of T10448, which in turn was resolved with a pointer to this task.

D19485 fixed one small remaining bug; I deployed that to admin.

• I cherry-picked to stable and deployed to admin.
• I launched a test instance, invited 32 users, and saw only 20 invites actually go out.
• After accepting two invites, I saw more invites go out.
• I cancelled some invites, for good measure.

I think my plan here is basically:

The "Pending Invites" counter didn't seem to work correctly for this instance.

Ah, yeah. No idea why I typed "blind" instead.

There should be a very small number of readers (2-3?) of this field, so it should be possible to blind them safely like this:

No. Mail stamps are not intended to answer "Why am I receiving this mail?" in the general case (which lives in T9412 now, I think).

Will stamps be applied for all email notifications and reasons for the recipient to receive them, so as to fix T6297: Maniphest email notification doesn't say why I'm receiving it?

This hasn't blown up in 24 hours and is about to promote, so anything else can be handled in followups.

(Testing "secure" flag in webhooks. 🐑)

Seems OK: