kind of sad this isn't called pherret

closed per user request

(dropped this since I don't have time to fully test, but I might come back to this in the future)

In T12240#211112, @epriestley wrote:

To jump back further, the root-ier cause is that you're using mailing lists?

If we implemented T3980, could you create projects for mailing lists instead of "Mailing List" users, then do one-mail-per-recipient + private-replies and be generally OK?

In T12240#211108, @epriestley wrote:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

I don't think we have control over the SMTP envelope for at least some of of the APIs we implement, although perhaps I'm mistaken. In some cases I chose the non-SMTP version of things (e.g., POST some JSON) when an SMTP version was available since I mostly know how JSON works but do not mostly know how SMTP works. It's possible we could revisit those decisions and do more SMTP to get greater access to envelopes, although I'd guess not all adapters provide us envelope access.

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user.

We already attempt to do this -- are you seeing it not work in practice? Rough pathway is:

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user. Of course, given the above, this is spoofable.

Unless I'm missing something, I think the instructions here cause X to receive two mails (they are on "To" for both).

In T12163#208938, @epriestley wrote:

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

In D17114#202971, @epriestley wrote:

However, I suspect that grouping/reordering will resolve this concern without more drastic steps.

Agreed. I suspect that this was mostly the case of seeing two "A" words near each other (and possibly just being used to ↓+A+⏎

one complaint we (FreeBSD) get when we enable abandon for anyone is that the top action is abandon, not accept, and this causes it get used accidentally. Does this change that behavior?

FWIW #Twitter has multiple users of this feature and we'd likely get complaints if it broke

updated advisory; https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
I don't think this changes the plan you suggest, just linking for completeness.

You should reask this in https://secure.phabricator.com/ponder/
Maniphest is for bugs and feature requests, not help

T5505 is related

Performance concern. At least one use case requires us to scour *all diffs and all diff ids*. Also a desire to avoid having deprecated calls in our codebase.