import type { GraphClientConfig } from "../lib/graph-client.js";
import { type MessageInput } from "../lib/message.js";
export interface MailSendResult {
    status: "sent";
    httpStatus: number;
    messageId: string | null;
    attachments: string[];
}
/**
 * Send a message via Microsoft Graph.
 *
 * Two transports, chosen by whether the message carries a file:
 *
 *   - no attachments → `POST /me/sendMail`. One call, atomic.
 *   - attachments    → `POST /me/messages` (draft) → per-file attach →
 *                      `POST /me/messages/{id}/send`, reusing mail-reply's
 *                      proven order.
 *
 * The switch is forced, not stylistic: `/me/sendMail` carries attachments inline
 * in the request body and is bounded well below the plugin's 25 MB per-file cap,
 * so a large file can only reach the wire through a draft's upload session.
 * The `op: "transport"` line names the route actually taken — a `route=sendMail`
 * line with `attachments>0` is the mis-wire signature and must never appear.
 *
 * `messageId` is null on BOTH routes. `/me/sendMail` returns 202 with no body,
 * and on the draft route the draft id is consumed by `/send` — returning it
 * would hand back a handle that 404s on the next call (Task 1688). Success is
 * asserted on the Graph status, which `writeGraph` already enforces by throwing
 * on any non-2xx; the literal status is logged rather than an assumed 202.
 *
 * The draft route is NOT atomic: an attach or send failing Graph-side leaves a
 * draft in the Drafts folder, the same exposure mail-reply carries. It is
 * operator-visible there, and greppable as an `op:"transport" route=draft-send`
 * line with no terminal `sent` line. Paths validate before any Graph write, so
 * the common failure — a bad path — still orphans nothing.
 */
export declare function runMailSend(config: GraphClientConfig, input: MessageInput): Promise<MailSendResult>;
//# sourceMappingURL=mail-send.d.ts.map