Summary of changes from January 14th, 2019 to January 18th, 2019.
| Codebase | Repository | {icon lock} | HEAD | Activity |
|----------|------------|--|------|----------|
| Phabricator | rP | | rPe6ca2b998 | 35 commits |
| Arcanist | rARC | | rARC25c23819 | 0 commits |
| libphutil | rPHU | | rPHU92413d0 | 5 commits |
| Instances (SAAS) | rSAAS | {icon lock} | rSAAS4624462 | 0 commits |
| Services (SAAS) | rSERVICES | {icon lock} | rSERVICES019a12a | 0 commits |
| Core (SAAS) | rCORE | {icon lock} | rCORE3b4f19c | 2 commits |
- These changes were promoted to `stable`.
General
=======
**Handling Inbound Mail**
When you send email to Phabricator, it now attempts to process the mail for each recipient in the "To" and "CC" headers. This means that you can CC an address like `bugs@` (instead of needing to put it in "To"), and also that you can send mail to multiple application addresses.
If you send mail to `bugs@` and `help@` and both are configured to create tasks, Phabricator will create two different tasks. This may or may not be very useful, but most closely aligns with apparent intent. (Likewise, an email to `bugs@` and an email to `paste@` will create one task and one paste, provided you've configured these addresses.)
**Generating Email Addresses**
When Phabricator sends mail that is not "From" a user, it generates a "From" address like `"Phabricator" <noreply@phabricator.example.com>`.
When Phabricator sends mail which has "CC" recipients but no "To" recipients, it generates a placeholder "To" address like `noreply@phabricator.example.com`. This means that client-side mail rules which depend on whether you were in the "To" line or "CC" line will behave consistently.
(Note that using the `X-Phabricator-To`, `X-Phabricator-CC`, and/or `X-Phabricator-Stamps` headers is a more reliable way to write client-side mail rules than using `To` or `CC`.)
Both the "From" and "Placeholder To" addresses are now generated from these sources, in order:
- by using the value provided in `metamta.default-address`; or
- by generating the address `noreply@<metamta.reply-handler-domain>`; or
- by generating the address `noreply@<phabricator.base-uri>`.
Ideally, these addresses should go to a real mailbox which just swallows the mail, so that Phabricator doesn't generate bounces when sending mail and users don't generate bounces if they "Reply" or "Reply All".
In most cases:
- If you've configured `metamta.reply-handler-domain`, you don't need to do anything else. Phabricator will automatically void the `noreply@` address.
- If you haven't configured `metamta.reply-handler-domain`, configure `metamta.default-address` to point at some valid mailbox (no one needs to read or see this mail, it just shouldn't bounce).
For many installs, no configuration changes will be required, but you may need to revisit your setup depending on exactly which options you have enabled.
**Special Rules**
These changes have some minor consequences which most users probably won't run into. New routing and processing rules are:
- Inbound mail to the generated addresses is never processed.
- Inbound mail to a set of reserved addresses (like `root@` and `ssladmin@`) is never processed.
- Inbound mail to a user address is never processed.
- If you try to create an application email address which hits any of these cases, you'll be rebuffed with a helpful error.
- Inbound mail which is not processed but which had at least one reserved recipient in the recipient list no longer generates a "nothing could process this mail" error reply. This is intended to avoid collateral damage from stray addresses in "Reply All".
**Welcome Mail / Auth Messages**
[{icon tint, color=sky}] You can now add a custom, ad-hoc message to "Welcome" mail sent from profile pages.
In {nav Auth > Customize Messages}, you can now configure default "Welcome Mail" and "Login Page" messages, which will appear in the respective locations during user onboarding.
Security
========
**LOAD DATA LOCAL INFILE**
See T13238. A MySQL server may ask a MySQL client for the content of any file on the client machine, and the client will happily hand it over under certain common configurations. This is not normally exploitable, but the existence of this capability is deeply concerning.
Phabricator now issues setup guidance suggesting you disable client support for divulging files and server support for accepting files.
Migrations
==========
| Migration | Risk | Duration | Notes |
|-----------|------|----------|-------|
| 20181228.auth.01.provider.sql | | 13 ms |
| 20181228.auth.02.xaction.sql | | 19 ms |
| 20181228.auth.03.name.sql | | 18 ms |
| 20190116.phortune.01.billing.sql | | 76 ms |
| 20190117.authmessage.01.message.sql | | 16 ms |
| 20190117.authmessage.02.xaction.sql | | 19 ms |
//"Duration" is the duration for this install, and may not be representative.//
Upgrading / Compatibility
=========================
Mail adapters have been rewritten. If you implement a custom mail adapter, it will need to be updated for the API changes (this is very unusual).
If you have custom mail receivers (this is very unusual) they'll need to be updated for the new "process-each-recipient" changes described above.
The `mailer` option and `encoding` option have been removed from the SMTP mailer. The `mailer` is now always treated as `smtp`. The `encoding` is always treated as `base64`.
The `encoding` option has been removed from the SES mailer. It is now always treated as `base64`.
The `api-user` option has been removed from the SendGrid mailer. The mailer now uses the v3 API. You may need to generate a new set of credentials if your current credentials are particularly ancient.
These configuration options have all been removed:
```
metamta.conpherence.subject-prefix
metamta.differential.subject-prefix
metamta.diffusion.subject-prefix
metamta.files.subject-prefix
metamta.legalpad.subject-prefix
metamta.macro.subject-prefix
metamta.maniphest.subject-prefix
metamta.package.subject-prefix
metamta.paste.subject-prefix
metamta.pholio.subject-prefix
metamta.phriction.subject-prefix
```
These options allowed you to customize part of the subject line of email sent by the respective applications. They are very old, rarely used, implemented inconsistently (not all applications or objects supported these options), not clearly valuable, and not how we'd implement the feature if we were approaching it today.
If you're sad to see these options go, you can use `translation.override` to accomplish the same goal. For example, this `translation.override` configuration will replace `[Paste]` with `[Glue]`:
```lang=json
{
"[Paste]": "[Glue]"
}
```
The `translation.override` option has some other problems (see T13055, for example) and may not be around forever (at least, in its current form), but it should work fine for the forseeable future.
(Note that the `X-Phabricator-Stamps` header with the `application(...)` stamp is a more reliable way to perform client-side mail routing than the `Subject` header. For example, users may name a file `My Favorite [Paste] [Maniphest] [Diff].mp3`. Mail about this file will proably be routed incorrectly with a `Subject` rule, but can be routed correctly with an `X-Phabricator-Stamps` rule.)
Minor / Internal
================
- `Filesystem::readRandomBytes()` now uses `random_bytes()` if available.
- We no longer automatically correct the spellling of workflow names which begin with `-`. For example, `bin/something --start` will not be automatically corrected into `bin/something restart`.
- [{icon tint, color=sky}] Burnup chart month number tooltips now use normal human conventions (1 = January, etc) instead of bizarre Javascript conventions (0 = January, etc).
- [{icon tint, color=sky}] You no longer need `CAN_EDIT` to watch or unwatch a project. This was a bug.
- Fixed a bug where mail that only has "CC" addresses would be improperly addressed.
- [{icon tint, color=sky}] Importing columns to an empty board which has milestones should now work correctly.
- [{icon tint, color=sky}] Phortune accounts now support a custom billing name and address which appear on invoices.
- Transaction summaries in HTML mail are now rendered as HTML.
- Merge mail should more reliably select `[Merged]` as a subject action.
- [{icon tint, color=sky}] Conduit call logs may now be exported from the UI. They also support date range filtering.
- [{icon tint, color=sky}] Password login attempts now hit a hard wall after a moderately large number of attempts from the same remote address within a relatively short period of time, whether CAPTCHAs are configured or not.
- [{icon tint, color=sky}] Welcome mail no longer tells users to "set a password" if the install doesn't use passwords.
//The [{icon tint, color=sky}] icon indicates a change backed by support mana.//