1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-02-27 05:59:08 +01:00
Commit graph

11 commits

Author SHA1 Message Date
epriestley
b3d3130b71 Fix a potentially lax hash comparison
Summary: Via HackerOne. See D14025. I missed this comparison when making the original change.

Test Plan:
  - Used `cat mail.txt | scripts/mail/mail_handler.php --process-duplicates` to pipe mail in a whole lot of times.
  - Tried bad hashes, saw rejections.
  - Tried good hash, saw mail accepted.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14455
2015-11-10 10:22:25 -08:00
epriestley
de01f3e2e0 Add Maniphest Task email creator to CCs
Summary: Fixes T9369.

Test Plan:
  - Sent a mail with Mail.app to `bugs@local.phacility.com`.
  - Used "View Raw Mail", copy-pasted it into `mail.txt` on disk.
  - Ran `cat mail.txt | ./scripts/mail/manage_mail.php --process-duplicates`.
  - Saw task get created and me get added as CC.
  - Changed "To" to include another user, ran command again, saw task get created and other user get added as CC.

Reviewers: chad

Reviewed By: chad

Subscribers: Korvin

Maniphest Tasks: T9369

Differential Revision: https://secure.phabricator.com/D14086
2015-09-09 14:07:07 -07:00
epriestley
eb81fd1562 Expose all application mail receivers
Summary:
Fixes T7199. This still isn't a shining example of perfect code, but the raw amount of copy/paste is much lower than it used to be.

  - Reduce code duplication between existing receivers.
  - Expose receiving objects in help menus where appropriate.
  - Connect some "TODO" receivers.

Test Plan:
  - Sent mail to every supported object type.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7199

Differential Revision: https://secure.phabricator.com/D12249
2015-04-01 11:52:02 -07:00
epriestley
d9cdbdb9fa When we fail to process mail, tell the user about it
Summary:
Ref T4371. Ref T4699. Fixes T3994.

Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff.

However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening.

Thus:

  - When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address.
  - Rewrite most of the errors to be more detailed and informative.
  - Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent..").
  - Remove the redundant, less sophisticated code which does something similar in Differential.

Test Plan:
  - Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail.
  - Hit a bunch of different errors.
  - Saw reasonable error mail get sent to me.
  - Saw other reasonable error mail get rate limited.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3994, T4371, T4699

Differential Revision: https://secure.phabricator.com/D8692
2014-04-03 18:43:18 -07:00
epriestley
a3c811f281 Accept case-insensitive mail replies
Summary:
Mailbox sometimes (?) changes the case of the email address (?). Be more liberal in what we accept.

Also fix a minor output bug.

Test Plan: Sent mail to `e1+...` instead of `E1+...`, verified it arrived.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7575
2013-11-12 21:23:23 -08:00
Jakub Vrana
8b95669e82 Fix typo in typehint 2013-06-05 11:52:12 -07:00
epriestley
5cd13c3c65 Remove the last hardcoding from PhabricatorMetaMTAReceivedMail
Summary:
Moves all remaining mail handling into ReplyHandlers.

Farewell, `getPhabricatorToInformation()`! You were a bad method and no one liked you.

Ref T1205.

Test Plan:
  - Used test console to send mail to Revisions, Tasks, Conpherences and Commits (these all actually work).
  - Used test console to send mail to Requests, Macros, Questions and Mocks (these accept the mail but don't do anything with it, but didn't do anything before either).

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1205

Differential Revision: https://secure.phabricator.com/D5953
2013-05-17 10:00:49 -07:00
epriestley
a548773209 Make "Receive Test" mail form use MailReceivers
Summary: Currently this is fairly hard-coded. Instead, make it use available receivers. Ref T1205.

Test Plan: Used mail form to send mail to various objects (Dnn, Tnn, Cnn, etc.). Only some of these work right now because the receiver thing still hard-codes a bunch of junk.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1205

Differential Revision: https://secure.phabricator.com/D5944
2013-05-17 03:51:33 -07:00
epriestley
2676e91dd8 Move sender validation into MailReceiver classes
Summary:
Ref T1205. Finally able to delete a big chunk of this nastiness.

Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy.

Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1205

Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 03:49:29 -07:00
epriestley
5243b0d653 Move computeMailHash() to PhabricatorObjectMailReceiver
Summary: Kick this out of here. Ref T1205.

Test Plan: Grep.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1205

Differential Revision: https://secure.phabricator.com/D5942
2013-05-17 03:49:00 -07:00
epriestley
341079c3cf Move some received mail responsibility to applications
Summary:
Ref T1205. Continuation of D5915.

Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular:

  - New mail receivers in applications must edit it.
  - Mail receivers don't drop out when applications are uninstalled.

Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail).

Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely.

For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled.

I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications.

Test Plan: Unit tests, used receive test to route mail to various objects.

Reviewers: btrahan

Reviewed By: btrahan

CC: Afaque_Hussain, edward, aran

Maniphest Tasks: T1205

Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 10:57:41 -07:00