2013-05-14 01:32:19 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class MetaMTAReceivedMailStatus
|
|
|
|
extends MetaMTAConstants {
|
|
|
|
|
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';
|
2013-05-15 17:44:54 +02:00
|
|
|
const STATUS_UNKNOWN_SENDER = 'err:unknown-sender';
|
2013-05-17 12:49:29 +02:00
|
|
|
const STATUS_DISABLED_SENDER = 'err:disabled-sender';
|
|
|
|
const STATUS_NO_PUBLIC_MAIL = 'err:no-public-mail';
|
|
|
|
const STATUS_USER_MISMATCH = 'err:bad-user';
|
|
|
|
const STATUS_POLICY_PROBLEM = 'err:policy';
|
|
|
|
const STATUS_NO_SUCH_OBJECT = 'err:not-found';
|
|
|
|
const STATUS_HASH_MISMATCH = 'err:bad-hash';
|
2013-05-17 19:00:49 +02:00
|
|
|
const STATUS_UNHANDLED_EXCEPTION = 'err:exception';
|
2014-04-04 20:14:33 +02:00
|
|
|
const STATUS_EMPTY = 'err:empty';
|
|
|
|
const STATUS_EMPTY_IGNORED = 'err:empty-ignored';
|
2013-05-14 01:32:19 +02:00
|
|
|
|
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-04 03:43:18 +02:00
|
|
|
public static function getHumanReadableName($status) {
|
|
|
|
$map = array(
|
|
|
|
self::STATUS_DUPLICATE => pht('Duplicate Message'),
|
|
|
|
self::STATUS_FROM_PHABRICATOR => pht('Phabricator Mail'),
|
|
|
|
self::STATUS_NO_RECEIVERS => pht('No Receivers'),
|
|
|
|
self::STATUS_ABUNDANT_RECEIVERS => pht('Multiple Receivers'),
|
|
|
|
self::STATUS_UNKNOWN_SENDER => pht('Unknown Sender'),
|
|
|
|
self::STATUS_DISABLED_SENDER => pht('Disabled Sender'),
|
|
|
|
self::STATUS_NO_PUBLIC_MAIL => pht('No Public Mail'),
|
|
|
|
self::STATUS_USER_MISMATCH => pht('User Mismatch'),
|
|
|
|
self::STATUS_POLICY_PROBLEM => pht('Policy Error'),
|
|
|
|
self::STATUS_NO_SUCH_OBJECT => pht('No Such Object'),
|
|
|
|
self::STATUS_HASH_MISMATCH => pht('Bad Address'),
|
|
|
|
self::STATUS_UNHANDLED_EXCEPTION => pht('Unhandled Exception'),
|
2014-04-04 20:14:33 +02:00
|
|
|
self::STATUS_EMPTY => pht('Empty Mail'),
|
|
|
|
self::STATUS_EMPTY_IGNORED => pht('Ignored Empty Mail'),
|
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-04 03:43:18 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
return idx($map, $status, pht('Processing Exception'));
|
|
|
|
}
|
|
|
|
|
2013-05-14 01:32:19 +02:00
|
|
|
}
|