phacility/phabricator · info · PhabricatorMetaMTAReceivedMailProcessingException

err:reserved-recipient

err:reserved-recipient

Error message

No application handled this mail. This mail was sent to a reserved recipient ("%s") so bounces are suppressed.

What it means

Thrown in PhabricatorMetaMTAReceivedMail::executeSend when no receiver (no application mail receiver) accepted the message AND the recipient list contained a reserved address such as noreply@. Normally that would bounce with 'no receivers', but a reserved recipient makes Phabricator silently drop the mail (STATUS_RESERVED) to avoid replying to From: noreply@phabricator and creating a mail storm. The comment is explicit: a reply-all that includes 'noreply@' should be dropped, not bounced.

Source

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

      if ($receiver_exception) {
        throw $receiver_exception;
      }


      if (!$any_accepted) {
        if ($reserved_recipient) {
          // If nothing accepted the mail, we normally raise an error to help
          // users who mistakenly send mail to "barges@" instead of "bugs@".

          // However, if the recipient list included a reserved recipient, we
          // don't bounce the mail with an error.

          // The intent here is that if a user does a "Reply All" and includes
          // "From: noreply@phabricator" in the receipient list, we just want
          // to drop the mail rather than send them an unhelpful bounce message.

          throw new PhabricatorMetaMTAReceivedMailProcessingException(
            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 {

View on GitHub (pinned to 5720a38cfe)

Solutions

No server-side fix is expected — this status is intentional drop-without-bounce; check the mail logs (MetaMTA > Received Mail) to confirm STATUS_RESERVED.
If you are the sender: reply only to the valid application address and remove noreply@ from the recipient list, then verify the application address is correct.
Admins: confirm the reserved-address config (e.g. 'metamta.reserved-names' style settings) matches the addresses Phabricator itself sends from, so loop protection stays effective.
If mail silently disappears and you expected a bounce, remember this exact code path is why: a reserved recipient suppresses the error email by design.

Example fix

// before: reply-all with a dead object address + noreply@
// To: barges@phabricator.example, noreply@phabricator.example
// -> no receiver accepts, reserved recipient present -> err:reserved-recipient (dropped, no bounce)

// after: send only to the correct application address
// To: bugs@phabricator.example

Defensive patterns

Strategy: try-catch

Try / catch

// When driving PhabricatorMetaMTAReceivedMail::processIncomingMail programmatically:
try {
  $received_mail->processIncomingMail($sender);
} catch (PhabricatorMetaMTAReceivedMailProcessingException $ex) {
  if ($ex->getStatusCode() === MetaMTAReceivedMailStatus::STATUS_RESERVED) {
    // expected drop: a reserved recipient was on the list and nothing accepted
    return; // do not retry, do not bounce
  }
  throw $ex;
}

Prevention

Send only to real application addresses; remove noreply@ and reserved addresses from recipient lists.
Check MetaMTA > Received Mail for STATUS_RESERVED rows when mail vanishes without a bounce — that is this branch by design.
Configure auto-responders to skip mail carrying X-Phabricator-Sent-This-Message.

When it happens

Trigger: loadAllReceivers()/processIncomingMail runs, $any_accepted stays false, and $reserved_recipient is non-null (a To/CC address matched a reserved list, e.g. the configured metamta noreply address). Typical: a user reply-all on a Phabricator notification that includes 'X-Phabricator-Sent-This-Message' mail from noreply@, where the object address itself is also wrong (typo'd or unknown), so nothing accepts it.

Common situations: Reply-all including noreply@ plus a misspelled application address (barges@ instead of bugs@); automated responders (out-of-office, ticketing systems) replying to Phabricator notifications; the object address having been retired after the thread started.

Related errors

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