/me/sendMail from an account without a mailbox: 504, then three retries

Symptom

A "Send reminder" button in an SPFx web part, clicked by a global admin account:

• the button shows its busy state for about two minutes,
• the network shows four POST https://graph.microsoft.com/v1.0/me/sendMail requests (if you can see them at all – MSGraphClient calls are easy to miss in DevTools), each ending in 504 after ~30 s,
• the app finally reports a raw HTTP 504 · UnknownError instead of anything about a mailbox.

The same account elsewhere gets the well-known MailboxNotEnabledForRESTAPI / "The mailbox is either inactive, soft-deleted, or is hosted on-premise" – so code that only matches that error never fires.

Why

1. The account has no Exchange Online plan. Admin accounts are often licensed without Exchange, or not licensed at all. Graph may reject sendMail immediately or may wait on the mailbox lookup until the gateway gives up with 504.
2. The SDK retries it. @microsoft/microsoft-graph-client (which MSGraphClientV3 wraps) installs a RetryHandler by default: up to 3 retries for 429, 503 and 504, with exponential back-off, and it retries requests with a buffered body – a JSON sendMail body is buffered. So a timeout becomes 4 × 30 s.
3. The usual signals lie. The mail property on /me and the site user's Email in SharePoint (/_api/web/currentuser) can both be filled in for such an account – they come from the directory, not from a mailbox. (pageContext.user.email, on the other hand, is often empty for these accounts – a different trap, see below – so neither filled nor empty tells you whether mail will go.)

Fix

Ask once per session whether the sender can send at all, before the first sendMail:

interface IAssignedPlan { service?: string; capabilityStatus?: string; }

/** true = has a usable Exchange plan, false = certainly not, undefined = could not tell. */
export function hasExchangePlan(plans: IAssignedPlan[] | undefined): boolean | undefined {
  if (!Array.isArray(plans)) return undefined;
  return plans.some(p => !!p && String(p.service || '').toLowerCase() === 'exchange'
    && (p.capabilityStatus === 'Enabled' || p.capabilityStatus === 'Warning'));
}

let mailboxCheck: Promise<boolean | undefined> | undefined;
function senderHasMailbox(client: MSGraphClientV3): Promise<boolean | undefined> {
  if (!mailboxCheck) {
    mailboxCheck = client.api('/me?$select=assignedPlans').get()
      .then((me: { assignedPlans?: IAssignedPlan[] }) => hasExchangePlan(me.assignedPlans))
      .catch(() => undefined);   // unreadable = don't block sending on a guess
  }
  return mailboxCheck;
}

// before sending:
if (await senderHasMailbox(client) === false) {
  // same message as for MailboxNotEnabledForRESTAPI – do not call sendMail at all
}

• assignedPlans comes back only when you ask for it with $select. It is a property of the signed-in user's own profile (measured with an app that also had User.Read.All consented).
• Warning means the subscription is in a grace period – mail still works, so keep sending.
• If the plans can't be read, send anyway: refusing on a failed read would block users who do have a mailbox.

Also worth doing

• Treat the RetryHandler as part of your write path: when you debug a "slow send", count requests in the network log, not clicks.
• If duplicates would hurt (notifications to external people), consider sending through a client without the retry middleware for this one call, or make the message idempotent on your side (record "sent" before showing success, check it before resending).

See also

• A mail-permission probe that can't tell "no mailbox" from "no consent"
• A mailto: fallback reported as sent
• MSGraphClient calls bypass the DevTools network panel
• Per-user data vanishes for admin accounts