phacility/phabricator · warning · PhabricatorMetaMTAReceivedMailProcessingException

err:no-receivers

err:no-receivers

Error message

This mail can not be processed because no application knows how to handle it. Check that the address you sent it to is correct.

What it means

The generic 'no receiver' failure in PhabricatorMetaMTAReceivedMail: a known, valid sender was resolved, some recipient address was non-reserved, but no application receiver claimed the mail (STATUS_NO_RECEIVERS). Unlike the reserved-recipient and unknown-sender branches, this one produces a bounce telling the user no application knows how to handle the message.

Source

Thrown at src/applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php:270

            MetaMTAReceivedMailStatus::STATUS_RESERVED,
            pht(
              'No application handled this mail. This mail was sent to a '.
              'reserved recipient ("%s") so bounces are suppressed.',
              (string)$reserved_recipient));
        } else if (!$sender) {
          // NOTE: Currently, we'll always drop this mail (since it's headed to
          // an unverified recipient). See T12237. These details are still
          // useful because they'll appear in the mail logs and Mail web UI.

          throw new PhabricatorMetaMTAReceivedMailProcessingException(
            MetaMTAReceivedMailStatus::STATUS_UNKNOWN_SENDER,
            pht(
              'This email was sent from an email address ("%s") that is not '.
              'associated with a registered user account. To interact via '.
              'email, add this address to your account.',
              (string)$this->newFromAddress()));
        } else {
          throw new PhabricatorMetaMTAReceivedMailProcessingException(
            MetaMTAReceivedMailStatus::STATUS_NO_RECEIVERS,
            pht(
              'This mail can not be processed because no application '.
              'knows how to handle it. Check that the address you sent it to '.
              'is correct.'));
        }
      }
    } catch (PhabricatorMetaMTAReceivedMailProcessingException $ex) {
      switch ($ex->getStatusCode()) {
        case MetaMTAReceivedMailStatus::STATUS_DUPLICATE:
        case MetaMTAReceivedMailStatus::STATUS_FROM_PHABRICATOR:
          // Don't send an error email back in these cases, since they're
          // very unlikely to be the sender's fault.
          break;
        case MetaMTAReceivedMailStatus::STATUS_RESERVED:
          // This probably is the sender's fault, but it's likely an accident
          // that we received the mail at all.
          break;

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Verify the exact recipient address against the application's configured address (Config > MetaMTA / application settings, e.g. 'metamta.maniphest.public-create-email').
  2. Check the mail actually reached Phabricator's inbound pipeline (MetaMTA > Received Mail) and inspect its To/CC headers for rewrites by your MTA or mailing list.
  3. Admins: confirm the relevant application receiver is enabled and its configured address prefix matches what users are told to use.
  4. Prefer replying to an existing notification (which carries a valid generated address) over hand-composing application addresses.

Example fix

// before: To: barges@phabricator.example (typo, no receiver matches)
// -> sender known, nothing accepts -> err:no-receivers (bounce)

// after: To: bugs@phabricator.example (the configured Maniphest address)
Defensive patterns

Strategy: validation

Validate before calling

// Before sending to an application address, confirm it matches a configured receiver:
$valid = PhabricatorEnv::getEnvConfig(
  'metamta.maniphest.public-create-email'); // example for Maniphest
if ($to_address !== $valid) {
  // wrong address: look up the application's real configured address first
}

Prevention

When it happens

Trigger: Receiver loop-over getToAddresses/getCCAddresses finds no matching application handler (no address matches any receiver pattern such asbugs@, D123+...@, or a user's personal mail handler) while $sender is non-null. Classic: a typo in the application address (barges@ vs bugs@), an application's address-format that no receiver is configured for, or handlers disabled for that application.

Common situations: Typo'd application alias; sending to a generic company address that is not routed to Phabricator; the intended application (e.g. Maniphest) no longer installed/receiving; address prefix configuration changed so old documented addresses no longer match receivers.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/e4cc4651d064cbd1. Report an issue: GitHub.