phacility/phabricator · warning · PhabricatorMetaMTAReceivedMailProcessingException

err:bad-hash

err:bad-hash

Error message

This mail is addressed to an object ("%s"), but the address is not correct (the security hash is wrong). Check that the address is correct.

What it means

Thrown by PhabricatorObjectMailReceiver after it recomputes the security hash for the address: computeMailHash(loadMailKey($object), $check_phid) must byte-match the hash segment of the receiver address (compared with phutil_hashes_are_identical, a timing-safe comparison). The hash binds the address to one object and one viewer, so a mismatch means the address was hand-edited, truncated, mangled by a mail client, or generated against a different mail key. Status is STATUS_HASH_MISMATCH.

Source

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

      if ($sender_identifier != $sender->getID()) {
        throw new PhabricatorMetaMTAReceivedMailProcessingException(
          MetaMTAReceivedMailStatus::STATUS_USER_MISMATCH,
          pht(
            'This mail is addressed to the private email address of an object '.
            '("%s"), but you are not the user who is authorized to use the '.
            'address you sent mail to. Each private address is unique to the '.
            'user who received the original mail. Try replying to a message '.
            'which was sent directly to you instead.',
            $pattern));
      }
      $check_phid = $sender->getPHID();
    }

    $mail_key = PhabricatorMetaMTAMailProperties::loadMailKey($object);
    $expect_hash = self::computeMailHash($mail_key, $check_phid);

    if (!phutil_hashes_are_identical($expect_hash, $parts['hash'])) {
      throw new PhabricatorMetaMTAReceivedMailProcessingException(
        MetaMTAReceivedMailStatus::STATUS_HASH_MISMATCH,
        pht(
          'This mail is addressed to an object ("%s"), but the address is '.
          'not correct (the security hash is wrong). Check that the address '.
          'is correct.',
          $pattern));
    }

    $mail->setRelatedPHID($object->getPHID());
    $this->processReceivedObjectMail($mail, $object, $sender);

    return $this;
  }

  protected function processReceivedObjectMail(
    PhabricatorMetaMTAReceivedMail $mail,
    PhabricatorLiskDAO $object,
    PhabricatorUser $sender) {

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Reply to an untouched, recent notification from Phabricator — never retype or edit the generated address.
2. Check the To header actually delivered (full address including +hash local part) in the raw mail source; mail-transport or list rewrites are a common culprit.
3. If addresses keep breaking for one object, verify its mail properties row exists and is stable (PhabricatorMetaMTAMailProperties) — regenerated keys invalidate every previously issued address for that object.
4. Send from the account the notification was addressed to so the hash's viewer component matches the sender.

Example fix

// before: hash segment damaged by a client wrapping the header
// To: D123+456+e3b0c44298fc1c14@phabricator.
//     example.com  (wrapped/truncated) -> err:bad-hash

// after: intact address on one line
// To: D123+456+e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855@phabricator.example

// Re-derive the expected hash before sending (mirrors the receiver check):
$mail_key = PhabricatorMetaMTAMailProperties::loadMailKey($object);
$expect = PhabricatorObjectMailReceiver::computeMailHash($mail_key, $viewer_phid);
// compare byte-for-byte with the hash segment of the address you are about to use
if (!phutil_hashes_are_identical($expect, $address_hash_segment)) {
  // address is stale/mangled: fetch a fresh notification instead of sending
}

When it happens

Trigger: Processing mail whose receiver pattern is like D123+456+HASH@ where HASH != HMAC over (mail key, PHID). This happens when a user edits or shortens the address, a mail client line-wraps/truncates the To header, the object's mail key was regenerated (PhabricatorMetaMTAMailProperties::loadMailKey returns a different key), or the address was assembled for a different install.

Common situations: Users copy-pasting a reply address by hand and dropping characters; mailing-list software or footers rewriting To addresses; objects imported/restored from a backup where mail properties differ; users trying to guess or construct addresses to act as someone else (the hash prevents exactly this); reply chains in clients that trim long local parts.

Related errors

• err:no-public-mail
• err:bad-user
• err:unknown-sender
• err:no-receivers
• err:self

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