2011-01-25 17:40:21 -08:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
2012-10-22 16:25:43 -07:00
|
|
|
* @task recipients Managing Recipients
|
2011-01-25 17:40:21 -08:00
|
|
|
*/
|
2015-06-22 13:46:26 -07:00
|
|
|
final class PhabricatorMetaMTAMail
|
|
|
|
extends PhabricatorMetaMTADAO
|
|
|
|
implements PhabricatorPolicyInterface {
|
2011-01-25 17:40:21 -08:00
|
|
|
|
|
|
|
const RETRY_DELAY = 5;
|
|
|
|
|
2015-06-22 14:14:21 -07:00
|
|
|
protected $actorPHID;
|
2011-01-25 17:40:21 -08:00
|
|
|
protected $parameters;
|
|
|
|
protected $status;
|
|
|
|
protected $message;
|
|
|
|
protected $relatedPHID;
|
|
|
|
|
2014-02-01 14:35:55 -08:00
|
|
|
private $recipientExpansionMap;
|
2015-08-15 10:54:33 -07:00
|
|
|
private $routingMap;
|
2012-10-10 10:18:23 -07:00
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
public function __construct() {
|
|
|
|
|
2015-08-14 04:31:42 -07:00
|
|
|
$this->status = PhabricatorMailOutboundStatus::STATUS_QUEUE;
|
2015-06-23 12:55:44 -07:00
|
|
|
$this->parameters = array('sensitive' => true);
|
2011-01-25 17:40:21 -08:00
|
|
|
|
|
|
|
parent::__construct();
|
|
|
|
}
|
|
|
|
|
2015-01-14 06:47:05 +11:00
|
|
|
protected function getConfiguration() {
|
2011-01-25 17:40:21 -08:00
|
|
|
return array(
|
2015-06-22 13:46:26 -07:00
|
|
|
self::CONFIG_AUX_PHID => true,
|
2011-01-25 17:40:21 -08:00
|
|
|
self::CONFIG_SERIALIZATION => array(
|
|
|
|
'parameters' => self::SERIALIZATION_JSON,
|
|
|
|
),
|
2014-09-24 13:50:00 -07:00
|
|
|
self::CONFIG_COLUMN_SCHEMA => array(
|
2015-06-22 14:14:21 -07:00
|
|
|
'actorPHID' => 'phid?',
|
Fix almost all remaining schemata issues
Summary:
Ref T1191. This fixes nearly every remaining blocker for utf8mb4 -- primarily, overlong keys.
Remaining issue is https://secure.phabricator.com/T1191#77467
Test Plan: I'll annotate inline.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, hach-que
Maniphest Tasks: T6099, T6129, T6133, T6134, T6150, T6148, T6147, T6146, T6105, T1191
Differential Revision: https://secure.phabricator.com/D10601
2014-10-01 08:18:36 -07:00
|
|
|
'status' => 'text32',
|
2014-09-24 13:50:00 -07:00
|
|
|
'relatedPHID' => 'phid?',
|
2014-10-01 07:59:44 -07:00
|
|
|
|
|
|
|
// T6203/NULLABILITY
|
|
|
|
// This should just be empty if there's no body.
|
|
|
|
'message' => 'text?',
|
2014-09-24 13:50:00 -07:00
|
|
|
),
|
|
|
|
self::CONFIG_KEY_SCHEMA => array(
|
|
|
|
'status' => array(
|
|
|
|
'columns' => array('status'),
|
|
|
|
),
|
2015-06-22 14:14:21 -07:00
|
|
|
'key_actorPHID' => array(
|
|
|
|
'columns' => array('actorPHID'),
|
|
|
|
),
|
2014-09-24 13:50:00 -07:00
|
|
|
'relatedPHID' => array(
|
|
|
|
'columns' => array('relatedPHID'),
|
|
|
|
),
|
|
|
|
'key_created' => array(
|
|
|
|
'columns' => array('dateCreated'),
|
|
|
|
),
|
|
|
|
),
|
2011-01-25 17:40:21 -08:00
|
|
|
) + parent::getConfiguration();
|
|
|
|
}
|
|
|
|
|
2015-06-22 13:46:26 -07:00
|
|
|
public function generatePHID() {
|
|
|
|
return PhabricatorPHID::generateNewPHID(
|
|
|
|
PhabricatorMetaMTAMailPHIDType::TYPECONST);
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
protected function setParam($param, $value) {
|
|
|
|
$this->parameters[$param] = $value;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
protected function getParam($param, $default = null) {
|
|
|
|
return idx($this->parameters, $param, $default);
|
2011-01-25 17:40:21 -08: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-17 22:57:07 -08:00
|
|
|
/**
|
2015-06-08 09:54:53 +10:00
|
|
|
* These tags are used to allow users to opt out of receiving certain types
|
|
|
|
* of mail, like updates when a task's projects change.
|
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-17 22:57:07 -08:00
|
|
|
*
|
2015-06-08 09:54:53 +10:00
|
|
|
* @param list<const>
|
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-17 22:57:07 -08:00
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
public function setMailTags(array $tags) {
|
2013-09-25 11:16:55 -07:00
|
|
|
$this->setParam('mailtags', array_unique($tags));
|
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-17 22:57:07 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
public function getMailTags() {
|
|
|
|
return $this->getParam('mailtags', array());
|
|
|
|
}
|
|
|
|
|
2011-06-22 12:41:19 -07:00
|
|
|
/**
|
|
|
|
* 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-25 17:40:21 -08:00
|
|
|
public function getSubject() {
|
|
|
|
return $this->getParam('subject');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function addTos(array $phids) {
|
Better enforce uniqueness for email delivery
Summary:
@skrul reports receiving multiple copies of notification emails since
@hunterbridges configured some bizarre dystopian email replication factory on
their outbound route. Two fixes:
- Ensure "To" and "Cc" are unique. Email shouldn't be replicated for "To:
x@y.com, x@y.com" but it's silly that we do this.
- Remove "To" addresses from "Cc". Email shouldn't be replicated here either,
but we don't really lose anything by accommodating this.
Test Plan:
Sent a mail to the same to/cc, verified I was to'd only and not cc'd when the
mail was delivered.
@hunterbridges, can you apply this patch locally and verify it fixes the issue?
You can test by going to MetaMTA -> Send New Message and sending a message to
yourself as both To and CC.
Reviewed By: skrul
Reviewers: skrul, hunterbridges, jungejason, tuomaspelkonen, aran
CC: aran, skrul, epriestley
Differential Revision: 751
2011-07-31 11:54:50 -07:00
|
|
|
$phids = array_unique($phids);
|
2011-01-25 17:40:21 -08:00
|
|
|
$this->setParam('to', $phids);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-05-07 10:29:33 -07:00
|
|
|
public function addRawTos(array $raw_email) {
|
2014-08-12 12:27:13 -07:00
|
|
|
|
|
|
|
// Strip addresses down to bare emails, since the MailAdapter API currently
|
|
|
|
// requires we pass it just the address (like `alincoln@logcabin.org`), not
|
|
|
|
// a full string like `"Abraham Lincoln" <alincoln@logcabin.org>`.
|
|
|
|
foreach ($raw_email as $key => $email) {
|
|
|
|
$object = new PhutilEmailAddress($email);
|
|
|
|
$raw_email[$key] = $object->getAddress();
|
|
|
|
}
|
|
|
|
|
2012-05-07 10:29:33 -07:00
|
|
|
$this->setParam('raw-to', $raw_email);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
public function addCCs(array $phids) {
|
Better enforce uniqueness for email delivery
Summary:
@skrul reports receiving multiple copies of notification emails since
@hunterbridges configured some bizarre dystopian email replication factory on
their outbound route. Two fixes:
- Ensure "To" and "Cc" are unique. Email shouldn't be replicated for "To:
x@y.com, x@y.com" but it's silly that we do this.
- Remove "To" addresses from "Cc". Email shouldn't be replicated here either,
but we don't really lose anything by accommodating this.
Test Plan:
Sent a mail to the same to/cc, verified I was to'd only and not cc'd when the
mail was delivered.
@hunterbridges, can you apply this patch locally and verify it fixes the issue?
You can test by going to MetaMTA -> Send New Message and sending a message to
yourself as both To and CC.
Reviewed By: skrul
Reviewers: skrul, hunterbridges, jungejason, tuomaspelkonen, aran
CC: aran, skrul, epriestley
Differential Revision: 751
2011-07-31 11:54:50 -07:00
|
|
|
$phids = array_unique($phids);
|
2011-01-25 17:40:21 -08:00
|
|
|
$this->setParam('cc', $phids);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-08-12 12:28:07 -07:00
|
|
|
public function setExcludeMailRecipientPHIDs(array $exclude) {
|
|
|
|
$this->setParam('exclude', $exclude);
|
2012-10-10 10:18:23 -07:00
|
|
|
return $this;
|
|
|
|
}
|
2013-03-20 15:50:02 -07:00
|
|
|
|
2014-08-12 12:28:07 -07:00
|
|
|
private function getExcludeMailRecipientPHIDs() {
|
|
|
|
return $this->getParam('exclude', array());
|
2013-03-20 15:50:02 -07:00
|
|
|
}
|
|
|
|
|
2015-04-06 10:01:32 -07:00
|
|
|
public function setForceHeraldMailRecipientPHIDs(array $force) {
|
|
|
|
$this->setParam('herald-force-recipients', $force);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getForceHeraldMailRecipientPHIDs() {
|
|
|
|
return $this->getParam('herald-force-recipients', array());
|
|
|
|
}
|
|
|
|
|
2012-06-15 23:21:25 -07:00
|
|
|
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;
|
|
|
|
}
|
2012-07-02 07:17:56 -07:00
|
|
|
|
|
|
|
if (!$return) {
|
|
|
|
$return = $default_translation;
|
|
|
|
}
|
|
|
|
|
2012-06-15 23:21:25 -07:00
|
|
|
return $return;
|
|
|
|
}
|
|
|
|
|
2012-06-21 18:39:35 -07:00
|
|
|
public function addPHIDHeaders($name, array $phids) {
|
2015-06-08 10:50:13 -07:00
|
|
|
$phids = array_unique($phids);
|
2012-06-21 18:39:35 -07:00
|
|
|
foreach ($phids as $phid) {
|
|
|
|
$this->addHeader($name, '<'.$phid.'>');
|
|
|
|
}
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
public function addHeader($name, $value) {
|
2012-06-21 18:39:35 -07:00
|
|
|
$this->parameters['headers'][] = array($name, $value);
|
2011-01-25 17:40:21 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-11-08 15:15:44 -08:00
|
|
|
public function addAttachment(PhabricatorMetaMTAAttachment $attachment) {
|
2013-03-30 15:53:49 -07:00
|
|
|
$this->parameters['attachments'][] = $attachment->toDictionary();
|
2011-11-08 15:15:44 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getAttachments() {
|
2013-03-30 15:53:49 -07:00
|
|
|
$dicts = $this->getParam('attachments');
|
|
|
|
|
|
|
|
$result = array();
|
|
|
|
foreach ($dicts as $dict) {
|
|
|
|
$result[] = PhabricatorMetaMTAAttachment::newFromDictionary($dict);
|
|
|
|
}
|
|
|
|
return $result;
|
2011-11-08 15:15:44 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
public function setAttachments(array $attachments) {
|
2012-04-03 12:10:45 -07:00
|
|
|
assert_instances_of($attachments, 'PhabricatorMetaMTAAttachment');
|
2013-03-30 15:53:49 -07:00
|
|
|
$this->setParam('attachments', mpull($attachments, 'toDictionary'));
|
2011-10-14 12:07:29 -07:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
public function setFrom($from) {
|
|
|
|
$this->setParam('from', $from);
|
2015-06-22 14:14:21 -07:00
|
|
|
$this->setActorPHID($from);
|
2011-01-25 17:40:21 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2015-06-22 14:14:21 -07:00
|
|
|
public function getFrom() {
|
|
|
|
return $this->getParam('from');
|
|
|
|
}
|
|
|
|
|
2015-03-17 14:43:21 -07:00
|
|
|
public function setRawFrom($raw_email, $raw_name) {
|
|
|
|
$this->setParam('raw-from', array($raw_email, $raw_name));
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-26 09:08:26 -08:00
|
|
|
public function setReplyTo($reply_to) {
|
|
|
|
$this->setParam('reply-to', $reply_to);
|
2011-01-25 17:40:21 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setSubject($subject) {
|
|
|
|
$this->setParam('subject', $subject);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-06-11 12:21:37 -07:00
|
|
|
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 09:31:03 -07:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
public function setBody($body) {
|
|
|
|
$this->setParam('body', $body);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2015-06-23 12:55:44 -07:00
|
|
|
public function setSensitiveContent($bool) {
|
|
|
|
$this->setParam('sensitive', $bool);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasSensitiveContent() {
|
|
|
|
return $this->getParam('sensitive', true);
|
|
|
|
}
|
|
|
|
|
2014-08-15 08:04:10 -07:00
|
|
|
public function setHTMLBody($html) {
|
|
|
|
$this->setParam('html-body', $html);
|
|
|
|
return $this;
|
2011-05-11 20:32:30 -07:00
|
|
|
}
|
|
|
|
|
2014-08-15 08:04:10 -07:00
|
|
|
public function getBody() {
|
|
|
|
return $this->getParam('body');
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|
|
|
|
|
2014-08-15 11:07:33 -07:00
|
|
|
public function getHTMLBody() {
|
|
|
|
return $this->getParam('html-body');
|
|
|
|
}
|
|
|
|
|
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
|
|
|
public function setIsErrorEmail($is_error) {
|
|
|
|
$this->setParam('is-error', $is_error);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getIsErrorEmail() {
|
|
|
|
return $this->getParam('is-error', false);
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
public function getToPHIDs() {
|
|
|
|
return $this->getParam('to', array());
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getRawToAddresses() {
|
|
|
|
return $this->getParam('raw-to', array());
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getCcPHIDs() {
|
|
|
|
return $this->getParam('cc', array());
|
|
|
|
}
|
|
|
|
|
2014-08-12 12:28:29 -07:00
|
|
|
/**
|
|
|
|
* Force delivery of a message, even if recipients have preferences which
|
|
|
|
* would otherwise drop the message.
|
|
|
|
*
|
|
|
|
* This is primarily intended to let users who don't want any email still
|
|
|
|
* receive things like password resets.
|
|
|
|
*
|
|
|
|
* @param bool True to force delivery despite user preferences.
|
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
public function setForceDelivery($force) {
|
|
|
|
$this->setParam('force', $force);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getForceDelivery() {
|
|
|
|
return $this->getParam('force', false);
|
|
|
|
}
|
|
|
|
|
2011-10-23 12:07:37 -07:00
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
2011-04-30 22:51:25 -07:00
|
|
|
/**
|
2014-01-14 13:22:47 -08:00
|
|
|
* Save a newly created mail to the database. The mail will eventually be
|
|
|
|
* delivered by the MetaMTA daemon.
|
2011-04-30 22:51:25 -07:00
|
|
|
*
|
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
public function saveAndSend() {
|
2014-01-14 13:22:47 -08:00
|
|
|
return $this->save();
|
2011-01-31 21:13:38 -08:00
|
|
|
}
|
2011-02-01 15:52:04 -08:00
|
|
|
|
2014-04-17 16:04:14 -07:00
|
|
|
public function save() {
|
|
|
|
if ($this->getID()) {
|
|
|
|
return parent::save();
|
|
|
|
}
|
|
|
|
|
|
|
|
// NOTE: When mail is sent from CLI scripts that run tasks in-process, we
|
|
|
|
// may re-enter this method from within scheduleTask(). The implementation
|
|
|
|
// is intended to avoid anything awkward if we end up reentering this
|
|
|
|
// method.
|
2012-02-27 17:11:25 -08:00
|
|
|
|
2014-04-17 16:04:14 -07:00
|
|
|
$this->openTransaction();
|
2015-06-23 11:37:14 -07:00
|
|
|
// Save to generate a mail ID and PHID.
|
2014-04-21 15:45:29 -07:00
|
|
|
$result = parent::save();
|
2014-04-17 16:04:14 -07:00
|
|
|
|
2015-06-23 11:37:14 -07:00
|
|
|
// Write the recipient edges.
|
|
|
|
$editor = new PhabricatorEdgeEditor();
|
|
|
|
$edge_type = PhabricatorMetaMTAMailHasRecipientEdgeType::EDGECONST;
|
2015-06-23 12:55:44 -07:00
|
|
|
$recipient_phids = array_merge(
|
|
|
|
$this->getToPHIDs(),
|
|
|
|
$this->getCcPHIDs());
|
|
|
|
$expanded_phids = $this->expandRecipients($recipient_phids);
|
|
|
|
$all_phids = array_unique(array_merge(
|
|
|
|
$recipient_phids,
|
|
|
|
$expanded_phids));
|
|
|
|
foreach ($all_phids as $curr_phid) {
|
|
|
|
$editor->addEdge($this->getPHID(), $edge_type, $curr_phid);
|
2015-06-23 11:37:14 -07:00
|
|
|
}
|
|
|
|
$editor->save();
|
|
|
|
|
2014-04-17 16:04:14 -07:00
|
|
|
// Queue a task to send this mail.
|
2012-10-31 15:22:16 -07:00
|
|
|
$mailer_task = PhabricatorWorker::scheduleTask(
|
|
|
|
'PhabricatorMetaMTAWorker',
|
2014-07-12 03:02:06 +10:00
|
|
|
$this->getID(),
|
2014-12-23 16:30:05 -08:00
|
|
|
array(
|
|
|
|
'priority' => PhabricatorWorker::PRIORITY_ALERTS,
|
|
|
|
));
|
2012-10-31 15:22:16 -07:00
|
|
|
|
2014-04-17 16:04:14 -07:00
|
|
|
$this->saveTransaction();
|
2012-02-27 17:11:25 -08:00
|
|
|
|
2014-04-17 16:04:14 -07:00
|
|
|
return $result;
|
|
|
|
}
|
2011-04-30 22:51:25 -07:00
|
|
|
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
public function buildDefaultMailer() {
|
2012-03-21 14:48:58 -07:00
|
|
|
return PhabricatorEnv::newObjectFromConfig('metamta.mail-adapter');
|
2011-02-09 17:39:55 -08:00
|
|
|
}
|
2011-01-25 17:40:21 -08:00
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07: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 09:08:26 -08:00
|
|
|
public function sendNow(
|
|
|
|
$force_send = false,
|
2011-02-09 17:39:55 -08:00
|
|
|
PhabricatorMailImplementationAdapter $mailer = null) {
|
|
|
|
|
|
|
|
if ($mailer === null) {
|
|
|
|
$mailer = $this->buildDefaultMailer();
|
|
|
|
}
|
2011-01-25 17:40:21 -08:00
|
|
|
|
|
|
|
if (!$force_send) {
|
2015-08-14 04:31:42 -07:00
|
|
|
if ($this->getStatus() != PhabricatorMailOutboundStatus::STATUS_QUEUE) {
|
2015-05-22 17:27:56 +10:00
|
|
|
throw new Exception(pht('Trying to send an already-sent mail!'));
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|
|
|
|
}
|
2011-02-01 15:52:04 -08:00
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
try {
|
2015-08-12 12:27:31 -07:00
|
|
|
$headers = $this->generateHeaders();
|
|
|
|
|
2012-10-23 10:48:03 -07:00
|
|
|
$params = $this->parameters;
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
$actors = $this->loadAllActors();
|
|
|
|
$deliverable_actors = $this->filterDeliverableActors($actors);
|
2011-02-01 15:52:04 -08:00
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
$default_from = PhabricatorEnv::getEnvConfig('metamta.default-address');
|
2011-02-09 11:11:24 -08:00
|
|
|
if (empty($params['from'])) {
|
2013-07-10 15:17:38 -07:00
|
|
|
$mailer->setFrom($default_from);
|
2011-02-09 11:11:24 -08:00
|
|
|
}
|
2011-02-01 15:52:04 -08:00
|
|
|
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08:00
|
|
|
$is_first = idx($params, 'is-first-message');
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
unset($params['is-first-message']);
|
|
|
|
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08:00
|
|
|
$is_threaded = (bool)idx($params, 'thread-id');
|
|
|
|
|
2011-05-06 16:35:59 -07:00
|
|
|
$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-17 22:57:07 -08:00
|
|
|
$add_cc = array();
|
|
|
|
$add_to = array();
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08:00
|
|
|
|
2014-08-15 08:04:10 -07: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();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-09 11:11:24 -08:00
|
|
|
foreach ($params as $key => $value) {
|
2011-01-25 17:40:21 -08:00
|
|
|
switch ($key) {
|
2015-03-17 14:43:21 -07:00
|
|
|
case 'raw-from':
|
|
|
|
list($from_email, $from_name) = $value;
|
|
|
|
$mailer->setFrom($from_email, $from_name);
|
|
|
|
break;
|
2011-01-25 17:40:21 -08:00
|
|
|
case 'from':
|
2013-07-10 15:17:38 -07:00
|
|
|
$from = $value;
|
2013-10-10 15:17:37 -07:00
|
|
|
$actor_email = null;
|
|
|
|
$actor_name = null;
|
|
|
|
$actor = idx($actors, $from);
|
|
|
|
if ($actor) {
|
|
|
|
$actor_email = $actor->getEmailAddress();
|
|
|
|
$actor_name = $actor->getName();
|
|
|
|
}
|
2013-07-10 15:17:38 -07:00
|
|
|
$can_send_as_user = $actor_email &&
|
|
|
|
PhabricatorEnv::getEnvConfig('metamta.can-send-as-user');
|
|
|
|
|
|
|
|
if ($can_send_as_user) {
|
2014-04-03 17:51:23 -07:00
|
|
|
$mailer->setFrom($actor_email, $actor_name);
|
2013-07-10 15:17:38 -07:00
|
|
|
} else {
|
|
|
|
$from_email = coalesce($actor_email, $default_from);
|
|
|
|
$from_name = coalesce($actor_name, pht('Phabricator'));
|
|
|
|
|
|
|
|
if (empty($params['reply-to'])) {
|
|
|
|
$params['reply-to'] = $from_email;
|
|
|
|
$params['reply-to-name'] = $from_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
$mailer->setFrom($default_from, $from_name);
|
|
|
|
}
|
2011-01-25 17:40:21 -08:00
|
|
|
break;
|
|
|
|
case 'reply-to':
|
2011-05-06 16:35:59 -07:00
|
|
|
$mailer->addReplyTo($value, $reply_to_name);
|
2011-01-25 17:40:21 -08:00
|
|
|
break;
|
|
|
|
case 'to':
|
2014-02-01 14:35:55 -08:00
|
|
|
$to_phids = $this->expandRecipients($value);
|
|
|
|
$to_actors = array_select_keys($deliverable_actors, $to_phids);
|
2013-07-10 15:17:38 -07:00
|
|
|
$add_to = array_merge(
|
|
|
|
$add_to,
|
|
|
|
mpull($to_actors, 'getEmailAddress'));
|
2011-01-25 17:40:21 -08:00
|
|
|
break;
|
2012-05-07 10:29:33 -07:00
|
|
|
case 'raw-to':
|
|
|
|
$add_to = array_merge($add_to, $value);
|
|
|
|
break;
|
2011-01-25 17:40:21 -08:00
|
|
|
case 'cc':
|
2014-02-01 14:35:55 -08:00
|
|
|
$cc_phids = $this->expandRecipients($value);
|
|
|
|
$cc_actors = array_select_keys($deliverable_actors, $cc_phids);
|
2013-07-10 15:17:38 -07:00
|
|
|
$add_cc = array_merge(
|
|
|
|
$add_cc,
|
|
|
|
mpull($cc_actors, 'getEmailAddress'));
|
2011-01-25 17:40:21 -08:00
|
|
|
break;
|
2011-10-14 12:07:29 -07:00
|
|
|
case 'attachments':
|
2013-03-30 15:53:49 -07:00
|
|
|
$value = $this->getAttachments();
|
2011-10-14 12:07:29 -07:00
|
|
|
foreach ($value as $attachment) {
|
|
|
|
$mailer->addAttachment(
|
2011-11-08 15:15:44 -08:00
|
|
|
$attachment->getData(),
|
2012-01-16 23:05:44 -08:00
|
|
|
$attachment->getFilename(),
|
2013-02-19 13:33:10 -08:00
|
|
|
$attachment->getMimeType());
|
2011-10-14 12:07:29 -07:00
|
|
|
}
|
|
|
|
break;
|
2011-01-25 17:40:21 -08:00
|
|
|
case 'subject':
|
2012-06-11 12:21:37 -07: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 09:31:03 -07:00
|
|
|
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08: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 09:31:03 -07:00
|
|
|
if ($prefs) {
|
|
|
|
$add_re = $prefs->getPreference(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_RE_PREFIX,
|
|
|
|
$add_re);
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($add_re) {
|
2012-06-11 12:21:37 -07:00
|
|
|
$subject[] = 'Re:';
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-17 20:32:28 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-06-11 12:21:37 -07:00
|
|
|
$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-25 17:40:21 -08:00
|
|
|
break;
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
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 09:31:03 -07: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.'>';
|
|
|
|
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
if ($is_first && $mailer->supportsMessageIDHeader()) {
|
2015-08-12 12:27:31 -07:00
|
|
|
$headers[] = array('Message-ID', $value);
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
} else {
|
2011-06-22 12:41:19 -07:00
|
|
|
$in_reply_to = $value;
|
2011-06-22 15:37:30 -07:00
|
|
|
$references = array($value);
|
2011-06-22 12:41:19 -07:00
|
|
|
$parent_id = $this->getParentMessageID();
|
|
|
|
if ($parent_id) {
|
|
|
|
$in_reply_to = $parent_id;
|
2011-06-22 15:37:30 -07:00
|
|
|
// By RFC 2822, the most immediate parent should appear last
|
|
|
|
// in the "References" header, so this order is intentional.
|
|
|
|
$references[] = $parent_id;
|
2011-06-22 12:41:19 -07:00
|
|
|
}
|
2011-06-22 15:37:30 -07:00
|
|
|
$references = implode(' ', $references);
|
2015-08-12 12:27:31 -07:00
|
|
|
$headers[] = array('In-Reply-To', $in_reply_to);
|
|
|
|
$headers[] = array('References', $references);
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
}
|
|
|
|
$thread_index = $this->generateThreadIndex($value, $is_first);
|
2015-08-12 12:27:31 -07:00
|
|
|
$headers[] = array('Thread-Index', $thread_index);
|
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 09:31:03 -07:00
|
|
|
break;
|
2011-01-25 17:40:21 -08:00
|
|
|
default:
|
2015-08-12 12:27:31 -07:00
|
|
|
// Other parameters are handled elsewhere or are not relevant to
|
|
|
|
// constructing the message.
|
|
|
|
break;
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-15 08:04:10 -07:00
|
|
|
$body = idx($params, 'body', '');
|
|
|
|
$max = PhabricatorEnv::getEnvConfig('metamta.email-body-limit');
|
|
|
|
if (strlen($body) > $max) {
|
2014-08-29 15:15:13 -07:00
|
|
|
$body = id(new PhutilUTF8StringTruncator())
|
|
|
|
->setMaximumBytes($max)
|
|
|
|
->truncateString($body);
|
2014-08-15 08:04:10 -07:00
|
|
|
$body .= "\n";
|
|
|
|
$body .= pht('(This email was truncated at %d bytes.)', $max);
|
|
|
|
}
|
|
|
|
$mailer->setBody($body);
|
|
|
|
|
|
|
|
$html_emails = false;
|
|
|
|
if ($use_prefs && $prefs) {
|
|
|
|
$html_emails = $prefs->getPreference(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_HTML_EMAILS,
|
|
|
|
$html_emails);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($html_emails && isset($params['html-body'])) {
|
|
|
|
$mailer->setHTMLBody($params['html-body']);
|
|
|
|
}
|
|
|
|
|
2015-08-12 12:27:31 -07:00
|
|
|
// Pass the headers to the mailer, then save the state so we can show
|
|
|
|
// them in the web UI.
|
|
|
|
foreach ($headers as $header) {
|
|
|
|
list($header_key, $header_value) = $header;
|
|
|
|
$mailer->addHeader($header_key, $header_value);
|
|
|
|
}
|
|
|
|
$this->setParam('headers.sent', $headers);
|
|
|
|
|
|
|
|
// Save the final deliverability outcomes and reasoning so we can
|
|
|
|
// explain why things happened the way they did.
|
|
|
|
$actor_list = array();
|
|
|
|
foreach ($actors as $actor) {
|
|
|
|
$actor_list[$actor->getPHID()] = array(
|
|
|
|
'deliverable' => $actor->isDeliverable(),
|
|
|
|
'reasons' => $actor->getDeliverabilityReasons(),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
$this->setParam('actors.sent', $actor_list);
|
|
|
|
|
2015-08-15 10:54:33 -07:00
|
|
|
$this->setParam('routing.sent', $this->getParam('routing'));
|
|
|
|
$this->setParam('routingmap.sent', $this->getRoutingRuleMap());
|
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
if (!$add_to && !$add_cc) {
|
2015-08-14 04:31:42 -07:00
|
|
|
$this->setStatus(PhabricatorMailOutboundStatus::STATUS_VOID);
|
2012-10-22 16:25:43 -07:00
|
|
|
$this->setMessage(
|
2015-05-22 17:27:56 +10:00
|
|
|
pht(
|
|
|
|
'Message has no valid recipients: all To/Cc are disabled, '.
|
|
|
|
'invalid, or configured not to receive this mail.'));
|
2012-10-22 16:25:43 -07:00
|
|
|
return $this->save();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
if ($this->getIsErrorEmail()) {
|
|
|
|
$all_recipients = array_merge($add_to, $add_cc);
|
|
|
|
if ($this->shouldRateLimitMail($all_recipients)) {
|
2015-08-14 04:31:42 -07:00
|
|
|
$this->setStatus(PhabricatorMailOutboundStatus::STATUS_VOID);
|
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
|
|
|
$this->setMessage(
|
|
|
|
pht(
|
|
|
|
'This is an error email, but one or more recipients have '.
|
|
|
|
'exceeded the error email rate limit. Declining to deliver '.
|
|
|
|
'message.'));
|
|
|
|
return $this->save();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add "phabricator.silent" for stopping all outbound events from an install
Summary:
Ref T7522. This is mostly useful in the cluster, but could be useful for external installs too.
If you want to import an instance into a test/dry-run state (in the cluster, to test an import; in the general case, to do something like test new hardware or configuration), you currently risk spamming users with a lot of duplicate notifications. In particular, if Phabricator tracks remotes, both instances will continue importing commits and sending email about them. Both instances will try to publish to mirrors, too, which could be bad news, and both instances will try to update linked services.
Instead, provide a flag to let an instance run in "silent mode", which disables all outbound messaging and data.
We need to remember to support this flag on any new outbound channels, but we add about one of those per year so I think that's reasonable.
Test Plan:
- Flipped config.
- Saw it void email, feed and mirroring.
- Didn't test SMS since it's not really in use yet and not convenient to test.
- (Can you think of any publishing I missed?)
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7522
Differential Revision: https://secure.phabricator.com/D12109
2015-03-18 07:09:43 -07:00
|
|
|
if (PhabricatorEnv::getEnvConfig('phabricator.silent')) {
|
2015-08-14 04:31:42 -07:00
|
|
|
$this->setStatus(PhabricatorMailOutboundStatus::STATUS_VOID);
|
Add "phabricator.silent" for stopping all outbound events from an install
Summary:
Ref T7522. This is mostly useful in the cluster, but could be useful for external installs too.
If you want to import an instance into a test/dry-run state (in the cluster, to test an import; in the general case, to do something like test new hardware or configuration), you currently risk spamming users with a lot of duplicate notifications. In particular, if Phabricator tracks remotes, both instances will continue importing commits and sending email about them. Both instances will try to publish to mirrors, too, which could be bad news, and both instances will try to update linked services.
Instead, provide a flag to let an instance run in "silent mode", which disables all outbound messaging and data.
We need to remember to support this flag on any new outbound channels, but we add about one of those per year so I think that's reasonable.
Test Plan:
- Flipped config.
- Saw it void email, feed and mirroring.
- Didn't test SMS since it's not really in use yet and not convenient to test.
- (Can you think of any publishing I missed?)
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7522
Differential Revision: https://secure.phabricator.com/D12109
2015-03-18 07:09:43 -07:00
|
|
|
$this->setMessage(
|
|
|
|
pht(
|
2015-05-22 17:27:56 +10:00
|
|
|
'Phabricator is running in silent mode. See `%s` '.
|
|
|
|
'in the configuration to change this setting.',
|
|
|
|
'phabricator.silent'));
|
Add "phabricator.silent" for stopping all outbound events from an install
Summary:
Ref T7522. This is mostly useful in the cluster, but could be useful for external installs too.
If you want to import an instance into a test/dry-run state (in the cluster, to test an import; in the general case, to do something like test new hardware or configuration), you currently risk spamming users with a lot of duplicate notifications. In particular, if Phabricator tracks remotes, both instances will continue importing commits and sending email about them. Both instances will try to publish to mirrors, too, which could be bad news, and both instances will try to update linked services.
Instead, provide a flag to let an instance run in "silent mode", which disables all outbound messaging and data.
We need to remember to support this flag on any new outbound channels, but we add about one of those per year so I think that's reasonable.
Test Plan:
- Flipped config.
- Saw it void email, feed and mirroring.
- Didn't test SMS since it's not really in use yet and not convenient to test.
- (Can you think of any publishing I missed?)
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7522
Differential Revision: https://secure.phabricator.com/D12109
2015-03-18 07:09:43 -07:00
|
|
|
return $this->save();
|
|
|
|
}
|
|
|
|
|
2012-08-20 14:08:45 -07:00
|
|
|
// 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();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
$add_to = array_unique($add_to);
|
don't add email addresses to CC if they are already in TO
Summary:
Some mailers remove the duplicate entries themselves, but some (Mailgun) don't.
This affects installations with metamta.one-mail-per-recipient set to false, and will cause
- ugly looking "to" entries. Gmail, for example, collapses to+cc entries to one list, so you get something that looks like "to: me me john"
- It sometimes causes duplicate delivery of the same message when used in conjuction with Google Groups. I suspect that their message de-dup mechanism is confused by it (I fuzzed it directly with Mailgun, and saw the same message delivered twice - once directly through mailgun, and bounced again through Google Groups). This doesn't happen when the entries are not duplicated.
Test Plan: Created some tasks. Added subscribers. Things seem to work reasonably well.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D9978
2014-07-17 18:32:44 -07:00
|
|
|
$add_cc = array_diff(array_unique($add_cc), $add_to);
|
2013-07-10 15:17:38 -07:00
|
|
|
|
2012-08-20 14:08:45 -07:00
|
|
|
$mailer->addTos($add_to);
|
|
|
|
if ($add_cc) {
|
|
|
|
$mailer->addCCs($add_cc);
|
|
|
|
}
|
2011-01-25 17:40:21 -08:00
|
|
|
} catch (Exception $ex) {
|
2014-04-21 15:45:29 -07:00
|
|
|
$this
|
2015-08-14 04:31:42 -07:00
|
|
|
->setStatus(PhabricatorMailOutboundStatus::STATUS_FAIL)
|
2014-04-21 15:45:29 -07:00
|
|
|
->setMessage($ex->getMessage())
|
|
|
|
->save();
|
|
|
|
|
|
|
|
throw $ex;
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|
|
|
|
|
2014-02-01 14:35:42 -08:00
|
|
|
try {
|
|
|
|
$ok = $mailer->send();
|
2014-04-21 15:45:29 -07:00
|
|
|
if (!$ok) {
|
|
|
|
// TODO: At some point, we should clean this up and make all mailers
|
|
|
|
// throw.
|
|
|
|
throw new Exception(
|
|
|
|
pht('Mail adapter encountered an unexpected, unspecified failure.'));
|
|
|
|
}
|
|
|
|
|
2015-08-14 04:31:42 -07:00
|
|
|
$this->setStatus(PhabricatorMailOutboundStatus::STATUS_SENT);
|
2014-04-21 15:45:29 -07:00
|
|
|
$this->save();
|
|
|
|
|
|
|
|
return $this;
|
2014-02-01 14:35:42 -08:00
|
|
|
} catch (PhabricatorMetaMTAPermanentFailureException $ex) {
|
2014-04-21 15:45:29 -07:00
|
|
|
$this
|
2015-08-14 04:31:42 -07:00
|
|
|
->setStatus(PhabricatorMailOutboundStatus::STATUS_FAIL)
|
2014-04-21 15:45:29 -07:00
|
|
|
->setMessage($ex->getMessage())
|
|
|
|
->save();
|
|
|
|
|
|
|
|
throw $ex;
|
2014-02-01 14:35:42 -08:00
|
|
|
} catch (Exception $ex) {
|
2014-04-21 15:45:29 -07:00
|
|
|
$this
|
|
|
|
->setMessage($ex->getMessage()."\n".$ex->getTraceAsString())
|
|
|
|
->save();
|
2011-01-26 09:08:26 -08:00
|
|
|
|
2014-04-21 15:45:29 -07:00
|
|
|
throw $ex;
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 11:47:00 -07:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
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 09:31:03 -07:00
|
|
|
public static function shouldMultiplexAllMail() {
|
|
|
|
return PhabricatorEnv::getEnvConfig('metamta.one-mail-per-recipient');
|
|
|
|
}
|
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
|
|
|
|
/* -( Managing Recipients )------------------------------------------------ */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get all of the recipients for this mail, after preference filters are
|
2013-07-10 15:17:38 -07:00
|
|
|
* applied. This list has all objects to whom delivery will be attempted.
|
2012-10-22 16:25:43 -07:00
|
|
|
*
|
2015-03-24 12:47:38 -07:00
|
|
|
* Note that this expands recipients into their members, because delivery
|
|
|
|
* is never directly attempted to aggregate actors like projects.
|
|
|
|
*
|
2012-10-22 16:25:43 -07:00
|
|
|
* @return list<phid> A list of all recipients to whom delivery will be
|
|
|
|
* attempted.
|
|
|
|
* @task recipients
|
|
|
|
*/
|
|
|
|
public function buildRecipientList() {
|
2015-03-24 12:47:38 -07:00
|
|
|
$actors = $this->loadAllActors();
|
2013-07-10 15:17:38 -07:00
|
|
|
$actors = $this->filterDeliverableActors($actors);
|
|
|
|
return mpull($actors, 'getPHID');
|
2012-10-22 16:25:43 -07:00
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
public function loadAllActors() {
|
2015-06-23 11:37:14 -07:00
|
|
|
$actor_phids = $this->getExpandedRecipientPHIDs();
|
2013-07-10 15:17:38 -07:00
|
|
|
return $this->loadActors($actor_phids);
|
|
|
|
}
|
|
|
|
|
2015-06-23 11:37:14 -07:00
|
|
|
public function getExpandedRecipientPHIDs() {
|
|
|
|
$actor_phids = $this->getAllActorPHIDs();
|
|
|
|
return $this->expandRecipients($actor_phids);
|
|
|
|
}
|
|
|
|
|
2015-03-24 12:47:38 -07:00
|
|
|
private function getAllActorPHIDs() {
|
|
|
|
return array_merge(
|
|
|
|
array($this->getParam('from')),
|
|
|
|
$this->getToPHIDs(),
|
|
|
|
$this->getCcPHIDs());
|
2014-02-01 14:35:55 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Expand a list of recipient PHIDs (possibly including aggregate recipients
|
|
|
|
* like projects) into a deaggregated list of individual recipient PHIDs.
|
|
|
|
* For example, this will expand project PHIDs into a list of the project's
|
|
|
|
* members.
|
|
|
|
*
|
|
|
|
* @param list<phid> List of recipient PHIDs, possibly including aggregate
|
|
|
|
* recipients.
|
|
|
|
* @return list<phid> Deaggregated list of mailable recipients.
|
|
|
|
*/
|
|
|
|
private function expandRecipients(array $phids) {
|
|
|
|
if ($this->recipientExpansionMap === null) {
|
2015-03-24 12:47:38 -07:00
|
|
|
$all_phids = $this->getAllActorPHIDs();
|
|
|
|
$this->recipientExpansionMap = id(new PhabricatorMetaMTAMemberQuery())
|
|
|
|
->setViewer(PhabricatorUser::getOmnipotentUser())
|
|
|
|
->withPHIDs($all_phids)
|
|
|
|
->execute();
|
2014-02-01 14:35:55 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
$results = array();
|
|
|
|
foreach ($phids as $phid) {
|
2015-03-24 12:47:38 -07:00
|
|
|
foreach ($this->recipientExpansionMap[$phid] as $recipient_phid) {
|
|
|
|
$results[$recipient_phid] = $recipient_phid;
|
2014-02-01 14:35:55 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return array_keys($results);
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
private function filterDeliverableActors(array $actors) {
|
|
|
|
assert_instances_of($actors, 'PhabricatorMetaMTAActor');
|
|
|
|
$deliverable_actors = array();
|
|
|
|
foreach ($actors as $phid => $actor) {
|
|
|
|
if ($actor->isDeliverable()) {
|
|
|
|
$deliverable_actors[$phid] = $actor;
|
|
|
|
}
|
2013-01-08 10:39:49 -08:00
|
|
|
}
|
2013-07-10 15:17:38 -07:00
|
|
|
return $deliverable_actors;
|
|
|
|
}
|
2013-01-08 10:39:49 -08:00
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
private function loadActors(array $actor_phids) {
|
|
|
|
$actor_phids = array_filter($actor_phids);
|
|
|
|
$viewer = PhabricatorUser::getOmnipotentUser();
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
$actors = id(new PhabricatorMetaMTAActorQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withPHIDs($actor_phids)
|
|
|
|
->execute();
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
if (!$actors) {
|
|
|
|
return array();
|
|
|
|
}
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2014-08-12 12:28:29 -07:00
|
|
|
if ($this->getForceDelivery()) {
|
2015-04-06 10:01:32 -07:00
|
|
|
// If we're forcing delivery, skip all the opt-out checks. We don't
|
|
|
|
// bother annotating reasoning on the mail in this case because it should
|
|
|
|
// always be obvious why the mail hit this rule (e.g., it is a password
|
|
|
|
// reset mail).
|
2015-04-06 10:01:11 -07:00
|
|
|
foreach ($actors as $actor) {
|
|
|
|
$actor->setDeliverable(PhabricatorMetaMTAActor::REASON_FORCE);
|
|
|
|
}
|
2014-08-12 12:28:29 -07:00
|
|
|
return $actors;
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
// Exclude explicit recipients.
|
|
|
|
foreach ($this->getExcludeMailRecipientPHIDs() as $phid) {
|
|
|
|
$actor = idx($actors, $phid);
|
|
|
|
if (!$actor) {
|
|
|
|
continue;
|
|
|
|
}
|
2015-04-06 10:01:11 -07:00
|
|
|
$actor->setUndeliverable(PhabricatorMetaMTAActor::REASON_RESPONSE);
|
2013-07-10 15:17:38 -07:00
|
|
|
}
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2015-04-06 10:01:32 -07:00
|
|
|
// Before running more rules, save a list of the actors who were
|
|
|
|
// deliverable before we started running preference-based rules. This stops
|
|
|
|
// us from trying to send mail to disabled users just because a Herald rule
|
|
|
|
// added them, for example.
|
|
|
|
$deliverable = array();
|
|
|
|
foreach ($actors as $phid => $actor) {
|
|
|
|
if ($actor->isDeliverable()) {
|
|
|
|
$deliverable[] = $phid;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// For the rest of the rules, order matters. We're going to run all the
|
|
|
|
// possible rules in order from weakest to strongest, and let the strongest
|
|
|
|
// matching rule win. The weaker rules leave annotations behind which help
|
|
|
|
// users understand why the mail was routed the way it was.
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
// Exclude the actor if their preferences are set.
|
|
|
|
$from_phid = $this->getParam('from');
|
|
|
|
$from_actor = idx($actors, $from_phid);
|
|
|
|
if ($from_actor) {
|
|
|
|
$from_user = id(new PhabricatorPeopleQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withPHIDs(array($from_phid))
|
|
|
|
->execute();
|
|
|
|
$from_user = head($from_user);
|
2014-08-12 12:28:07 -07:00
|
|
|
if ($from_user) {
|
2012-10-22 16:25:43 -07:00
|
|
|
$pref_key = PhabricatorUserPreferences::PREFERENCE_NO_SELF_MAIL;
|
|
|
|
$exclude_self = $from_user
|
|
|
|
->loadPreferences()
|
|
|
|
->getPreference($pref_key);
|
|
|
|
if ($exclude_self) {
|
2015-04-06 10:01:11 -07:00
|
|
|
$from_actor->setUndeliverable(PhabricatorMetaMTAActor::REASON_SELF);
|
2012-10-22 16:25:43 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-12 12:28:29 -07:00
|
|
|
$all_prefs = id(new PhabricatorUserPreferences())->loadAllWhere(
|
|
|
|
'userPHID in (%Ls)',
|
|
|
|
$actor_phids);
|
|
|
|
$all_prefs = mpull($all_prefs, null, 'getUserPHID');
|
|
|
|
|
2014-08-12 12:29:03 -07:00
|
|
|
$value_email = PhabricatorUserPreferences::MAILTAG_PREFERENCE_EMAIL;
|
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
// 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');
|
2013-07-10 15:17:38 -07:00
|
|
|
if ($tags) {
|
|
|
|
foreach ($all_prefs as $phid => $prefs) {
|
2012-10-22 16:25:43 -07:00
|
|
|
$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) {
|
2014-08-12 12:29:03 -07:00
|
|
|
if (((int)idx($user_mailtags, $tag, $value_email)) == $value_email) {
|
2012-10-22 16:25:43 -07:00
|
|
|
$send = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$send) {
|
2013-07-10 15:17:38 -07:00
|
|
|
$actors[$phid]->setUndeliverable(
|
2015-04-06 10:01:11 -07:00
|
|
|
PhabricatorMetaMTAActor::REASON_MAILTAGS);
|
2012-10-22 16:25:43 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-15 10:54:33 -07:00
|
|
|
foreach ($deliverable as $phid) {
|
|
|
|
switch ($this->getRoutingRule($phid)) {
|
|
|
|
case PhabricatorMailRoutingRule::ROUTE_AS_NOTIFICATION:
|
|
|
|
$actors[$phid]->setUndeliverable(
|
|
|
|
PhabricatorMetaMTAActor::REASON_ROUTE_AS_NOTIFICATION);
|
|
|
|
break;
|
|
|
|
case PhabricatorMailRoutingRule::ROUTE_AS_MAIL:
|
|
|
|
$actors[$phid]->setDeliverable(
|
|
|
|
PhabricatorMetaMTAActor::REASON_ROUTE_AS_MAIL);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// No change.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-06 10:01:32 -07:00
|
|
|
// If recipients were initially deliverable and were added by "Send me an
|
|
|
|
// email" Herald rules, annotate them as such and make them deliverable
|
2015-08-15 10:54:33 -07:00
|
|
|
// again, overriding any changes made by the "self mail" and "mail tags"
|
2015-04-06 10:01:32 -07:00
|
|
|
// settings.
|
|
|
|
$force_recipients = $this->getForceHeraldMailRecipientPHIDs();
|
|
|
|
$force_recipients = array_fuse($force_recipients);
|
|
|
|
if ($force_recipients) {
|
|
|
|
foreach ($deliverable as $phid) {
|
|
|
|
if (isset($force_recipients[$phid])) {
|
|
|
|
$actors[$phid]->setDeliverable(
|
|
|
|
PhabricatorMetaMTAActor::REASON_FORCE_HERALD);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Exclude recipients who don't want any mail. This rule is very strong
|
|
|
|
// and runs last.
|
|
|
|
foreach ($all_prefs as $phid => $prefs) {
|
|
|
|
$exclude = $prefs->getPreference(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_NO_MAIL,
|
|
|
|
false);
|
|
|
|
if ($exclude) {
|
|
|
|
$actors[$phid]->setUndeliverable(
|
|
|
|
PhabricatorMetaMTAActor::REASON_MAIL_DISABLED);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:17:38 -07:00
|
|
|
return $actors;
|
2012-10-22 16:25:43 -07: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-03 18:43:18 -07:00
|
|
|
private function shouldRateLimitMail(array $all_recipients) {
|
|
|
|
try {
|
|
|
|
PhabricatorSystemActionEngine::willTakeAction(
|
|
|
|
$all_recipients,
|
|
|
|
new PhabricatorMetaMTAErrorMailAction(),
|
|
|
|
1);
|
|
|
|
return false;
|
|
|
|
} catch (PhabricatorSystemActionRateLimitException $ex) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-24 11:44:49 -07:00
|
|
|
public function delete() {
|
|
|
|
$this->openTransaction();
|
|
|
|
queryfx(
|
|
|
|
$this->establishConnection('w'),
|
|
|
|
'DELETE FROM %T WHERE src = %s AND type = %d',
|
|
|
|
PhabricatorEdgeConfig::TABLE_NAME_EDGE,
|
|
|
|
$this->getPHID(),
|
|
|
|
PhabricatorMetaMTAMailHasRecipientEdgeType::EDGECONST);
|
|
|
|
$ret = parent::delete();
|
|
|
|
$this->saveTransaction();
|
|
|
|
|
|
|
|
return $ret;
|
|
|
|
}
|
|
|
|
|
2015-08-12 12:27:31 -07:00
|
|
|
public function generateHeaders() {
|
|
|
|
$headers = array();
|
|
|
|
|
|
|
|
$headers[] = array('X-Phabricator-Sent-This-Message', 'Yes');
|
|
|
|
$headers[] = array('X-Mail-Transport-Agent', 'MetaMTA');
|
|
|
|
|
|
|
|
// Some clients respect this to suppress OOF and other auto-responses.
|
|
|
|
$headers[] = array('X-Auto-Response-Suppress', 'All');
|
|
|
|
|
|
|
|
// 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) {
|
|
|
|
$tag_header = array();
|
|
|
|
foreach ($mailtags as $mailtag) {
|
|
|
|
$tag_header[] = '<'.$mailtag.'>';
|
|
|
|
}
|
|
|
|
$tag_header = implode(', ', $tag_header);
|
|
|
|
$headers[] = array('X-Phabricator-Mail-Tags', $tag_header);
|
|
|
|
}
|
|
|
|
|
|
|
|
$value = $this->getParam('headers', array());
|
|
|
|
foreach ($value as $pair) {
|
|
|
|
list($header_key, $header_value) = $pair;
|
|
|
|
|
|
|
|
// NOTE: If we have \n in a header, SES rejects the email.
|
|
|
|
$header_value = str_replace("\n", ' ', $header_value);
|
|
|
|
$headers[] = array($header_key, $header_value);
|
|
|
|
}
|
|
|
|
|
|
|
|
$is_bulk = $this->getParam('is-bulk');
|
|
|
|
if ($is_bulk) {
|
|
|
|
$headers[] = array('Precedence', 'bulk');
|
|
|
|
}
|
|
|
|
|
|
|
|
return $headers;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDeliveredHeaders() {
|
|
|
|
return $this->getParam('headers.sent');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDeliveredActors() {
|
|
|
|
return $this->getParam('actors.sent');
|
|
|
|
}
|
|
|
|
|
2015-08-15 10:54:33 -07:00
|
|
|
public function getDeliveredRoutingRules() {
|
|
|
|
return $this->getParam('routing.sent');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDeliveredRoutingMap() {
|
|
|
|
return $this->getParam('routingmap.sent');
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Routing )------------------------------------------------------------ */
|
|
|
|
|
|
|
|
|
|
|
|
public function addRoutingRule($routing_rule, $phids, $reason_phid) {
|
|
|
|
$routing = $this->getParam('routing', array());
|
|
|
|
$routing[] = array(
|
|
|
|
'routingRule' => $routing_rule,
|
|
|
|
'phids' => $phids,
|
|
|
|
'reasonPHID' => $reason_phid,
|
|
|
|
);
|
|
|
|
$this->setParam('routing', $routing);
|
|
|
|
|
|
|
|
// Throw the routing map away so we rebuild it.
|
|
|
|
$this->routingMap = null;
|
|
|
|
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getRoutingRule($phid) {
|
|
|
|
$map = $this->getRoutingRuleMap();
|
|
|
|
|
|
|
|
$info = idx($map, $phid, idx($map, 'default'));
|
|
|
|
if ($info) {
|
|
|
|
return idx($info, 'rule');
|
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getRoutingRuleMap() {
|
|
|
|
if ($this->routingMap === null) {
|
|
|
|
$map = array();
|
|
|
|
|
|
|
|
$routing = $this->getParam('routing', array());
|
|
|
|
foreach ($routing as $route) {
|
|
|
|
$phids = $route['phids'];
|
|
|
|
if ($phids === null) {
|
|
|
|
$phids = array('default');
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($phids as $phid) {
|
|
|
|
$new_rule = $route['routingRule'];
|
|
|
|
|
|
|
|
$current_rule = idx($map, $phid);
|
|
|
|
if ($current_rule === null) {
|
|
|
|
$is_stronger = true;
|
|
|
|
} else {
|
|
|
|
$is_stronger = PhabricatorMailRoutingRule::isStrongerThan(
|
|
|
|
$new_rule,
|
|
|
|
$current_rule);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($is_stronger) {
|
|
|
|
$map[$phid] = array(
|
|
|
|
'rule' => $new_rule,
|
|
|
|
'reason' => $route['reasonPHID'],
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$this->routingMap = $map;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $this->routingMap;
|
|
|
|
}
|
|
|
|
|
2012-10-22 16:25:43 -07:00
|
|
|
|
2015-06-22 13:46:26 -07:00
|
|
|
/* -( PhabricatorPolicyInterface )----------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
|
|
|
return PhabricatorPolicies::POLICY_NOONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
|
2015-06-23 11:37:14 -07:00
|
|
|
$actor_phids = $this->getExpandedRecipientPHIDs();
|
2015-06-22 13:46:26 -07:00
|
|
|
return in_array($viewer->getPHID(), $actor_phids);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function describeAutomaticCapability($capability) {
|
|
|
|
return pht(
|
|
|
|
'The mail sender and message recipients can always see the mail.');
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-25 17:40:21 -08:00
|
|
|
}
|