phacility/phabricator · warning · PhabricatorMetaMTAReceivedMailProcessingException

err:disabled-sender

err:disabled-sender

Error message

Your account ("%s") is disabled, so you can not interact with over email.

What it means

validateSender() runs on every received mail whose From resolved to a user; the first branch fires when $sender->getIsDisabled() is true — an administrator has disabled the account. All inbound interaction for that user is refused with STATUS_DISABLED_SENDER, bundling 'disabled' together with the not-approved and not-verified states under one status code.

Source

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

        $sender->getUsername());
    } else if ($sender->getIsStandardUser()) {
      if (!$sender->getIsApproved()) {
        $failure_reason = pht(
          'Your account ("%s") has not been approved yet. You can not '.
          'interact over email until your account is approved.',
          $sender->getUsername());
      } else if (PhabricatorUserEmail::isEmailVerificationRequired() &&
               !$sender->getIsEmailVerified()) {
        $failure_reason = pht(
          'You have not verified the email address for your account ("%s"). '.
          'You must verify your email address before you can interact over '.
          'email.',
          $sender->getUsername());
      }
    }

    if ($failure_reason) {
      throw new PhabricatorMetaMTAReceivedMailProcessingException(
        MetaMTAReceivedMailStatus::STATUS_DISABLED_SENDER,
        $failure_reason);
    }
  }

}

View on GitHub (pinned to 5720a38cfe)

Solutions

1. If the account should be usable, an administrator re-enables it in People (Manage User > Enable); inbound mail works immediately after.
2. If the disable is intentional, stop mail at the source: remove the forwarding rule or the mailbox alias that routes that person's mail into Phabricator.
3. Admins: audit MetaMTA > Received Mail filtered on STATUS_DISABLED_SENDER to find which disabled accounts still send.
4. For real automation needs, migrate the workflow to a dedicated bot account that stays enabled.

Example fix

// before: disabled account replies to a notification
// From: leaver@example.com (account 'jdoe', isDisabled=1)
// -> validateSender() -> err:disabled-sender

// after: admin re-enables the account (or automation moves to a bot account)

// Pre-flight the account state before relying on email interaction:
$user = id(new PhabricatorUser())->loadOneWhere('userName = %s', $username);
if (!$user || $user->getIsDisabled()) {
  // inbound mail from this account will be rejected: re-enable or re-route
}

try {
  $received_mail->processIncomingMail($sender);
} catch (PhabricatorMetaMTAReceivedMailProcessingException $ex) {
  if ($ex->getStatusCode() === MetaMTAReceivedMailStatus::STATUS_DISABLED_SENDER
      && preg_match('/disabled/', $ex->getMessage())) {
    // administrative action needed; retrying the same mail will not help
  }
  throw $ex;
}

When it happens

Trigger: Mail arrives from the registered, verified address of a user whose Phabricator account row has isDisabled = 1 (disabled via People > user > Disable, or by an admin cleaning out a leaver). Receiver processing reaches validateSender($sender) and the first condition throws.

Common situations: Employees who left the company but whose old mailbox auto-forwards to a Phabricator address; accounts disabled for policy reasons that still receive notification digests and reply to them; admin bulk-disabling spam accounts whose owners keep emailing.

Related errors

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

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