phacility/phabricator · error · Exception

Receiver '%s' accepts mail to '%s', but is not a subclass of

Error message

Receiver '%s' accepts mail to '%s', but is not a subclass of PhabricatorObjectMailReceiver.

What it means

A receiver did accept the mail (canAcceptMail returned true), but this workflow additionally requires an instanceof PhabricatorObjectMailReceiver, because it then calls loadMailReceiverObject() to compute object mail keys and the to+userID+hash@ addressing scheme. The accepting receiver class is not that subclass - typically a custom or extension receiver - so the workflow aborts rather than generate a malformed test.

Source

Thrown at src/applications/metamta/management/PhabricatorMailManagementReceiveTestWorkflow.php:152

        $possible_receiver = id(clone $possible_receiver)
          ->setViewer($viewer)
          ->setSender($user);

        if (!$possible_receiver->canAcceptMail($pseudomail, $target)) {
          continue;
        }
        $receiver = $possible_receiver;
        break;
      }

      if (!$receiver) {
        throw new Exception(
          pht("No configured mail receiver can accept mail to '%s'.", $to));
      }

      if (!($receiver instanceof PhabricatorObjectMailReceiver)) {
        $class = get_class($receiver);
        throw new Exception(
          pht(
            "Receiver '%s' accepts mail to '%s', but is not a ".
            "subclass of PhabricatorObjectMailReceiver.",
            $class,
            $to));
      }

      $object = $receiver->loadMailReceiverObject($to, $user);
      if (!$object) {
        throw new Exception(pht("No such object '%s'!", $to));
      }

      $mail_key = PhabricatorMetaMTAMailProperties::loadMailKey($object);

      $hash = PhabricatorObjectMailReceiver::computeMailHash(
        $mail_key,
        $user->getPHID());

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Test with a destination handled by a standard object receiver instead (e.g. --to T123).
2. If you maintain the custom receiver and it genuinely wraps an object, make it extend PhabricatorObjectMailReceiver (and implement loadMailReceiverObject).
3. Otherwise exercise custom receivers with their own test tooling rather than receive-test.

function is_object_mail_receiver($receiver) {
  return ($receiver instanceof PhabricatorObjectMailReceiver);
}

When it happens

Trigger: A custom PhabricatorMailReceiver subclass (extension inbound channel) responds to the --to address; receive-test only supports the built-in object receivers (tasks, revisions, etc.).

Common situations: Developing or installing third-party inbound channels; testing an address routed to a custom receiver.

Related errors

• No configured mail receiver can accept mail to '%s'.
• Use '%s' to specify the receiving object or email address.
• Use '--as' to specify the acting user.
• No such user '%s' exists.
• No such object '%s'!

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