审批与发信策略

每封外发信都由放行服务对照组织的发信策略检查。策略决定立刻发出、等一个人批准，还是拦住。人在控制台里改策略（要再次验证）；agent 能看到效果，但不能改。

分层：每一层只能更严

策略设在五层，从上往下合并：

平台 → 组织 → pod → 邮箱 → key

下一层只能让结果更严，不能更松。「更严」按字段定义，所以合并是可预期的：

字段	更严是指
limits.*、approval.ttl_minutes、attachments.max_total_bytes、injection.hold_threshold、loop_guard.max_exchanges_*、inbound.wake.*	更小的数
dedupe.window_minutes、loop_guard.window_hours	更大的数
recipients.allow_bcc、attachments.allow_outbound、links.allow	false 赢
content.block_*、recipients.block_punycode、loop_guard.block_reply_to_auto_submitted、llm_injection_scoring、branding.footer	true 赢
approval.mode	none < first_contact < risky < first_contact_and_risky < all
first_contact	allow < approval < block
approval.approvers	由组织设置；下层只能减人

策略文档

{
  "approval": { "mode": "first_contact_and_risky", "channels": ["console", "telegram", "slack", "email_reply"], "ttl_minutes": 1440, "approvers": ["usr_…"] },
  "first_contact": "approval",
  "limits": { "daily_recipients": 100, "inbox_daily_recipients": 200, "key_daily_recipients": 200, "per_thread_per_hour": 10, "per_recipient_per_day": 20, "max_recipients_per_message": 50 },
  "dedupe": { "window_minutes": 1440 },
  "loop_guard": { "block_reply_to_auto_submitted": true, "max_exchanges_per_thread_per_day": 20, "max_exchanges_per_peer_per_day": 40, "window_hours": 24 },
  "content": { "block_credentials": false, "block_card_numbers": true, "block_empty": true, "block_placeholders": true },
  "recipients": { "allow_bcc": false, "block_punycode": false },
  "attachments": { "allow_outbound": true, "max_total_bytes": 3670016 },
  "links": { "allow": true },
  "branding": { "footer": true, "display_name_suffix": true },
  "t0": { "stranger_thread": "approval", "auto_per_thread_per_day": 3, "thread_token_ttl_days": 30 },
  "inbound": { "wake": { "stranger_daily": 50, "per_sender_hourly": 5 } },
  "injection": { "hold_threshold": 0.7 },
  "llm_injection_scoring": false
}

这是新组织的默认值。组织能选的最松审批模式是 first_contact_and_risky；没有 none。

什么时候要批准

approval.mode	人要批准
first_contact	发给还不是该邮箱联系人的人
risky	带任何风险旗标的信
first_contact_and_risky	上面两种都要（默认）
all	每一封

与模式无关的还有：

• first_contact: block 直接拒绝首次联系（first_contact_blocked）。
• 陌生人发起的线程里每一次回复都要批准（t0.stranger_thread），除非人把发件人升成联系人。
• 每个线程每天最多 t0.auto_per_thread_per_day 封可以不经批准发出；其余等人。
• 复用了 agent 在其他线程里读到的内容（cross_thread_echo）要批准。这是提示注入外泄的典型形状。
• 转发给新收件人算首次联系。

给审批人看的风险旗标：first_contact、punycode、lookalike_domain、cross_thread_echo、has_links、has_attachments、bcc、credential_like、large_recipient_set、new_recipient_domain、recipient_unverified。

联系人。 邮箱先写给某人且对方回了，或人在控制台里提升他们，他们就成为该邮箱的联系人。

审批人看到什么、怎样决定

审批卡显示发件人、放行服务将要发送的每一个信封收件人、主题、正文开头 2,000 个字符、附件名和大小、风险旗标、提交用的 key，以及控制台里该线程的链接。

审批人可以在这些地方决定：

• 控制台（审批人、所有者和管理员；5 分钟内再次验证），
• Telegram 或 Slack，在人于控制台接上之后，
• 邮件：在审批请求的第一行回复 APPROVE 或 REJECT（只能来自审批人已验证的地址，并且 DKIM 对齐）。

批准绑定确切内容。请求之后内容变了，批准就不再适用。每次批准只能决定一次。未决定的批准在 approval.ttl_minutes（默认 24 小时）后过期，信不会发出。

agent 看到什么

agent 从不批准。他们可以跟踪结果：

• 发送响应说 status: "pending_approval"，并带 flags；
• GET /v0/sends/{send_id} 会变成 approved（然后 sending、sent）、rejected、expired 或 cancelled（发送）；
• GET /v0/approvals 和 GET /v0/approvals/{approval_id} 只返回元数据（审批 API）；approval.requested 和 approval.decided 事件 报告变化。

等批准的 agent 不要用新的幂等键重发；那会再开一次批准，批准后就是重复的一封。

最后检查

批准不是最后一步。已批准或已定时的信离开之前，放行服务重读当前状态：暂停、已吊销的 key、已删除或暂停的邮箱、线程锁、抑制名单和拦截名单、当前策略和今天的限额。不再通过的信会等待或被拦住（policy_changed、principal_revoked 等）；不会凭过期的批准发出。

署名

外发信署 simail.ai：一行页脚 — Sent by an AI agent via simail.ai，显示名后面加 " via SiMail"。在 simail 邮件域上的每个组织都开着。