{"record":{"id":"337a327f6bfed8a8","repo":"phacility/phabricator","slug":"err-reserved-recipient","errorCode":"err:reserved-recipient","errorMessage":"No application handled this mail. This mail was sent to a reserved recipient (\"%s\") so bounces are suppressed.","messagePattern":"No application handled this mail\\. This mail was sent to a reserved recipient \\(\"(.+?)\"\\) so bounces are suppressed\\.","errorType":"exception","errorClass":"PhabricatorMetaMTAReceivedMailProcessingException","httpStatus":null,"severity":"info","filePath":"src/applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php","lineNumber":251,"sourceCode":"\n      if ($receiver_exception) {\n        throw $receiver_exception;\n      }\n\n\n      if (!$any_accepted) {\n        if ($reserved_recipient) {\n          // If nothing accepted the mail, we normally raise an error to help\n          // users who mistakenly send mail to \"barges@\" instead of \"bugs@\".\n\n          // However, if the recipient list included a reserved recipient, we\n          // don't bounce the mail with an error.\n\n          // The intent here is that if a user does a \"Reply All\" and includes\n          // \"From: noreply@phabricator\" in the receipient list, we just want\n          // to drop the mail rather than send them an unhelpful bounce message.\n\n          throw new PhabricatorMetaMTAReceivedMailProcessingException(\n            MetaMTAReceivedMailStatus::STATUS_RESERVED,\n            pht(\n              'No application handled this mail. This mail was sent to a '.\n              'reserved recipient (\"%s\") so bounces are suppressed.',\n              (string)$reserved_recipient));\n        } else if (!$sender) {\n          // NOTE: Currently, we'll always drop this mail (since it's headed to\n          // an unverified recipient). See T12237. These details are still\n          // useful because they'll appear in the mail logs and Mail web UI.\n\n          throw new PhabricatorMetaMTAReceivedMailProcessingException(\n            MetaMTAReceivedMailStatus::STATUS_UNKNOWN_SENDER,\n            pht(\n              'This email was sent from an email address (\"%s\") that is not '.\n              'associated with a registered user account. To interact via '.\n              'email, add this address to your account.',\n              (string)$this->newFromAddress()));\n        } else {","sourceCodeStart":233,"sourceCodeEnd":269,"githubUrl":"https://github.com/phacility/phabricator/blob/5720a38cfe95b00ca4be5016dd0d2f3195f4fa04/src/applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php#L233-L269","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","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."],"exampleFix":"// before: reply-all with a dead object address + noreply@\n// To: barges@phabricator.example, noreply@phabricator.example\n// -> no receiver accepts, reserved recipient present -> err:reserved-recipient (dropped, no bounce)\n\n// after: send only to the correct application address\n// To: bugs@phabricator.example","handlingStrategy":"try-catch","validationCode":null,"typeGuard":null,"tryCatchPattern":"// When driving PhabricatorMetaMTAReceivedMail::processIncomingMail programmatically:\ntry {\n  $received_mail->processIncomingMail($sender);\n} catch (PhabricatorMetaMTAReceivedMailProcessingException $ex) {\n  if ($ex->getStatusCode() === MetaMTAReceivedMailStatus::STATUS_RESERVED) {\n    // expected drop: a reserved recipient was on the list and nothing accepted\n    return; // do not retry, do not bounce\n  }\n  throw $ex;\n}","preventionTips":["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."],"tags":["metamta","email","reserved-address","loop-prevention","silent-drop"],"backgroundTag":"mail-silently-dropped","analyzedSha":"5720a38cfe95b00ca4be5016dd0d2f3195f4fa04","analyzedAt":"2026-08-21T05:07:25.672Z","schemaVersion":2},"datasetVersion":"2026-08-21T11:28:35.574Z"}