1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-09-23 02:38:48 +02:00
phorge-phorge/src/applications/metamta/storage/PhabricatorMetaMTAMail.php

961 lines
28 KiB
PHP
Raw Normal View History

2011-01-26 02:40:21 +01:00
<?php
/**
* See #394445 for an explanation of why this thing even exists.
*
* @task recipients Managing Recipients
2011-01-26 02:40:21 +01:00
*/
final class PhabricatorMetaMTAMail extends PhabricatorMetaMTADAO {
2011-01-26 02:40:21 +01:00
const STATUS_QUEUE = 'queued';
const STATUS_SENT = 'sent';
const STATUS_FAIL = 'fail';
const STATUS_VOID = 'void';
2011-01-26 02:40:21 +01:00
const MAX_RETRIES = 250;
const RETRY_DELAY = 5;
protected $parameters;
protected $status;
protected $message;
protected $retryCount;
protected $nextRetry;
protected $relatedPHID;
private $excludePHIDs = array();
private $overrideNoSelfMail = false;
2011-01-26 02:40:21 +01:00
public function __construct() {
$this->status = self::STATUS_QUEUE;
$this->retryCount = 0;
$this->nextRetry = time();
$this->parameters = array();
parent::__construct();
}
public function getConfiguration() {
return array(
self::CONFIG_SERIALIZATION => array(
'parameters' => self::SERIALIZATION_JSON,
),
) + parent::getConfiguration();
}
protected function setParam($param, $value) {
$this->parameters[$param] = $value;
return $this;
}
protected function getParam($param, $default = null) {
return idx($this->parameters, $param, $default);
2011-01-26 02:40:21 +01:00
}
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
/**
* Set tags (@{class:MetaMTANotificationType} constants) which identify the
* content of this mail in a general way. These tags are used to allow users
* to opt out of receiving certain types of mail, like updates when a task's
* projects change.
*
* @param list<const> List of @{class:MetaMTANotificationType} constants.
* @return this
*/
public function setMailTags(array $tags) {
$this->setParam('mailtags', $tags);
return $this;
}
/**
* In Gmail, conversations will be broken if you reply to a thread and the
* server sends back a response without referencing your Message-ID, even if
* it references a Message-ID earlier in the thread. To avoid this, use the
* parent email's message ID explicitly if it's available. This overwrites the
* "In-Reply-To" and "References" headers we would otherwise generate. This
* needs to be set whenever an action is triggered by an email message. See
* T251 for more details.
*
* @param string The "Message-ID" of the email which precedes this one.
* @return this
*/
public function setParentMessageID($id) {
$this->setParam('parent-message-id', $id);
return $this;
}
public function getParentMessageID() {
return $this->getParam('parent-message-id');
}
2011-01-26 02:40:21 +01:00
public function getSubject() {
return $this->getParam('subject');
}
public function addTos(array $phids) {
$phids = array_unique($phids);
2011-01-26 02:40:21 +01:00
$this->setParam('to', $phids);
return $this;
}
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
public function addRawTos(array $raw_email) {
$this->setParam('raw-to', $raw_email);
return $this;
}
2011-01-26 02:40:21 +01:00
public function addCCs(array $phids) {
$phids = array_unique($phids);
2011-01-26 02:40:21 +01:00
$this->setParam('cc', $phids);
return $this;
}
public function setExcludeMailRecipientPHIDs($exclude) {
$this->excludePHIDs = $exclude;
return $this;
}
private function getExcludeMailRecipientPHIDs() {
return $this->excludePHIDs;
}
public function getOverrideNoSelfMailPreference() {
return $this->overrideNoSelfMail;
}
public function setOverrideNoSelfMailPreference($override) {
$this->overrideNoSelfMail = $override;
return $this;
}
public function getTranslation(array $objects) {
$default_translation = PhabricatorEnv::getEnvConfig('translation.provider');
$return = null;
$recipients = array_merge(
idx($this->parameters, 'to', array()),
idx($this->parameters, 'cc', array()));
foreach (array_select_keys($objects, $recipients) as $object) {
$translation = null;
if ($object instanceof PhabricatorUser) {
$translation = $object->getTranslation();
}
if (!$translation) {
$translation = $default_translation;
}
if ($return && $translation != $return) {
return $default_translation;
}
$return = $translation;
}
if (!$return) {
$return = $default_translation;
}
return $return;
}
public function addPHIDHeaders($name, array $phids) {
foreach ($phids as $phid) {
$this->addHeader($name, '<'.$phid.'>');
}
return $this;
}
2011-01-26 02:40:21 +01:00
public function addHeader($name, $value) {
$this->parameters['headers'][] = array($name, $value);
2011-01-26 02:40:21 +01:00
return $this;
}
public function addAttachment(PhabricatorMetaMTAAttachment $attachment) {
$this->parameters['attachments'][] = $attachment->toDictionary();
return $this;
}
public function getAttachments() {
$dicts = $this->getParam('attachments');
$result = array();
foreach ($dicts as $dict) {
$result[] = PhabricatorMetaMTAAttachment::newFromDictionary($dict);
}
return $result;
}
public function setAttachments(array $attachments) {
assert_instances_of($attachments, 'PhabricatorMetaMTAAttachment');
$this->setParam('attachments', mpull($attachments, 'toDictionary'));
return $this;
}
2011-01-26 02:40:21 +01:00
public function setFrom($from) {
$this->setParam('from', $from);
return $this;
}
2011-01-26 18:08:26 +01:00
public function setReplyTo($reply_to) {
$this->setParam('reply-to', $reply_to);
2011-01-26 02:40:21 +01:00
return $this;
}
public function setSubject($subject) {
$this->setParam('subject', $subject);
return $this;
}
public function setSubjectPrefix($prefix) {
$this->setParam('subject-prefix', $prefix);
return $this;
}
public function setVarySubjectPrefix($prefix) {
$this->setParam('vary-subject-prefix', $prefix);
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
return $this;
}
2011-01-26 02:40:21 +01:00
public function setBody($body) {
$this->setParam('body', $body);
return $this;
}
public function getBody() {
return $this->getParam('body');
}
2011-01-26 02:40:21 +01:00
public function setIsHTML($html) {
$this->setParam('is-html', $html);
return $this;
}
public function getSimulatedFailureCount() {
return nonempty($this->getParam('simulated-failures'), 0);
}
public function setSimulatedFailureCount($count) {
$this->setParam('simulated-failures', $count);
return $this;
}
public function getWorkerTaskID() {
return $this->getParam('worker-task');
}
public function setWorkerTaskID($id) {
$this->setParam('worker-task', $id);
return $this;
}
/**
* Flag that this is an auto-generated bulk message and should have bulk
* headers added to it if appropriate. Broadly, this means some flavor of
* "Precedence: bulk" or similar, but is implementation and configuration
* dependent.
*
* @param bool True if the mail is automated bulk mail.
* @return this
*/
public function setIsBulk($is_bulk) {
$this->setParam('is-bulk', $is_bulk);
return $this;
}
/**
* Use this method to set an ID used for message threading. MetaMTA will
* set appropriate headers (Message-ID, In-Reply-To, References and
* Thread-Index) based on the capabilities of the underlying mailer.
*
* @param string Unique identifier, appropriate for use in a Message-ID,
* In-Reply-To or References headers.
* @param bool If true, indicates this is the first message in the thread.
* @return this
*/
public function setThreadID($thread_id, $is_first_message = false) {
$this->setParam('thread-id', $thread_id);
$this->setParam('is-first-message', $is_first_message);
return $this;
}
/**
* Save a newly created mail to the database and attempt to send it
* immediately if the server is configured for immediate sends. When
* applications generate new mail they should generally use this method to
* deliver it. If the server doesn't use immediate sends, this has the same
* effect as calling save(): the mail will eventually be delivered by the
* MetaMTA daemon.
*
* @return this
*/
public function saveAndSend() {
$ret = null;
if (PhabricatorEnv::getEnvConfig('metamta.send-immediately')) {
$ret = $this->sendNow();
} else {
$ret = $this->save();
}
return $ret;
}
protected function didWriteData() {
parent::didWriteData();
if (!$this->getWorkerTaskID()) {
$mailer_task = PhabricatorWorker::scheduleTask(
'PhabricatorMetaMTAWorker',
$this->getID());
$this->setWorkerTaskID($mailer_task->getID());
$this->save();
}
}
public function buildDefaultMailer() {
return PhabricatorEnv::newObjectFromConfig('metamta.mail-adapter');
}
2011-01-26 02:40:21 +01:00
/**
* Attempt to deliver an email immediately, in this process.
*
* @param bool Try to deliver this email even if it has already been
* delivered or is in backoff after a failed delivery attempt.
* @param PhabricatorMailImplementationAdapter Use a specific mail adapter,
* instead of the default.
*
* @return void
*/
2011-01-26 18:08:26 +01:00
public function sendNow(
$force_send = false,
PhabricatorMailImplementationAdapter $mailer = null) {
if ($mailer === null) {
$mailer = $this->buildDefaultMailer();
}
2011-01-26 02:40:21 +01:00
if (!$force_send) {
if ($this->getStatus() != self::STATUS_QUEUE) {
throw new Exception("Trying to send an already-sent mail!");
}
if (time() < $this->getNextRetry()) {
throw new Exception("Trying to send an email before next retry!");
}
}
2011-01-26 02:40:21 +01:00
try {
$params = $this->parameters;
2011-01-26 18:33:31 +01:00
$phids = array();
foreach ($params as $key => $value) {
switch ($key) {
case 'to':
$params[$key] = $this->buildToList();
break;
case 'cc':
$params[$key] = $this->buildCCList();
break;
}
}
foreach ($params as $key => $value) {
2011-01-26 18:33:31 +01:00
switch ($key) {
case 'from':
$value = array($value);
/* fallthrough */
2011-01-26 18:33:31 +01:00
case 'to':
case 'cc':
foreach ($value as $phid) {
$type = phid_get_type($phid);
$phids[$phid] = $type;
2011-01-26 18:33:31 +01:00
}
break;
}
}
$this->loadEmailAndNameDataFromPHIDs($phids);
$default = PhabricatorEnv::getEnvConfig('metamta.default-address');
if (empty($params['from'])) {
$mailer->setFrom($default);
} else {
$from = $params['from'];
if (!PhabricatorEnv::getEnvConfig('metamta.can-send-as-user')) {
if (empty($params['reply-to'])) {
$params['reply-to'] = $phids[$from]['email'];
$params['reply-to-name'] = $phids[$from]['name'];
}
$mailer->setFrom(
$default,
$phids[$from]['name']);
unset($params['from']);
}
}
$is_first = idx($params, 'is-first-message');
unset($params['is-first-message']);
$is_threaded = (bool)idx($params, 'thread-id');
$reply_to_name = idx($params, 'reply-to-name', '');
unset($params['reply-to-name']);
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
$add_cc = array();
$add_to = array();
foreach ($params as $key => $value) {
2011-01-26 02:40:21 +01:00
switch ($key) {
case 'from':
$mailer->setFrom($phids[$from]['email']);
2011-01-26 02:40:21 +01:00
break;
case 'reply-to':
$mailer->addReplyTo($value, $reply_to_name);
2011-01-26 02:40:21 +01:00
break;
case 'to':
$to_emails = $this->filterSendable($value, $phids);
if ($to_emails) {
$add_to = array_merge($add_to, $to_emails);
2011-01-26 18:33:31 +01:00
}
2011-01-26 02:40:21 +01:00
break;
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
case 'raw-to':
$add_to = array_merge($add_to, $value);
break;
2011-01-26 02:40:21 +01:00
case 'cc':
$cc_emails = $this->filterSendable($value, $phids);
if ($cc_emails) {
$add_cc = $cc_emails;
2011-01-26 18:33:31 +01:00
}
2011-01-26 02:40:21 +01:00
break;
case 'headers':
foreach ($value as $pair) {
list($header_key, $header_value) = $pair;
2012-01-08 19:25:01 +01:00
// NOTE: If we have \n in a header, SES rejects the email.
$header_value = str_replace("\n", " ", $header_value);
2011-01-26 02:40:21 +01:00
$mailer->addHeader($header_key, $header_value);
}
break;
case 'attachments':
$value = $this->getAttachments();
foreach ($value as $attachment) {
$mailer->addAttachment(
$attachment->getData(),
$attachment->getFilename(),
$attachment->getMimeType());
}
break;
2011-01-26 02:40:21 +01:00
case 'body':
$mailer->setBody($value);
break;
case 'subject':
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
// Only try to use preferences if everything is multiplexed, so we
// get consistent behavior.
$use_prefs = self::shouldMultiplexAllMail();
$prefs = null;
if ($use_prefs) {
// If multiplexing is enabled, some recipients will be in "Cc"
// rather than "To". We'll move them to "To" later (or supply a
// dummy "To") but need to look for the recipient in either the
// "To" or "Cc" fields here.
$target_phid = head(idx($params, 'to', array()));
if (!$target_phid) {
$target_phid = head(idx($params, 'cc', array()));
}
if ($target_phid) {
$user = id(new PhabricatorUser())->loadOneWhere(
'phid = %s',
$target_phid);
if ($user) {
$prefs = $user->loadPreferences();
}
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
}
}
$subject = array();
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
if ($is_threaded) {
$add_re = PhabricatorEnv::getEnvConfig('metamta.re-prefix');
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
if ($prefs) {
$add_re = $prefs->getPreference(
PhabricatorUserPreferences::PREFERENCE_RE_PREFIX,
$add_re);
}
if ($add_re) {
$subject[] = 'Re:';
}
}
$subject[] = trim(idx($params, 'subject-prefix'));
$vary_prefix = idx($params, 'vary-subject-prefix');
if ($vary_prefix != '') {
$use_subject = PhabricatorEnv::getEnvConfig(
'metamta.vary-subjects');
if ($prefs) {
$use_subject = $prefs->getPreference(
PhabricatorUserPreferences::PREFERENCE_VARY_SUBJECT,
$use_subject);
}
if ($use_subject) {
$subject[] = $vary_prefix;
}
}
$subject[] = $value;
$mailer->setSubject(implode(' ', array_filter($subject)));
2011-01-26 02:40:21 +01:00
break;
case 'is-html':
if ($value) {
$mailer->setIsHTML(true);
}
break;
case 'is-bulk':
if ($value) {
if (PhabricatorEnv::getEnvConfig('metamta.precedence-bulk')) {
$mailer->addHeader('Precedence', 'bulk');
}
}
break;
case 'thread-id':
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
// NOTE: Gmail freaks out about In-Reply-To and References which
// aren't in the form "<string@domain.tld>"; this is also required
// by RFC 2822, although some clients are more liberal in what they
// accept.
$domain = PhabricatorEnv::getEnvConfig('metamta.domain');
$value = '<'.$value.'@'.$domain.'>';
if ($is_first && $mailer->supportsMessageIDHeader()) {
$mailer->addHeader('Message-ID', $value);
} else {
$in_reply_to = $value;
$references = array($value);
$parent_id = $this->getParentMessageID();
if ($parent_id) {
$in_reply_to = $parent_id;
// By RFC 2822, the most immediate parent should appear last
// in the "References" header, so this order is intentional.
$references[] = $parent_id;
}
$references = implode(' ', $references);
$mailer->addHeader('In-Reply-To', $in_reply_to);
$mailer->addHeader('References', $references);
}
$thread_index = $this->generateThreadIndex($value, $is_first);
$mailer->addHeader('Thread-Index', $thread_index);
break;
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
case 'mailtags':
// Handled below.
break;
case 'subject-prefix':
case 'vary-subject-prefix':
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
// Handled above.
break;
2011-01-26 02:40:21 +01:00
default:
// Just discard.
}
}
if (!$add_to && !$add_cc) {
$this->setStatus(self::STATUS_VOID);
$this->setMessage(
"Message has no valid recipients: all To/CC are disabled or ".
"configured not to receive this mail.");
return $this->save();
}
$mailer->addHeader('X-Phabricator-Sent-This-Message', 'Yes');
2011-01-26 02:40:21 +01:00
$mailer->addHeader('X-Mail-Transport-Agent', 'MetaMTA');
// Some clients respect this to suppress OOF and other auto-responses.
$mailer->addHeader('X-Auto-Response-Suppress', 'All');
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
// If the message has mailtags, filter out any recipients who don't want
// to receive this type of mail.
$mailtags = $this->getParam('mailtags');
if ($mailtags) {
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
$tag_header = array();
foreach ($mailtags as $mailtag) {
$tag_header[] = '<'.$mailtag.'>';
}
$tag_header = implode(', ', $tag_header);
$mailer->addHeader('X-Phabricator-Mail-Tags', $tag_header);
}
// Some mailers require a valid "To:" in order to deliver mail. If we
// don't have any "To:", try to fill it in with a placeholder "To:".
// If that also fails, move the "Cc:" line to "To:".
if (!$add_to) {
$placeholder_key = 'metamta.placeholder-to-recipient';
$placeholder = PhabricatorEnv::getEnvConfig($placeholder_key);
if ($placeholder !== null) {
$add_to = array($placeholder);
} else {
$add_to = $add_cc;
$add_cc = array();
}
}
$mailer->addTos($add_to);
if ($add_cc) {
$mailer->addCCs($add_cc);
}
2011-01-26 02:40:21 +01:00
} catch (Exception $ex) {
$this->setStatus(self::STATUS_FAIL);
$this->setMessage($ex->getMessage());
return $this->save();
2011-01-26 02:40:21 +01:00
}
if ($this->getRetryCount() < $this->getSimulatedFailureCount()) {
$ok = false;
$error = 'Simulated failure.';
} else {
2011-01-26 18:33:31 +01:00
try {
$ok = $mailer->send();
$error = null;
2011-01-26 18:33:31 +01:00
} catch (Exception $ex) {
$ok = false;
$error = $ex->getMessage()."\n".$ex->getTraceAsString();
2011-01-26 18:33:31 +01:00
}
2011-01-26 02:40:21 +01:00
}
2011-01-26 18:08:26 +01:00
2011-01-26 02:40:21 +01:00
if (!$ok) {
$this->setMessage($error);
if ($this->getRetryCount() > self::MAX_RETRIES) {
$this->setStatus(self::STATUS_FAIL);
} else {
$this->setRetryCount($this->getRetryCount() + 1);
$next_retry = time() + ($this->getRetryCount() * self::RETRY_DELAY);
$this->setNextRetry($next_retry);
}
} else {
$this->setStatus(self::STATUS_SENT);
}
return $this->save();
2011-01-26 02:40:21 +01:00
}
public static function getReadableStatus($status_code) {
static $readable = array(
self::STATUS_QUEUE => "Queued for Delivery",
self::STATUS_FAIL => "Delivery Failed",
self::STATUS_SENT => "Sent",
self::STATUS_VOID => "Void",
2011-01-26 02:40:21 +01:00
);
$status_code = coalesce($status_code, '?');
return idx($readable, $status_code, $status_code);
}
private function generateThreadIndex($seed, $is_first_mail) {
// When threading, Outlook ignores the 'References' and 'In-Reply-To'
// headers that most clients use. Instead, it uses a custom 'Thread-Index'
// header. The format of this header is something like this (from
// camel-exchange-folder.c in Evolution Exchange):
/* A new post to a folder gets a 27-byte-long thread index. (The value
* is apparently unique but meaningless.) Each reply to a post gets a
* 32-byte-long thread index whose first 27 bytes are the same as the
* parent's thread index. Each reply to any of those gets a
* 37-byte-long thread index, etc. The Thread-Index header contains a
* base64 representation of this value.
*/
// The specific implementation uses a 27-byte header for the first email
// a recipient receives, and a random 5-byte suffix (32 bytes total)
// thereafter. This means that all the replies are (incorrectly) siblings,
// but it would be very difficult to keep track of the entire tree and this
// gets us reasonable client behavior.
$base = substr(md5($seed), 0, 27);
if (!$is_first_mail) {
// Not totally sure, but it seems like outlook orders replies by
// thread-index rather than timestamp, so to get these to show up in the
// right order we use the time as the last 4 bytes.
$base .= ' '.pack('N', time());
}
return base64_encode($base);
}
private function loadEmailAndNameDataFromPHIDs(array &$phids) {
$users = array();
$xusrs = array();
$mlsts = array();
// first iteration - group by types to do data fetches
foreach ($phids as $phid => $type) {
switch ($type) {
case PhabricatorPHIDConstants::PHID_TYPE_USER:
$users[] = $phid;
break;
case PhabricatorPHIDConstants::PHID_TYPE_XUSR:
$xusrs[] = $phid;
break;
case PhabricatorPHIDConstants::PHID_TYPE_MLST:
$mlsts[] = $phid;
break;
}
}
$user_emails = array();
if ($users) {
$user_emails = id(new PhabricatorUserEmail())->loadAllWhere(
'userPHID IN (%Ls) AND isPrimary = 1', $users);
$users = id(new PhabricatorUser())->loadAllWhere(
'phid IN (%Ls)', $users);
$user_emails = mpull($user_emails, null, 'getUserPHID');
$users = mpull($users, null, 'getPHID');
}
if ($xusrs) {
$xusrs = id(new PhabricatorExternalAccount())->loadAllWhere(
'phid IN (%Ls)', $xusrs);
$xusrs = mpull($xusrs, null, 'getPHID');
}
if ($mlsts) {
$mlsts = id(new PhabricatorMetaMTAMailingList())->loadAllWhere(
'phid IN (%Ls)', $mlsts);
$mlsts = mpull($mlsts, null, 'getPHID');
}
// second iteration - create entries for each phid
$default = PhabricatorEnv::getEnvConfig('metamta.default-address');
foreach ($phids as $phid => &$value) {
$name = '';
$email = $default;
$is_mailable = false;
switch ($value) {
case PhabricatorPHIDConstants::PHID_TYPE_USER:
$user = idx($users, $phid);
if ($user) {
$name = $this->getUserName($user);
$is_mailable = !$user->getIsDisabled()
&& !$user->getIsSystemAgent();
}
$email = isset($user_emails[$phid]) ?
$user_emails[$phid]->getAddress() :
$default;
break;
case PhabricatorPHIDConstants::PHID_TYPE_XUSR:
$xusr = $xusrs[$phid];
if ($xusr) {
$name = $xusr->getDisplayName();
$email = $xusr->getAccountID();
$accountType = $xusr->getAccountType();
if ($accountType == 'email') {
$is_mailable = true;
}
}
break;
case PhabricatorPHIDConstants::PHID_TYPE_MLST:
$mlst = $mlsts[$phid];
if ($mlst) {
$name = $mlst->getName();
$email = $mlst->getEmail();
$is_mailable = true;
}
break;
}
$value = array(
'name' => $name,
'email' => $email,
'mailable' => $is_mailable,
);
}
}
/**
* Small helper function to make sure we format the username properly as
* specified by the `metamta.user-address-format` configuration value.
*/
private function getUserName($user) {
$format = PhabricatorEnv::getEnvConfig('metamta.user-address-format');
switch ($format) {
case 'short':
$name = $user->getUserName();
break;
case 'real':
$name = $user->getRealName();
break;
case 'full':
default:
$name = $user->getFullName();
break;
}
return $name;
}
private function filterSendable($value, $phids) {
$result = array();
foreach ($value as $phid) {
if (isset($phids[$phid]) && $phids[$phid]['mailable']) {
$result[$phid] = $phids[$phid]['email'];
}
}
return $result;
}
Fix various threading issues, particularly in Gmail Summary: - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance. - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works). - Add a preference to enable subject line variance. - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results. NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better. Test Plan: Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK? NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults. I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/ Reviewers: btrahan, vrana, jungejason, nh Reviewed By: btrahan CC: cpiro, 20after4, aran Maniphest Tasks: T1097, T847 Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
public static function shouldMultiplexAllMail() {
return PhabricatorEnv::getEnvConfig('metamta.one-mail-per-recipient');
}
/* -( Managing Recipients )------------------------------------------------ */
/**
* Get all of the recipients for this mail, after preference filters are
* applied. This list has all objects to whom delivery will be attempted, but
* does not exclude recipeints two whom delivery may be impossible.
*
* @return list<phid> A list of all recipients to whom delivery will be
* attempted.
* @task recipients
*/
public function buildRecipientList() {
return $this->resolveRecipients(
array_merge(
$this->getRawToPHIDs(),
$this->getRawCCPHIDs()));
}
/**
* Filter out duplicate, invalid, or excluded recipients from a PHID list.
*
* @param list<phid> Unfiltered recipients.
* @return list<phid> Filtered recipients.
*
* @task recipients
*/
private function resolveRecipients(array $phids) {
if (!$phids) {
return array();
}
$phids = array_fuse($phids);
// Exclude PHIDs explicitly marked for exclusion. We use this to prevent
// recipients of an accidental "Reply All" from receiving the followup
// mail from Phabricator.
$exclude = $this->getExcludeMailRecipientPHIDs();
$exclude = array_fill_keys($exclude, true);
$phids = array_diff_key($phids, $exclude);
// If the actor is a recipient and has configured their preferences not to
// send them mail about their own actions, drop them from the recipient
// list.
$from = $this->getParam('from');
if (isset($phids[$from])) {
$from_user = id(new PhabricatorUser())->loadOneWhere(
'phid = %s',
$from);
if ($from_user && !$this->getOverrideNoSelfMailPreference()) {
$pref_key = PhabricatorUserPreferences::PREFERENCE_NO_SELF_MAIL;
$exclude_self = $from_user
->loadPreferences()
->getPreference($pref_key);
if ($exclude_self) {
unset($phids[$from]);
}
}
}
// Exclude all recipients who have set preferences to not receive this type
// of email (for example, a user who says they don't want emails about task
// CC changes).
$tags = $this->getParam('mailtags');
if ($tags && $phids) {
$all_prefs = id(new PhabricatorUserPreferences())->loadAllWhere(
'userPHID in (%Ls)',
$phids);
$all_prefs = mpull($all_prefs, null, 'getUserPHID');
foreach ($phids as $phid) {
$prefs = idx($all_prefs, $phid);
if (!$prefs) {
continue;
}
$user_mailtags = $prefs->getPreference(
PhabricatorUserPreferences::PREFERENCE_MAILTAGS,
array());
// The user must have elected to receive mail for at least one
// of the mailtags.
$send = false;
foreach ($tags as $tag) {
if (idx($user_mailtags, $tag, true)) {
$send = true;
break;
}
}
if (!$send) {
unset($phids[$phid]);
}
}
}
return array_keys($phids);
}
/**
* @task recipients
*/
private function buildToList() {
return $this->resolveRecipients($this->getRawToPHIDs());
}
/**
* @task recipients
*/
private function buildCCList() {
return $this->resolveRecipients($this->getRawCCPHIDs());
}
/**
* @task recipients
*/
private function getRawToPHIDs() {
$to = $this->getParam('to', array());
return $this->filterRawPHIDList($to);
}
/**
* @task recipients
*/
private function getRawCCPHIDs() {
$cc = $this->getParam('cc', array());
return $this->filterRawPHIDList($cc);
}
/**
* @task recipients
*/
private function filterRawPHIDList(array $list) {
$list = array_filter($list);
$list = array_unique($list);
return array_values($list);
}
2011-01-26 02:40:21 +01:00
}