(I've muted this task so I shouldn't get mail about it.)

"Quack, quack" said the duck.

We now have Postmark configured as a primary mailer for this domain with inbound (via MX record) and outbound (via cluster.mailers) failover to Mailgun. 📫

"Moo", said the cow.

• PhabricatorMailSetupCheck should be removed, but some of the SES stuff should stick around.

I largely agree. This is getting leeway because it's backed by support mana (PHI126 basically just asks for this feature, verbatim). I think the actual change in D19033 is small enough that I don't feel too bad about giving this a shot, but I'd like this feature to see significant use and not generate a lot of confusion/support load if it's going to stay in the upstream. I'm also more comfortable trying this because it's very easy to revert.

For what it's worth, I think the Mute feature adds a lot of complexities to the system, in excess to the norms of the last few years:

• Code to handle it in the sending mechanism
• Prioritizing this feature against any other notify feature (like T9031)
• UI to show the to the muting user (on the object and in /mail/?)
• UI to show to other users that this user will not be notified (What if all members of a project are muting a thread?)
• Can a mailing list/project mute a topic?
• "why did I not receive this notification?" - there's still some issues about this - novice users don't know/understand /mail/, and admins can't see this for them. I suspect this question will require a written checklist somewhere.

See T13069 for followups on mail stamps.

See T13069 for this and other similar use cases.

I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".

I'm going to roll this forward into T13069.

If this feature doesn't see much use, I'd like to remove or deemphasize it (for example, by moving it to a keystroke or removing the UI and just providing access via !mute) at some point since I think UI space in the curtain is premium real estate. This doesn't need to be 200 mutes per user per day, but I could imagine this seeing essentially zero use.

If we make "Must Encrypt" stateful, that flag should also probably live in this table.

The scope on T13053 didn't end up making it very far in this direction so I think this missed the boat for now.

T11934 plans to add these commands everywhere. If they're available all over the place, it might be less necessary to add reminders.

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.

I'm not sure how to reproduce whatever remaining issues are described here so I don't see how to move this forward.

D19030 marks this as fixed: it removes this documentation.

I'm going to merge this into T10448, which exposes this information in an X-Header and optionally in mail bodies.

I've marked D19029 as resolving this since it fixes the last one of these that I'm aware of. HTML mail has been the default for a long time now so this presumably isn't really causing problems even if there are other cases.

See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway.

If D19012/D19013 turn out badly this table should be <objectPHID, mailKey, firstSubjectWeSentMailWith> so there's some vague argument for waiting until those are in the wild for a little bit or naming the table in a more generic way (MailObjectMetadata instead of MailObjectKey).

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: