phacility/phabricator · error · PhabricatorMetaMTAReceivedMailProcessingException

err:not-found

err:not-found

Error message

This mail is addressed to an object ("%s"), but that object does not exist.

What it means

The object identifier parsed from the target address was well-formed, but loadObject() returned nothing: no object with that pattern exists. The mail is rejected with STATUS_NO_SUCH_OBJECT ('err:not-found'). This is the mail-receiver analogue of a 404 — distinct from err:policy (object exists but is hidden).

Source

Thrown at src/applications/metamta/receiver/PhabricatorObjectMailReceiver.php:60

    }

    $pattern = $parts['pattern'];
    $sender = $this->getSender();

    try {
      $object = $this->loadObject($pattern, $sender);
    } catch (PhabricatorPolicyException $policy_exception) {
      throw new PhabricatorMetaMTAReceivedMailProcessingException(
        MetaMTAReceivedMailStatus::STATUS_POLICY_PROBLEM,
        pht(
          'This mail is addressed to an object ("%s") you do not have '.
          'permission to see: %s',
          $pattern,
          $policy_exception->getMessage()));
    }

    if (!$object) {
      throw new PhabricatorMetaMTAReceivedMailProcessingException(
        MetaMTAReceivedMailStatus::STATUS_NO_SUCH_OBJECT,
        pht(
          'This mail is addressed to an object ("%s"), but that object '.
          'does not exist.',
          $pattern));
    }

    $sender_identifier = $parts['sender'];
    if ($sender_identifier === 'public') {
      if (!PhabricatorEnv::getEnvConfig('metamta.public-replies')) {
        throw new PhabricatorMetaMTAReceivedMailProcessingException(
          MetaMTAReceivedMailStatus::STATUS_NO_PUBLIC_MAIL,
          pht(
            'This mail is addressed to the public email address of an object '.
            '("%s"), but public replies are not enabled on this server. An '.
            'administrator may have recently disabled this setting, or you '.
            'may have replied to an old message. Try replying to a more '.
            'recent message instead.',

View on GitHub (pinned to 5720a38cfe)

Solutions

Confirm the object exists by opening the same ID in the web UI (e.g. /T123).
Reply to a current notification so Phabricator regenerates a valid object address.
If the object was deleted, no configuration fixes it — start a new thread or recreate the object.

Defensive patterns

Strategy: validation

Validate before calling

// Before generating an object reply address, confirm the object still exists:
$object = id(new PhabricatorObjectQuery())
  ->setViewer(PhabricatorUser::getOmnipotentUser())
  ->withPHIDs(array($phid))
  ->executeOne();
if (!$object) {
  // do not emit a reply-to address for a deleted object
}

Try / catch

try {
  $receiver->processReceivedMail($mail, $target);
} catch (PhabricatorMetaMTAReceivedMailProcessingException $ex) {
  if ($ex->getStatusCode() === MetaMTAReceivedMailStatus::STATUS_NO_SUCH_OBJECT) {
    // tell the sender the object no longer exists; do not retry
  }
}

Prevention

Distinguish err:not-found (object gone) from err:policy (object hidden) before debugging.
Regenerate reply addresses from current notifications rather than reusing old ones.
When deleting objects that have active mail threads, expect replies to start failing with this status.

When it happens

Trigger: Replying to mail for an object that has since been deleted (task deleted, diff discarded); a mistyped or guessed object address (D99999 that was never created); replying to an ancient thread whose object no longer exists.

Common situations: Old mail threads resurrected after object deletion; addresses harvested from stale documentation or signatures; ID typos in manually composed addresses.

Related errors

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