Page MenuHomestyx hydra
Files F1455565

No OneTemporary
Actions

View Options

diff --git a/src/docs/configuration/configuring_inbound_email.diviner b/src/docs/configuration/configuring_inbound_email.diviner
index 9caed4f899..a81bf03c96 100644
--- a/src/docs/configuration/configuring_inbound_email.diviner
+++ b/src/docs/configuration/configuring_inbound_email.diviner
@@ -1,230 +1,236 @@
@title Configuring Inbound Email
@group config
This document contains instructions for configuring inbound email, so users
may update Differential and Maniphest by replying to messages and create
Maniphest tasks via email.
= Preamble =
This can be extremely difficult to configure correctly. This is doubly true if
you use sendmail.
There are basically a few approaches available:
- Use SendGrid (<http://sendgrid.com/>), which is very easy but is not free.
- Run your own MTA, which can be quite harrowing to configure but is free.
- Tell the Phabricator devteam about another service you'd like support for,
this stuff is seriously terrible to configure on your own.
= Configuring Phabricator =
By default, Phabricator uses a "noreply@phabricator.example.com" email address
as the 'From' (configurable with ##metamta.default-address##) and sets
'Reply-To' to the user generating the email (e.g., by making a comment), if the
mail was generated by a user action. This means that users can reply (or
reply-all) to email to discuss changes, but the conversation won't be recorded
in Phabricator and users will not be able to take actions like claiming tasks or
requesting changes to revisions.
To change this behavior so that users can interact with objects in Phabricator
over email, set these configuration keys:
- ##metamta.differential.reply-handler-domain##: enables email replies for
Differential.
- ##metamta.maniphest.reply-handler-domain##: enables email replies for
Maniphest.
Set these keys to some domain which you configure according to the instructions
below, e.g. "##phabricator.example.com##". You can set these both to the same
domain, and will generally want to. Once you set these keys, emails will use a
'Reply-To' like "##T123+273+af310f9220ad@example.com##", which -- when
configured correctly, according to the instructions below -- will parse incoming
email and allow users to interact with Maniphest tasks and Differential
revisions over email.
If you don't want phabricator to take up an entire domain (or subdomain) you
can configure a general prefix so you can use a single mailbox to receive mail
on. To make use of this set ##metamta.single-reply-handler-prefix## to the
prefix of your choice, and phabricator will prepend this to the 'Reply-To'
mail address. This works because everything up to the first (optional) '+'
character in an email-address is considered the receiver, and everything
after is essentially "ignored".
You can also set up a task creation email address, like ##bugs@example.com##,
which will create a Maniphest task out of any email which is set to it. To do
this, set ##metamta.maniphest.public-create-email## in your configuration. This
has some mild security implications, see below.
= Security =
The email reply channel is "somewhat" authenticated. Each reply-to address is
unique to the recipient and includes a hash of user information and a unique
object ID, so it can only be used to update that object and only be used to act
on behalf of the recipient.
However, if an address is leaked (which is fairly easy -- for instance,
forwarding an email will leak a live reply address, or a user might take a
screenshot), //anyone// who can send mail to your reply-to domain may interact
with the object the email relates to as the user who leaked the mail. Because
the authentication around email has this weakness, some actions (like accepting
revisions) are not permitted over email.
This implementation is an attempt to balance utility and security, but makes
some sacrifices on both sides to achieve it because of the difficulty of
authenticating senders in the general case (e.g., where you are an open source
project and need to interact with users whose email accounts you have no control
over).
If you leak a bunch of reply-to addresses by accident, you can change
##phabricator.mail-key## in your configuration to invalidate all the old hashes.
You can also set ##metamta.public-replies##, which will change how Phabricator
delivers email. Instead of sending each recipient a unique mail with a personal
reply-to address, it will send a single email to everyone with a public reply-to
address. This decreases security because anyone who can spoof a "From" address
can act as another user, but increases convenience if you use mailing lists and,
practically, is a reasonable setting for many installs. The reply-to address
will still contain a hash unique to the object it represents, so users who have
not received an email about an object can not blindly interact with it.
If you enable ##metamta.maniphest.public-create-email##, that address also uses
the weaker "From" authentication mechanism.
NOTE: Phabricator does not currently attempt to verify "From" addresses because
this is technically complex, seems unreasonably difficult in the general case,
and no installs have had a need for it yet. If you have a specific case where a
reasonable mechanism exists to provide sender verification (e.g., DKIM
signatures are sufficient to authenticate the sender under your configuration,
or you are willing to require all users to sign their email), file a feature
request.
-= Testing =
+= Testing and Debugging Inbound Email =
-You can view a log of received mail by going to MetaMTA -> Received in the
-Phabricator web interface. This can help you determine if mail is being
-delivered to Phabricator or not.
+You can use the `bin/mail` utility to test and review inbound mail. This can
+help you determine if mail is being delivered to Phabricator or not:
-You can also use the "Test Receiver" button, but note that this just simulates
-receiving mail and doesn't send any information over the network. It is
+ phabricator/ $ ./bin/mail list-inbound # List inbound messages.
+ phabricator/ $ ./bin-mail show-inbound # Show details about a message.
+
+You can also test receiving mail, but note that this just simulates receiving
+the mail and doesn't send any information over the network. It is
primarily aimed at developing email handlers: it will still work properly
if your inbound email configuration is incorrect or even disabled.
+ phabricator/ $ ./bin/mail receive-test # Receive test message.
+
+Run `bin/mail help <command>` for detailed help on using these commands.
+
= SendGrid =
To use SendGrid, you need a SendGrid account with access to the "Parse API" for
inbound email. Provided you have such an account, configure it like this:
- Configure an MX record according to SendGrid's instructions, i.e. add
##phabricator.example.com MX 10 mx.sendgrid.net.## or similar.
- Go to the "Parse Incoming Emails" page on SendGrid
(<http://sendgrid.com/developer/reply>) and add the domain as the
"Hostname".
- Add the URL ##https://phabricator.example.com/mail/sendgrid/## as the "Url",
using your domain (and HTTP instead of HTTPS if you are not configured with
SSL).
- If you get an error that the hostname "can't be located or verified", it
means your MX record is either incorrectly configured or hasn't propagated
yet.
- Set ##metamta.maniphest.reply-handler-domain## and/or
##metamta.differential.reply-handler-domain## to
"##phabricator.example.com##" (whatever you configured the MX record for),
depending on whether you want to support email replies for Maniphest,
Differential, or both.
That's it! If everything is working properly you should be able to send email
to ##anything@phabricator.example.com## and it should appear in the "Received"
tab of MetaMTA within a few seconds.
= Installing Mailparse =
If you're going to run your own MTA, you need to install the PECL mailparse
extension. In theory, you can do that with:
$ sudo pecl install mailparse
You may run into an error like "needs mbstring". If so, try:
$ sudo yum install php-mbstring # or equivalent
$ sudo pecl install -n mailparse
If you get a linker error like this:
COUNTEREXAMPLE
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/modules/mailparse.so' - /usr/lib64/php/modules/mailparse.so:
undefined symbol: mbfl_name2no_encoding in Unknown on line 0
...you need to edit your php.ini file so that mbstring.so is loaded **before**
mailparse.so. This is not the default if you have individual files in
##php.d/##.
= MTA: Configuring Sendmail =
Before you can configure Sendmail, you need to install Mailparse. See the
section "Installing Mailparse" above.
Sendmail is very difficult to configure. First, you need to configure it for
your domain so that mail can be delivered correctly. In broad strokes, this
probably means something like this:
- add an MX record;
- make sendmail listen on external interfaces;
- open up port 25 if necessary (e.g., in your EC2 security policy);
- add your host to /etc/mail/local-host-names; and
- restart sendmail.
Now, you can actually configure sendmail to deliver to Phabricator. In
##/etc/aliases##, add an entry like this:
phabricator: "| /path/to/phabricator/scripts/mail/mail_handler.php <ENV>"
...where <ENV> is the PHABRICATOR_ENV the script should run under. Run
##sudo newaliases##. Now you likely need to symlink this script into
##/etc/smrsh/##:
sudo ln -s /path/to/phabricator/scripts/mail/mail_handler.php /etc/smrsh/
Finally, edit ##/etc/mail/virtusertable## and add an entry like this:
- @yourdomain.com phabricator@localhost
+ @yourdomain.com phabricator@localhost
That will forward all mail to @yourdomain.com to the Phabricator processing
script. Run ##sudo /etc/mail/make## or similar and then restart sendmail with
##sudo /etc/init.d/sendmail restart##.
= MTA: Configuring Lamson =
Before you can configure Lamson, you need to install Mailparse. See the section
"Installing Mailparse" above.
In contrast to Sendmail, Lamson is relatively easy to configure. It is fairly
minimal, and is suitable for a development or testing environment. Lamson
listens for incoming SMTP mails and passes the content directly to Phabricator.
To get started, follow the provided instructions
(<http://lamsonproject.org/docs/getting_started.html>) to set up an instance.
One likely deployment issue is that binding to port 25 requires root
privileges. Lamson is capable of starting as root then dropping privileges, but
you must supply ##-uid## and ##-gid## arguments to do so, as demonstrated by
Step 8 in Lamson's deployment tutorial (located here:
<http://lamsonproject.org/docs/deploying_oneshotblog.html>).
The Lamson handler code itself is very concise; it merely needs to pass the
content of the email to Phabricator:
import logging, subprocess
from lamson.routing import route, stateless
from lamson import view
PHABRICATOR_ROOT = "/path/to/phabricator"
PHABRICATOR_ENV = "custom/myconf"
LOGGING_ENABLED = True
@route("(address)@(host)", address=".+")
@stateless
def START(message, address=None, host=None):
if LOGGING_ENABLED:
logging.debug("%s", message.original)
process = subprocess.Popen([PHABRICATOR_ROOT + "scripts/mail/mail_handler.php",PHABRICATOR_ENV],stdin=subprocess.PIPE)
process.communicate(message.original)
diff --git a/src/docs/configuration/configuring_outbound_email.diviner b/src/docs/configuration/configuring_outbound_email.diviner
index c93b54b011..56a08eb006 100644
--- a/src/docs/configuration/configuring_outbound_email.diviner
+++ b/src/docs/configuration/configuring_outbound_email.diviner
@@ -1,188 +1,187 @@
@title Configuring Outbound Email
@group config
Instructions for configuring Phabricator to send mail.
= Overview =
Phabricator can send outbound email via several different adapters:
- by running ##sendmail## on the local host with SMTP; or
- by running postfix on the local host with SMTP; or
- by using Amazon SES (Simple Email Service); or
- by using SendGrid's REST API; or
- via a custom adapter you write; or
- by dropping email into a hole and not delivering it.
Of these, ##sendmail## is the default but requires some configuration. SES and
SendGrid are easier, but cost money and have some limitations. Writing a custom
solution requires digging into the code. See below for details on how to set up
each method.
Phabricator can also send outbound email in two ways:
- immediately, when messages are generated (default); or
- in the background, via a daemon.
Sending mail in the background requires that you be running the Phabricator
daemons, but can greatly improve the performance of the application if your mail
handler is slow. For more information on using daemons, see
@{article:Managing Daemons with phd}.
= Basics =
Regardless of how outbound email is delivered, you should configure these keys
in your configuration file:
- **metamta.default-address** determines where mail is sent "From" by
default. If your domain is ##example.org##, set this to something like
"##noreply@example.org##".
- **metamta.domain** should be set to your domain, e.g. "##example.org##".
- **metamta.can-send-as-user** should be left as ##false## in most cases,
but see the documentation in ##default.conf.php## for details.
= Configuring Mail Adapters =
To choose how mail will be sent, change the **metamta.mail-adapter** key in
your configuration. Possible values are:
- ##PhabricatorMailImplementationPHPMailerLiteAdapter##: default, uses
"sendmail", see "Adapter: Sendmail".
- ##PhabricatorMailImplementationPHPMailerAdapter##: uses SMTP, see
"Adapter: SMTP".
- ##PhabricatorMailImplementationAmazonSESAdapter##: use Amazon SES, see
"Adapter: Amazon SES".
- ##PhabricatorMailImplementationSendGridAdapter##: use SendGrid, see
"Adapter: SendGrid".
- ##Some Custom Class You Write##: use a custom adapter you write, see
"Adapter: Custom".
- ##PhabricatorMailImplementationTestAdapter##: this will
**completely disable** outbound mail. You can use this if you don't want to
send outbound mail, or want to skip this step for now and configure it
later.
= Adapter: Sendmail =
This is the default, and selected by choosing
##PhabricatorMailImplementationPHPMailerLiteAdapter## as the value for
**metamta.mail-adapter**. This requires a 'sendmail' binary to be installed on
the system. Most MTAs (e.g., sendmail, qmail, postfix) should do this, but your
machine may not have one installed by default. For install instructions, consult
the documentation for your favorite MTA.
Since you'll be sending the mail yourself, you are subject to things like SPF
rules, blackholes, and MTA configuration which are beyond the scope of this
document. If you can already send outbound email from the command line or know
how to configure it, this option is straightforward. If you have no idea how to
do any of this, consider using Amazon SES.
= Adapter: SMTP =
For most situations of using SMTP to send email, you could actually use
-'sendmail' or 'postfix' to do it. But some SMTP server requires authentication
-and the 'sendmail' mailer doesn't work. If you want to try with postfix, for install
-instructions, consult the documentation for postfix as MTA and you could configure
-to use SMTP then.
+'sendmail' or 'postfix' to do it. But some SMTP server requires authentication
+and the 'sendmail' mailer doesn't work. If you want to try with postfix, for
+install instructions, consult the documentation for postfix as MTA and you
+could configure to use SMTP then.
To configure Phabricator to use SMTP, set these configuration keys:
- **metamta.mail-adapter**: set to
"PhabricatorMailImplementationPHPMailerAdapter".
- **phpmailer.mailer**: set to "smtp".
- **phpmailer.smtp-host**: set to hostname of your smtp server.
- **phpmailer.smtp-port**: set to port of your smtp server.
- **phpmailer.smtp-user**: set to your username used for authentication.
- **phpmailer.smtp-password**: set to your password used for authentication.
= Adapter: Amazon SES =
Amazon SES is Amazon's cloud email service. It is not free, but is easier to
configure than sendmail and can simplify outbound email configuration. To use
Amazon SES, you need to sign up for an account with Amazon at
<http://aws.amazon.com/ses/>.
To configure Phabricator to use Amazon SES, set these configuration keys:
- **metamta.mail-adapter**: set to
"PhabricatorMailImplementationAmazonSESAdapter".
- **amazon-ses.access-key**: set to your Amazon SES access key.
- **amazon-ses.secret-key**: set to your Amazon SES secret key.
NOTE: Amazon SES **requires you to verify your "From" address**. Configure which
"From" address to use by setting "##metamta.default-address##" in your config,
then follow the Amazon SES verification process to verify it. You won't be able
to send email until you do this!
NOTE: Amazon SES is slow to accept mail (often 1-2 seconds) and application
performance will improve greatly if you configure outbound email to send in
the background.
= Adapter: SendGrid =
SendGrid is an email delivery service like Amazon SES. You can learn more at
<http://sendgrid.com/>. It is easy to configure, but not free.
You can configure SendGrid in two ways: you can send via SMTP or via the REST
API. To use SMTP, just configure ##sendmail## and leave Phabricator's setup
with defaults. To use the REST API, follow the instructions in this section.
To configure Phabricator to use SendGrid, set these configuration keys:
- **metamta.mail-adapter**: set to
"PhabricatorMailImplementationSendGridAdapter".
- **sendgrid.api-user**: set to your SendGrid login name.
- **sendgrid.api-key**: set to your SendGrid password.
If you're logged into your SendGrid account, you may be able to find this
information easily by visiting <http://sendgrid.com/developer>.
= Adapter: Custom =
You can provide a custom adapter by writing a concrete subclass of
@{class:PhabricatorMailImplementationAdapter} and setting it as the
**metamta.mail-adapter**.
TODO: This needs to be better documented once extending Phabricator is better
documented.
= Adapter: Disable Outbound Mail =
You can use the @{class:PhabricatorMailImplementationTestAdapter} to completely
disable outbound mail, if you don't want to send mail or don't want to configure
it yet. Just set **metamta.mail-adapter** to
"PhabricatorMailImplementationTestAdapter".
= Configuring MetaMTA to Send Mail Using a Daemon =
Regardless of how you are sending outbound email, you can move the handoff to
the MTA out of the main process and into a daemon. This will greatly improve
application performance if your mailer is slow, like Amazon SES. In particular,
commenting on Differential Revisions and Maniphest Tasks sends outbound email.
If you set **metamta.send-immediately** to ##false## in your configuration,
MetaMTA will queue mail to be send by a PhabricatorTaskmasterDaemon.
For more information on using daemons, see @{article:Managing Daemons with phd}.
= Testing and Debugging Outbound Email =
-Phabricator has a mail log and test console at ##/mail/##, or click the
-**MetaMTA** link from the homepage. This console shows all the mail Phabricator
-has attempted to deliver, plus debugging and error information.
+You can use the `bin/mail` utility to test, debug, and examine outbound mail. In
+particular:
-You can use the "Send New Message" button to send mail using the current
-configuration. This can help test that your setup is correct.
+ phabricator/ $ ./bin/mail list-outbound # List outbound mail.
+ phabricator/ $ ./bin/mail show-outbound # Show details about messages.
+ phabricator/ $ ./bin/mail send-test # Send test messages.
-NOTE: when you send mail, "to" and "cc" must be valid users of the system, not
-arbitrary email addresses.
+Run `bin/mail help <command>` for more help on using these commands.
You can monitor daemons using the Daemon Console (##/daemon/##, or click
**Daemon Console** from the homepage).
= Next Steps =
Continue by:
- @{article:Configuring Inbound Email} so users can reply to email they
receive about revisions and tasks to interact with them; or
- learning about daemons with @{article:Managing Daemons with phd}; or
- returning to the @{article:Configuration Guide}.

File Metadata

Mime Type
text/x-diff
Expires
Fri, Nov 14, 7:34 AM (1 d, 10 h)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
336867
Default Alt Text
(20 KB)

Event Timeline

styx copyright 2020 sirocyl / ellie (kymkdd) / ncommander / styx contributors
Use of other names and brands is not intended to reflect a claim of, or right to, use the name or brand.
styx is an operating system using the Linux kernel and components, and "styx Linux" as a phrase does not reflect the inclusion of the Linux brand or trademark in the styx project.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Terms and Conditions (TODO: fix this!)