Allow multiple mail receivers to react to an individual email
e3aa043a0272
Actions

Description

Allow multiple mail receivers to react to an individual email

Summary:
Fixes T7477. Fixes T13066. Currently, inbound mail is processed by the first receiver that matches any "To:" address. "Cc" addresses are ignored.

To, CC, and Multiple Receivers

Some users would like to be able to "Cc" addresses like bugs@ instead of having to "To" the address, which makes perfect sense. That's the driving use case behind T7477.

Since users can To/Cc multiple "create object" or "update object" addresses, I also wanted to make the behavior more general. For example, if you email bugs@ and also paste@, your mail might reasonably make both a Task and a Paste. Is this useful? I'm not sure. But it seems like it's pretty clearly the best match for user intent, and the least-surprising behavior we can have. There's also no good rule for picking which address "wins" when two or more match -- we ended up with "address order", which is pretty arbitrary since "To" and "Cc" are not really ordered fields.

One part of this change is removing phabricator.allow-email-users. In practice, this option only controlled whether users were allowed to send mail to "Application Email" addresses with a configured default author, and it's unlikely that we'll expand it since I think the future of external/grey users is Nuance, not richer interaction with Maniphest/Differential/etc. Since this option only made "Default Author" work and "Default Author" is optional, we can simplify behavior by making the rule work like this:

If an address specifies a default author, it allows public email.
If an address does not, it doesn't.

That's basically how it worked already, except that you could intentionally "break" the behavior by not configuring phabricator.allow-email-users. This is a backwards compatility change with possible security implications (it might allow email in that was previously blocked by configuration) that I'll call out in the changelog, but I suspect that no installs are really impacted and this new behavior is generally more intuitive.

A somewhat related change here is that each receiver is allowed to react to each individual email address, instead of firing once. This allows you to configure bugs-a@ and bugs-b@ and CC them both and get two tasks. Useful? Maybe not, but seems like the best execution of intent.

Sender vs Author

Adjacently, T13066 described an improvement to error handling behavior here: we did not distinguish between "sender" (the user matching the email "From" address) and "actor" (the user we're actually acting as in the application). These are different when you're some internet rando and send to bugs@, which has a default author. Then the "sender" is null and the "author" is @bugs-robot or whatever (some user account you've configured).

This refines "Sender" vs "Author". This is mostly a purity/correctness change, but it means that we won't send random email error messages to @bugs-robot.

Since receivers are now allowed to process mail with no "sender" if they have some default "actor" they would rather use instead, it's not an error to send from an invalid address unless nothing processes the mail.

Other

This removes the "abundant receivers" error since this is no longer an error.

This always sets "external user" mail recipients to be unverified. As far as I can tell, there's no pathway by which we send them email anyway (before or after this change), although it's possible I'm missing something somewhere.

Test Plan:
I did most of this with bin/mail receive-test. I rigged the workflow slightly for some of it since it doesn't support multiple addresses or explicit "CC" and adding either would be a bit tricky.

These could also be tested with scripts/mail/mail_handler.php, but I don't currently have the MIME parser extension installed locally after a recent upgrade to Mojave and suspect T13232 makes it tricky to install.

Ran unit tests, which provide significant coverage of this flow.
Sent mail to multiple Maniphest application emails, got multiple tasks.
Sent mail to a Maniphest and a Paste application email, got a task and a paste.
Sent mail to a task.
- Saw original email recorded on tasks. This is a behavior particular to tasks.
Sent mail to a paste.
Sent mail to a mock.
Sent mail to a Phame blog post.
Sent mail to a Legalpad document.
Sent mail to a Conpherence thread.
Sent mail to a poll.
This isn't every type of supported object but it's enough of them that I'm pretty confident I didn't break the whole flow.
Sent mail to an object I could not view (got an error).
As a non-user, sent mail to several "create an object..." addresses.
- Addresses with a default user worked (e.g., created a task).
- Addresses without a default user did not work.