2019 Week 3 (Mid January)

Updated 2,117 Days AgoPublic

Actions

Summary of changes from January 14th, 2019 to January 18th, 2019.

• 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

[] You can now add a custom, ad-hoc message to "Welcome" mail sent from profile pages.

In 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

"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]:

{
  "[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.
• [] Burnup chart month number tooltips now use normal human conventions (1 = January, etc) instead of bizarre Javascript conventions (0 = January, etc).
• [] 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.
• [] Importing columns to an empty board which has milestones should now work correctly.
• [] 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.
• [] Conduit call logs may now be exported from the UI. They also support date range filtering.
• [] 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.
• [] Welcome mail no longer tells users to "set a password" if the install doesn't use passwords.

The [] icon indicates a change backed by support mana.