phorge-phorge/src/applications/metamta/constants/MetaMTAReceivedMailStatus.php

<?php

final class MetaMTAReceivedMailStatus
  extends MetaMTAConstants {

  const STATUS_DUPLICATE            = 'err:duplicate';
  const STATUS_FROM_PHABRICATOR     = 'err:self';
  const STATUS_NO_RECEIVERS         = 'err:no-receivers';
  const STATUS_ABUNDANT_RECEIVERS   = 'err:multiple-receivers';

}
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915 2013-05-14 01:32:19 +02:00			`<?php`

			`final class MetaMTAReceivedMailStatus`
			`extends MetaMTAConstants {`

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 19:57:41 +02:00			`const STATUS_DUPLICATE = 'err:duplicate';`
			`const STATUS_FROM_PHABRICATOR = 'err:self';`
			`const STATUS_NO_RECEIVERS = 'err:no-receivers';`
			`const STATUS_ABUNDANT_RECEIVERS = 'err:multiple-receivers';`
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915 2013-05-14 01:32:19 +02:00
			`}`