1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-19 20:10:55 +01:00
phorge-phorge/src/applications/metamta/query/PhabricatorMetaMTAActor.php

122 lines
4 KiB
PHP
Raw Normal View History

Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
<?php
final class PhabricatorMetaMTAActor extends Phobject {
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
const STATUS_DELIVERABLE = 'deliverable';
const STATUS_UNDELIVERABLE = 'undeliverable';
const REASON_UNLOADABLE = 'unloadable';
const REASON_UNMAILABLE = 'unmailable';
const REASON_NO_ADDRESS = 'noaddress';
const REASON_DISABLED = 'disabled';
const REASON_MAIL_DISABLED = 'maildisabled';
const REASON_EXTERNAL_TYPE = 'exernaltype';
const REASON_RESPONSE = 'response';
const REASON_SELF = 'self';
const REASON_MAILTAGS = 'mailtags';
const REASON_BOT = 'bot';
const REASON_FORCE = 'force';
const REASON_FORCE_HERALD = 'force-herald';
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
private $phid;
private $emailAddress;
private $name;
private $status = self::STATUS_DELIVERABLE;
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
private $reasons = array();
public function setName($name) {
$this->name = $name;
return $this;
}
public function getName() {
return $this->name;
}
public function setEmailAddress($email_address) {
$this->emailAddress = $email_address;
return $this;
}
public function getEmailAddress() {
return $this->emailAddress;
}
public function setPHID($phid) {
$this->phid = $phid;
return $this;
}
public function getPHID() {
return $this->phid;
}
public function setUndeliverable($reason) {
$this->reasons[] = $reason;
$this->status = self::STATUS_UNDELIVERABLE;
return $this;
}
public function setDeliverable($reason) {
$this->reasons[] = $reason;
$this->status = self::STATUS_DELIVERABLE;
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
return $this;
}
public function isDeliverable() {
return ($this->status === self::STATUS_DELIVERABLE);
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
}
public function getDeliverabilityReasons() {
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
return $this->reasons;
}
public static function getReasonDescription($reason) {
$descriptions = array(
self::REASON_DISABLED => pht(
'This user is disabled; disabled users do not receive mail.'),
self::REASON_BOT => pht(
'This user is a bot; bot accounts do not receive mail.'),
self::REASON_NO_ADDRESS => pht(
'Unable to load an email address for this PHID.'),
self::REASON_EXTERNAL_TYPE => pht(
'Only external accounts of type "email" are deliverable; this '.
'account has a different type.'),
self::REASON_UNMAILABLE => pht(
'This PHID type does not correspond to a mailable object.'),
self::REASON_RESPONSE => pht(
'This message is a response to another email message, and this '.
'recipient received the original email message, so we are not '.
'sending them this substantially similar message (for example, '.
'the sender used "Reply All" instead of "Reply" in response to '.
'mail from Phabricator).'),
self::REASON_SELF => pht(
'This recipient is the user whose actions caused delivery of '.
'this message, but they have set preferences so they do not '.
'receive mail about their own actions (Settings > Email '.
'Preferences > Self Actions).'),
self::REASON_MAIL_DISABLED => pht(
'This recipient has disabled all email notifications '.
'(Settings > Email Preferences > Email Notifications).'),
self::REASON_MAILTAGS => pht(
'This mail has tags which control which users receive it, and '.
'this recipient has not elected to receive mail with any of '.
'the tags on this message (Settings > Email Preferences).'),
self::REASON_UNLOADABLE => pht(
'Unable to load user record for this PHID.'),
self::REASON_FORCE => pht(
'Delivery of this mail is forced and ignores deliver preferences. '.
'Mail which uses forced delivery is usually related to account '.
'management or authentication. For example, password reset email '.
'ignores mail preferences.'),
self::REASON_FORCE_HERALD => pht(
'This recipient was added by a "Send me an Email" rule in Herald, '.
'which overrides some delivery settings.'),
);
return idx($descriptions, $reason, pht('Unknown Reason ("%s")', $reason));
}
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
}