mail_send
Gate: gated
on mail.send, target the recipient address
· write
The one mail tool that leaves the household, and the only one that asks. Every recipient is checked on its own, because "send to these three?" is not a question a person can answer on a phone — and a grant remembered from one ask would otherwise carry an approval for each of them. Plain text only: an assistant writing HTML mail is a formatting problem nobody asked for, and every feature here is another way for generated content to leave.
Input
| Field | Type | Required | Notes |
|---|---|---|---|
to | array of string | yes | Recipient addresses. Each is parsed with net/mail and continues in its canonical form, so what the gate asks about, what a grant records and what the To header carries are the same string — a value with a second header behind a newline is refused before anything is asked. Each is checked separately; one denial stops the whole send. |
subject | string | yes | Subject line. Sent as an RFC 2047 encoded word, so non-ASCII survives. |
body | string | yes | Message text. Sent as quoted-printable, UTF-8. |
Output
{"sent": true, "to": [...]} once the submission server has accepted the message. There is no later confirmation and no way back — that asymmetry is why this asks and the reading tools do not.
From JavaScript
nocturn.call("mail_send", { to: ["chef@firma.de"], subject: "Freitag", body: "Bis dann." });Notes
The gate is checked before anything is composed, and the leak scanner runs between the gate and the wire: a message carrying a known vault value never leaves. What comes back to the model then says only that the send was refused — unlike a rejected http_write there is nothing for it to correct, and naming the reason would tell it which text is a stored secret. TLS is not optional on either path: port 465 is encrypted from the first byte, anything else must offer STARTTLS or the send is refused rather than downgraded.