How Superintelligence Works | Outbound Email Safety — Recipient Binding, Attachments and Verified Sending

An AI agent that drafts an email has not automatically been authorised to send it. A message can have excellent wording but the wrong recipient, a stale attachment or a Bcc field that exposes sensitive information. Outbound email safety binds an explicit user decision to the exact intended sender, recipients, body, files and timing, then distinguishes preparing a draft from submitting it to an email provider and confirming what happened next. A confident ‘sent’ message is not proof of external delivery.

Did you know that some email APIs return a successful Accepted response before delivery processing has finished? A robust assistant must understand provider-specific states, inspect the real submitted message and avoid resending after an ambiguous timeout. It must also protect private source data, recognise changes after approval and keep third-party text from acting as a new send instruction. These are application-level controls, not etiquette rules for how a subject line should sound.

This guide uses an invented hundred-operation send ledger and a changed school-support exercise. All outcomes are fictional teaching values, not real eduKate email activity or proof of artificial superintelligence. The wider How Super Intelligence Works library includes distinct articles on Dual Control and Agent Cancellation.

Choose a reading route

• Writing an email with AI? Begin with draft, approval and exact recipient binding.
• Building a sending agent? Study provider response states, attachments and timeouts.
• Teaching Mathematics? Verify the hundred-send and forty-message dispositions.
• Protecting private information? Focus on Cc/Bcc, attachment versions and consent.

Contents

• 1. Draft, approve, submit and deliver are different states
• 2. Recipient identity should be bound to the exact task
• 3. Aliases, autocomplete and domain similarity need attention
• 4. Approval applies to content, recipients and attachments
• 5. Attachments require exact identity and safe processing
• 6. Keep drafts editable without implicit transmission
• 7. Use provider APIs according to their actual contracts
• 8. An accepted send can still have unknown outcome
• 9. Scheduling introduces another authority boundary
• 10. An invented one-hundred-operation send ledger
• 11. Build a review display that prevents destination mistakes
• 12. A changed-context forty-message exercise
• 13. Diagnose six preventable send failures
• 14. The practical sending checklist
• Frequently asked questions
• Provider documentation and source notes
• Further learning

1. Draft, approve, submit and deliver are different states

A draft may be complete and helpful without being transmitted. A user can ask the agent to prepare a polite message for review, which does not authorise sending. If the model later says it has finished, that can legitimately mean the draft is ready. The assistant should not silently reinterpret draft completion as permission to send to the recipient. A separate current grant is needed for the consequential external action under the user’s requested scope.

After approval, the application may submit a message to a provider. The provider can accept the request, process it asynchronously, attempt delivery and receive a later bounce or rejection. These milestones have distinct evidence. Microsoft’s Graph sendMail documentation says its 202 Accepted response does not mean processing has completed. Gmail’s users.messages.send method returns a message resource on success, but a submission receipt is not proof that the human recipient read the email.

User-facing wording must match the actual state: Draft ready, Awaiting confirmation, Submitted to provider, Sent-item verified under the provider’s semantics, Delivery status unknown or Confirmed by a supported receipt. Do not collapse these into one binary Sent field. A provider may not offer final recipient-delivery proof at all. Honest limitations support a person’s decision better than inventing receipt or reading information.

Return to contents or continue with Recipient identity should be bound to the exact task.

2. Recipient identity should be bound to the exact task

An email address is an external destination. A student’s parent, school counsellor and admissions office may have similar display names, but a wrong address can disclose private information. The application should obtain intended recipient identities from the user or another authorised source and keep exact addresses within the approval contract. A model must not invent missing email addresses from likely institutional patterns.

Check To, Cc and Bcc separately. Gmail’s documented send method transmits to recipients in those headers. A copied recipient may receive the entire message and attachment even when the primary To field is correct. A blind-copy recipient can also have privacy implications when the user did not expect their inclusion. The approval view should show the actual recipient set, not only one familiar display name.

A recipient can change between drafting and sending because of manual edits, an autocomplete suggestion or a workflow transformation. If the destination materially differs from the approved target, the executor should refuse or request renewed confirmation according to policy. A valid subject line and grammatically correct body do not repair an incorrect recipient. Address binding is a permission boundary rather than a cosmetic proofreading step.

Return to contents or continue with Aliases, autocomplete and domain similarity need attention.

3. Aliases, autocomplete and domain similarity need attention

Modern email clients may display names rather than raw addresses. Two contacts can share a name, and a familiar-looking domain can differ from the intended institution. An agent that clicks the first autocomplete result may select an unauthorised person. Resolve the actual mailbox identities from the provider’s trusted contact or directory record where permitted, and show them to the user before a sensitive send.

Some workflows allow plus-addressing, aliases or distribution lists. These can be legitimate, but they alter who may receive the message or how it is routed. A mailing list may reach many people despite appearing as one address. The user needs to know the actual destination type for a consequential send. Do not assume that a single visible recipient equals one person or one protected mailbox.

Unicode and internationalised email address handling are complex and provider-specific. Do not normalise a destination by blindly replacing similar-looking characters, dropping dots or changing case without documented semantics. Keep the exact authorised address from the trusted system and validate it through the provider. A model-generated guess about spelling can be unsafe when private school records are attached.

Return to contents or continue with Approval applies to content, recipients and attachments.

4. Approval applies to content, recipients and attachments

A user might approve the words of a message but not its attached grade report or a newly added recipient. Bind the permission to the relevant exact draft revision, sender identity, To/Cc/Bcc set, attachment identities and intended send time or other material conditions. If those change, the earlier decision may not authorise the new message. A text-only confirmation does not necessarily cover later files.

Consider a fictional school reply approved for recipient P-1 with an empty attachment list. The agent later discovers a private progress report and attaches it to be helpful. The subject and body are still correct, but the external disclosure is materially different. A protected send gate should refuse the changed payload until the user and any applicable review policy specifically permit it. The model’s good intentions do not supply the missing consent.

Keep source and task scope visible. A teacher may share general public subject advice while being prohibited from disclosing another pupil’s records. Even if the sending account has technical access to a file, the requested educational purpose may not justify distributing it. A robust workflow verifies both content relevance and information rights before packaging any attachment.

Return to contents or continue with Attachments require exact identity and safe processing.

5. Attachments require exact identity and safe processing

An attachment path or filename is not enough to establish the intended file. Two documents can share a title while containing different students’ information or different source revisions. Store a stable file ID, content revision and approved recipient scope. Before sending, verify that the payload bytes or trusted file metadata match the approved object and that the file remains authorised for external sharing.

Generated PDFs or spreadsheets may not contain the current values the assistant thinks they do. A workbook can have stale formula caches, while a PDF conversion can omit a table or appendix. Validate the actual generated attachment with an appropriate parser or supported viewer before transmission when its contents matter. The related Spreadsheet Formula Verification article explains the distinct numerical case.

Untrusted uploaded attachments may contain active content, malformed archives or misleading metadata. Scan and parse them only through the organisation’s appropriate controlled tools. An AI model’s description of a file as harmless is not a security assessment. An attachment can also contain another person’s personal details; the required access and disclosure checks remain even after virus or file-type validation succeeds.

Return to contents or continue with Keep drafts editable without implicit transmission.

6. Keep drafts editable without implicit transmission

Draft-first workflows support meaningful human control. The agent can assemble a response, propose recipients and attach only explicitly approved materials, then provide a clear review interface. A draft resource created in Gmail or Outlook is not necessarily sent merely because it exists in the user’s account. The backend should use draft operations separately from send operations so a request to prepare content cannot accidentally invoke transmission.

Draft content can change before approval. A later model pass may improve tone but also alter a date, amount or programme rule. The reviewer needs to see the current version rather than approve a stale summary. Bind the send decision to the actual content revision and require current source verification for material claims. The final draft should not silently gain public or private attachments after the user clicks Approve.

If the user decides not to send, preserve that choice. A canceled draft may remain saved privately under the product’s legitimate data policy, but a scheduled send should not be created or resumed from the earlier plan. A background agent cannot treat the passage of time as implied consent. Stop and cancellation rules belong in trusted workflow state beyond the model’s conversational memory.

Return to contents or continue with Use provider APIs according to their actual contracts.

7. Use provider APIs according to their actual contracts

Gmail’s users.messages.send reference documents the message resource and relevant OAuth scopes, and its recipient behaviour is tied to To, Cc and Bcc headers. Microsoft Graph’s sendMail endpoint can accept a JSON message or MIME payload and returns 202 Accepted without guaranteeing completion. An application should not assume identical status codes, fields or delivery receipts across providers.

An agent adapter needs a typed contract for draft creation, update, send and status retrieval. A field named sent may mean different things across APIs, and some methods may not return a final message identifier in the initial response. The adapter must preserve the provider request identity and any trustworthy response it does receive. It should not invent a message ID or a recipient-read receipt simply to create a uniform dashboard.

Authentication scopes are necessary but not sufficient. An API token that permits sending from an account does not prove the user authorised a particular message with particular attachments. The protected application should enforce user-level and resource-level permission before calling the provider. Switching to a more privileged token after a permission refusal is not a safe recovery strategy.

Return to contents or continue with An accepted send can still have unknown outcome.

8. An accepted send can still have unknown outcome

A network timeout after submission is ambiguous. The email provider may have received and accepted the message, or the request may have failed before reaching it. If the agent immediately sends again with a new operation identity, the recipient could receive duplicates. The correct recovery checks the original provider operation or available sent-message state before deciding whether retry is necessary and permitted.

Some providers do not expose definitive end-to-end delivery confirmation in the way an application would like. A message appearing in Sent Items under a suitable contract supports a particular submission observation, not proof the recipient opened or understood it. A later bounce can change delivery status. Use precise user-facing terms and preserve Unknown when the evidence cannot settle the final result.

Idempotency is not automatic just because an API request has the same body. Two identical emails sent separately are still two external effects. An application may need its own stable logical send ID and reconciliation ledger around the provider. Even then, it should not promise exactly-once delivery across all mail systems without a supported guarantee. Human confirmation can be the correct route for a disputed consequential send.

Return to contents or continue with Scheduling introduces another authority boundary.

9. Scheduling introduces another authority boundary

A user may authorise a draft now but plan to send it tomorrow after checking a source. The future time does not imply that the agent may send despite a later cancellation, expired grant or material edit. At execution, revalidate the approved content, recipients and permission. A scheduled job should stop if the context that supported approval no longer applies.

Time zones matter. A send planned for 09:00 Singapore time is a different instant from 09:00 in another country. An email scheduled relative to a school deadline should preserve the intended local date and clock time, with appropriate handling of daylight-saving changes for other jurisdictions. The model should not silently invent a timezone merely because the server has a default.

An approved recurring newsletter is different from one-time correspondence. Its authority may cover a defined audience, frequency and source-update contract, and later opt-outs or permission changes must take effect. An agent should not reuse approval for every future message simply because the format is familiar. Current consent and relevant legal requirements remain outside the scope of model fluency.

Return to contents or continue with An invented one-hundred-operation send ledger.

10. An invented one-hundred-operation send ledger

Consider a fictional Cedar School Mail Desk evaluating one hundred proposed send operations. Sixty-two reach an independently verified provider-accepted submission under the declared send contract. Sixteen are correctly held because user approval is missing. Twelve are blocked because recipients or attachments no longer match the approved payload. Six have unknown provider outcomes after a timeout. Four are cancelled before further external action. The categories add to 62 + 16 + 12 + 6 + 4 = 100.

The verified submission fraction is 62%. Approval holds form 16%, payload-mismatch blocks 12%, unknown effects 6% and cancellations 4%. These are original synthetic teaching values, not real eduKate messages or observed email-provider performance. The sixty-two confirmed submissions should not be described as sixty-two messages opened or read by recipients. Submission verification and recipient delivery are different stages.

A dashboard treating the thirty-two protective holds, mismatches and cancellations as failures would penalise correct permission enforcement. Another dashboard might count the six unknown results as delivered because the model confidently said ‘sent’. Both claims would be unsound. A useful ledger preserves what was actually verified and the responsible next action for each distinct category.

Return to contents or continue with Build a review display that prevents destination mistakes.

11. Build a review display that prevents destination mistakes

A high-consequence send preview should show the actual From identity, complete To/Cc/Bcc recipients, subject, material body text, attachment names and stable file identities, with a clear decision between Save Draft and Send. Accessible review matters: the user should be able to inspect and refuse the action with keyboard or screen reader, not only click a tiny unlabeled icon.

Display names can be useful for recognition but should not hide exact destination addresses when the decision depends on them. A parent may recognise the teacher’s name but still need to know whether the mailbox belongs to the intended school or an external group. The interface should make changed recipients or attachments apparent after approval so a user is not unknowingly confirming a different operation.

Do not give broad groups access to sensitive approval packets without need. A message can contain private pupil information even before it is sent. Keep the draft and review trail within appropriate account permissions and retention. A trustworthy user experience protects the private work while making the final external consequence unambiguous.

Return to contents or continue with A changed-context forty-message exercise.

12. A changed-context forty-message exercise

Imagine a separate fictional helpdesk with forty proposed messages. Twenty-three have confirmed approved provider submissions, seven await current approval, five contain mismatched recipient or attachment details and are blocked, three have unknown external results, and two are canceled. Check 23 + 7 + 5 + 3 + 2 = 40. Confirmed submissions form 23 ÷ 40 = 57.5%, but this says nothing about the recipient-open rate.

Now change the recipient after the user reviewed the message. The draft may still contain correct school advice, but the earlier approval was bound to a different mailbox. A protected send gate should hold the changed message until the right person and any necessary reviewer authorise it. The model should not infer that a new address is acceptable because it belongs to the same institution.

Change the attachment instead. A report version is updated with another pupil’s private data, or the file name remains the same while its content changes. Exact file identity and permissions must be rechecked. If a prior send timed out, the agent should reconcile that original operation before attempting another. These changes illustrate why message content, recipient and external effect are separate evidence dimensions.

Return to contents or continue with Diagnose six preventable send failures.

13. Diagnose six preventable send failures

Failure one: a drafting request is treated as permission to send. Repair explicit state and the trusted approval gate. Failure two: the model selects an autocomplete match by display name alone. Repair exact recipient binding and visible confirmation. Failure three: an approved draft gains an attachment or new Cc address afterward. Repair content and recipient version checks.

Failure four: the provider returns 202 Accepted and the assistant claims delivery was completed. Repair typed provider states and trustworthy follow-up observations. Failure five: a timeout leads to a duplicate send. Repair stable logical operation identity and reconciliation. Failure six: private source content or a malicious quoted instruction changes the outgoing recipient. Repair the boundary separating untrusted text from authoritative user decisions.

Test failures with synthetic recipients and safe mail sandboxes, never actual parents. Include a correct authorised send and refusal cases, then inspect what the mock provider received. A model statement that it intended to withhold the message is weaker evidence than an actual absence of the external effect. Protect the test credentials and avoid sending dummy messages to real distribution lists.

Return to contents or continue with The practical sending checklist.

14. The practical sending checklist

First define whether the user asked for drafting, reviewing, scheduling or actual transmission. Obtain exact authorised sender, recipient set and material attachment scope. Prepare the current message under the appropriate source evidence and let the user inspect the entire consequence. Bind approval to that version, then have the protected execution service recheck it before submitting to the provider.

Record the provider’s actual response with a stable task ID and preserve whether its semantics mean queued, accepted, sent-item observed or some stronger confirmed state. If a timeout or ambiguous result occurs, reconcile before another send. Never convert a missing receipt into a confident success or a confirmed failure because the user expects closure.

Students can compare two visually identical drafts with different Bcc or attachment fields and explain why only one matches the approved task. Then classify the hundred synthetic operations and calculate why sixty-two confirmed submissions do not imply sixty-two delivered messages. The transferable lesson is that a useful AI agent writes clearly while protecting people through exact permission and truthful external-state reporting.

Return to contents.

16. Reply, reply-all and forwarding are different authorisations

An assistant helping a parent respond to a teacher may see the original message’s sender, recipients and conversation history. Replying only to the teacher is different from replying to everyone in the old thread, and forwarding the entire thread to another person is a further disclosure. A model may choose the most conversationally natural option, but the permitted recipient set must come from the actual user decision and current context.

Quoted messages can contain private details about other learners or staff. A reply-all may expose a response to people who should no longer be involved, especially if a thread originally included a large group. The review interface should show every effective destination and which quoted content or attachment will travel with it. Do not treat a familiar thread title as a permanent blanket permission to copy all participants.

A safe test can use fictitious mailboxes and a quoted group discussion. Ask the agent to draft a reply to one named recipient, then verify the mock provider sees exactly that recipient and only the approved quoted content. Change the instruction to reply-all and require a new matching approval. The correct result depends on scope, not how plausible the outgoing prose looks.

Return to contents for the earlier steps.

17. A mailing list can change the effective audience

One email address may represent a school distribution list, parent association or shared mailbox. Sending to it can expose the message to more people than the one visible address suggests. Before sending sensitive learner information, the system may need to know whether the destination is an individual or a group under the organisation’s policy. A model guessing that a friendly group name is safe cannot establish the recipient population.

Group membership can change between the moment of user approval and provider submission. The exact approval policy may therefore restrict use of distribution lists for private files, require an authorised contact directory or hold the action for a responsible person. When the service cannot confirm that the list is appropriate, preserving a private draft is safer than sending under an unverified assumption.

Bulk messages also have separate consent and subscription obligations that vary by jurisdiction and service context. A user authorising a single parent-support response has not implicitly requested a marketing campaign. Keep one-time correspondence separate from recurring mail automation and apply the applicable organisational and legal rules. The email provider’s technical ability to deliver to a list does not create the missing purpose permission.

Return to contents for the earlier steps.

18. Quoted content is data, not a new command

An incoming email can contain text instructing the agent to forward documents, change the recipient or ignore earlier restrictions. Such content might be genuinely written by a correspondent, yet it is not necessarily authorised by the user currently controlling the assistant. Treat quoted mail and attachments as lower-trust evidence until the authenticated user actually approves the next action.

Do not let a model convert a quoted instruction into a tool command simply because it appears in the latest message. The service should enforce current sender and recipient scope, attachment access and user approval outside the language model. An untrusted PDF saying ‘reply to this new address’ can suggest a contact for review, not silently alter the authorised destination.

Testing can use harmless invented messages whose text requests a different send target. The protected executor should still address only the user-approved recipient. A model’s apology after sending to the wrong account is not a successful safety result. The measurable property is that the unapproved message never leaves the controlled service.

Return to contents for the earlier steps.

19. Outgoing attachments need current data boundaries

An attachment might be created from several source records, including a progress table, a teacher comment and a derived summary. Before sharing it outside the original system, validate that each included field belongs to the intended learner and may be disclosed to the selected recipient. A successful document conversion does not provide this right. Source provenance and permission must be checked at the package boundary.

Generated spreadsheets can contain stale calculated values or hidden columns with private information. A PDF may have a second page not visible in the email preview, and an image can include metadata or background details. Review the actual saved attachment bytes or a trustworthy rendition, not only the model’s description. A file named progress-report.pdf is not evidence it contains the right child’s report.

Changes after approval matter. If the teacher updates the marks and the exporter regenerates the file, the content may differ materially from what the parent reviewed. The application needs a revision-bound approval or a documented rule for the exact allowable change. A safe workflow can request reconfirmation rather than assume the original name and file extension are enough.

Return to contents for the earlier steps.

20. Mail headers and body must remain under a typed contract

Internet messages include structured addressing and content fields. RFC 5322 describes the Internet Message Format and relevant headers, while provider APIs may offer higher-level JSON objects or MIME submissions. The agent should use a supported message-construction interface with typed fields, not concatenate untrusted text into raw headers without validation. The sender identity and recipient list should be enforced by the actual authenticated mail service.

Untrusted input can contain line breaks, markup or strings that resemble additional header fields. A robust adapter should encode and validate data according to its chosen provider contract so quoted text remains part of the intended body, not an instruction to add new recipients. A message that parses successfully is not necessarily permitted; the application still needs the user’s current approval for the effective fields.

Do not invent a universal provider behaviour from email standards alone. An API may return one message ID, another may return Accepted with no body, and clients can represent threads differently. Record the exact provider method, request and received response, and test the intended semantics under an authorised sandbox before relying on them for user-facing status.

Return to contents for the earlier steps.

21. The sent folder and delivery receipt have different meaning

A mailbox’s Sent Items entry can support a sender-side observation that the provider accepted or processed a message under its own rules. It does not prove every destination mailbox received the content, that spam filtering allowed it into an inbox or that a person opened it. A later bounce or delivery-status notification may provide additional evidence, but even those have provider-specific limitations.

Microsoft Graph’s sendMail documentation explicitly states that 202 Accepted does not guarantee completed processing. Gmail’s send API returns a Message resource under its documented success behaviour. Neither contract should be casually replaced with the claim ‘the recipient has read your letter’. A responsible agent uses specific status labels and does not manufacture a read receipt because the user would find it reassuring.

A dispute about delivery needs an appropriate support path. Preserve the original sender-side operation, message ID when available, approved recipients and exact submission time. The next step may be a provider audit or direct human confirmation through an approved channel. Blindly resending can increase confusion or expose private content twice, so the controller should reconcile what is actually known first.

Return to contents for the earlier steps.

22. Changed destination policy after a user approval

Suppose a parent approves a message to the school’s designated office at one exact address. The institution later changes its official contact channel, and the agent finds a new address in a retrieved webpage. That new source might be authentic, but the original send approval still covered the first destination. An authorised route update or user reconfirmation may be necessary before transmitting sensitive information.

A model that automatically substitutes the new address because it seems more current can cross the permission boundary. Conversely, insisting forever on an obsolete address could fail the user’s purpose. The correct response is to present the material destination change clearly, cite the relevant official source and obtain the applicable decision before executing the new send.

The final message should not overclaim. The assistant can say that it prepared the revised draft and identified a changed contact detail; it should not say that the correspondence was sent or received until trustworthy provider evidence supports those states. This is a useful distinction for real parents planning application questions and school meetings.

Return to contents for the earlier steps.

23. Correcting the hundred-operation synthetic ledger

Return to the fictional one-hundred-operation population: sixty-two confirmed provider-accepted submissions, sixteen approval holds, twelve payload-mismatch blocks, six unknown effects and four cancellations. Suppose a responsible user later approves eight of the pending messages without any change to their recipient or attachments, and their subsequent submissions are independently verified under the defined provider criterion.

The new accepted-submission count becomes seventy, pending approval falls to eight and the other categories remain twelve, six and four. Check 70 + 8 + 12 + 6 + 4 = 100. Accepted submissions now form 70% of the same invented task population. The increase reflects later authorised action, not a change to the provider’s deliverability or recipient readership.

Do not label the resulting seventy messages delivered without downstream evidence. If a later bounce is recorded, the corresponding state should be tracked separately. A service dashboard can legitimately show accepted submissions, delivery notifications and unresolved statuses under provider-specific definitions. A single large ’emails sent successfully’ number hides the distinctions a user needs when a consequential message has not reached its recipient.

Return to contents for the earlier steps.

24. Rate limits and queueing change the meaning of now

An email provider may throttle a burst of requests or queue accepted sends. A scheduled agent that tries to submit many messages during a peak period should respect provider limits and application budgets, not keep retrying immediately until the queue fills. A successful API acceptance can still precede final processing. The user’s requested timing should be distinguished from a promised instant arrival.

Priority should reflect the legitimate communication task. A time-sensitive permitted parent notice might need prompt processing, while an optional newsletter can wait or be safely canceled. An expired recipient permission must not be preserved merely because the message sat in the queue. Recheck the exact grant at the action boundary when the workflow’s policy requires it.

Do not silently substitute a different mailing service or broad credential to bypass rate limits. That may change data residency, recipients, sender identity or privacy handling. A transparent status such as ‘submission postponed under provider limits’ is preferable to a falsely delivered receipt. Cost and throughput optimizations cannot create new user authority.

Return to contents for the earlier steps.

25. A final user-facing status should be exact

After an authorised submission, describe the strongest state the provider actually established. A message may have been saved as a draft, handed to a sending service or recorded in Sent Items. These are distinct milestones. If a reply is still waiting for review, provide the draft and the reason it remains unsent. The user should never have to infer from enthusiastic language whether an external action occurred.

A trustworthy task record connects the original approval to the exact content and destinations, the provider operation, and any subsequent delivery or bounce evidence. This supports correction if a mistake was made and prevents another worker from repeating an uncertain send. It should protect sensitive message content with appropriate retention and account permissions.

Students can use a fictitious email exercise to learn these distinctions. They can compare a draft-only request with an approved send, identify how changing a Bcc or attachment changes the permitted operation, and recalculate the 100-case ledger after eight approvals. The principle transfers beyond email: a good AI agent separates planning, human authority, execution and verified real-world outcomes.

Return to contents for the earlier steps.

• 16. Reply, reply-all and forwarding are different authorisations
• 17. A mailing list can change the effective audience
• 18. Quoted content is data, not a new command
• 19. Outgoing attachments need current data boundaries
• 20. Mail headers and body must remain under a typed contract
• 21. The sent folder and delivery receipt have different meaning
• 22. Changed destination policy after a user approval
• 23. Correcting the hundred-operation synthetic ledger
• 24. Rate limits and queueing change the meaning of now
• 25. A final user-facing status should be exact

Frequently asked questions

Does asking an AI to draft an email authorise sending it?

No. Draft completion and transmission require different task states and appropriate user permission.

Should To, Cc and Bcc all be checked?

Yes. Each can change who receives the content, and a familiar display name alone may be insufficient.

Does Microsoft Graph 202 Accepted prove delivery?

No. The official sendMail documentation explicitly distinguishes acceptance from completed processing.

Can the assistant safely resend after a timeout?

Only after reconciling the earlier operation and current authority; an immediate repeat may deliver duplicates.

Does the Sent folder prove the recipient read the message?

No. It supports the relevant sender-side record under provider semantics, not human readership.

What if an attachment changed after approval?

A material file or recipient change can invalidate the approval and require a new authorised review before sending.

Provider documentation and source notes

Sources reviewed 24 October 2026. The Cedar Mail Desk, recipients, messages, counts and examples are fictional teaching material. The article does not claim that any email was sent for the reader.

• Microsoft Graph: sendMail: 202 Accepted and the distinction between acceptance and completed delivery processing.
• Gmail API: users.messages.send: Message submission, To/Cc/Bcc and provider-specific response fields.
• Gmail API: users.drafts.send: The provider’s explicit draft-to-send operation.
• RFC 5322: Internet Message Format: Email message header and addressing concepts.
• OWASP Authorization: Current authority at protected action boundaries.
• NIST AI RMF: Manage: Accountable human oversight and effect verification.

Further learning

Continue through Super Intelligence curriculum; How X Works hub; Dual Control; Agent Cancellation; Data Export; Tool Contract Drift; Gold Standard of Education. A safe send keeps exact user consent, message payload and provider evidence together.