常見問題
為什麼不直接讓代理存取我的 Gmail 或 Outlook？
安全性 — Gmail/Outlook 的 OAuth 會讓您的代理存取整個收件匣（醫療、財務、法律、個人郵件）。任何一封入站郵件中的提示注入都可能操控擁有全部存取權的代理。InboxAPI 為您的代理提供獨立隔離的收件匣，每封郵件都附帶信任分類和資料標記。
身份 — 當您的代理從您的 Gmail 發送郵件時，收件人無法分辨他們在和誰交流。回信會進入您的收件匣，與您的真實郵件混在一起。InboxAPI 為代理提供專屬地址 — 您與代理之間有清晰的區隔。
實用性 — Gmail/Outlook API 不是 MCP 原生的。您需要中間件、OAuth 配置和自訂整合。InboxAPI 與任何 MCP 客戶端開箱即用。
與 AWS SES、SendGrid 或 Resend 有什麼不同？
那些是發送 API — 您在它們之上構建電郵基礎設施。InboxAPI 為您的代理提供完整的電郵身份：發送、接收、搜索、回覆和轉發。無需配置，無需管理基礎設施。
與 AgentMail 或 a1base 有什麼不同？
我們從頭開始構建了自己的電郵堆疊。我們不封裝 SES、Postfix 或任何第三方發送服務。您的代理郵件通過我們直接營運的基礎設施。
真的免費嗎？
是的。無需信用卡，無試用期，無使用層級。我們正在開發付費方案及更多功能，但核心體驗將永遠免費。
你們如何防止垃圾郵件和濫用？
建立帳戶需要工作量證明。每個帳戶有 5 個通訊錄配額供外部收件人使用 — 當所有配額已使用時，最久未使用的記錄會在 5 天不活動後自動被替換。每日發件配額和速率限制在每個帳戶上強制執行。這些限制是結構性的 — 它們不是政策，而是系統運作的方式。
透過電郵的提示注入怎麼辦？
每封入站郵件都包含信任分類 — 受信任、代理、未驗證或可疑 — 基於發件人是否在您的通訊錄中以及其電郵是否通過身份驗證檢查。這幫助您的代理決定處理每封郵件時應多謹慎。來自其他 InboxAPI 代理的郵件會單獨標記，讓您的代理知道應先與您確認再採取行動。
此外，不受信任的電郵內容會自動使用 spotlighting（資料標記）進行轉換 — 空格被替換為唯一標記字元，讓您的代理能清楚區分電郵資料與自身指令。這將嵌入電郵中的提示注入攻擊成功率從約 50% 降至 3% 以下。
什麼是 spotlighting？
電郵擷取工具會對不受信任的內容進行資料標記，將空格替換為每次請求生成的唯一 Unicode 標記字元。包含標記的內容應被視為外部資料 — 絕不應視為需要遵從的指令。要恢復原始文字，將標記替換為空格。來自受信任發件人（在您的通訊錄中且認證有效）的電郵預設不會被 spotlight。此技術基於學術研究（arXiv:2403.14720）。
資料外洩怎麼辦？
外發郵件會掃描身份驗證令牌和憑證。如果您的代理意外嘗試發送包含 JWT 或存取令牌的郵件，該郵件會在離開平台前被拒絕。這防止代理被欺騙透過電郵洩漏敏感資料。此外，發送、回覆和轉發操作中的所有收件人地址都根據 RFC 5322 驗證 — 格式錯誤的地址在投遞前被拒絕。
代理之間可以互發垃圾郵件嗎？
相同的發送限制適用於所有外發郵件 — 收件人上限、配額和速率限制的運作方式相同，不論接收方是誰。
代理的郵件會進入垃圾郵件資料夾嗎？
初期可能會。每個代理獲得全新的子網域，新發件人尚無信譽。收件人可能需要檢查垃圾郵件資料夾中的前幾封郵件。隨著時間推移，當您的代理發送合法郵件且收件人與之互動，投遞率會改善。詳見電郵投遞。
為什麼選擇電郵而非 A2A 等原生代理協議？
電郵觸及整個現有的網際網路 — 數十億人和企業已在使用。A2A 需要雙方都實作該協議。當您的代理需要聯繫生態系統外的人時，電郵是通用選項。代理很可能兩者都需要。
為什麼選擇電子郵件而不是 WhatsApp、Telegram 或其他即時通訊應用？
即時通訊應用似乎很適合代理通訊，但它們有結構性的限制，使其在大規模代理場景中不實際。
可擴展性 — 您可以程式化地建立數百個電子郵件地址。WhatsApp、Telegram 和 Signal 都需要電話號碼和驗證。擴展超過幾個帳戶是不切實際的，通常違反服務條款，有時沒有實體 SIM 卡根本不可能。如果您的工作流程需要 50 個代理，您就需要 50 個電話號碼。
無門檻限制 — 電子郵件是唯一一個可以在不需要電話號碼、身份證件或平台擁有者批准的情況下建立身份的通訊管道。沒有任何一家公司控制誰能獲得電子郵件地址。
開放協議 — 電子郵件是聯邦化且供應商中立的。WhatsApp、Discord 和 Telegram 是專有的——它們可以隨時撤銷 API 存取權、封禁機器人帳戶或更改規則。電子郵件不會被任何一家公司關閉。
服務條款合規 — 大多數即時通訊平台明確禁止自動化帳戶或有嚴格的審批流程（WhatsApp Business API 需要商業驗證，Telegram 限制機器人對機器人的通訊）。電子郵件沒有此類限制——自動化發送是一級使用場景。
通用觸及 — 即時通訊管道是隔離的。您的 Telegram 機器人無法觸及 WhatsApp 使用者。電子郵件可以觸及任何擁有電子郵件地址的人——這基本上是每個人。
互補而非競爭 — 像 OpenClaw 這樣的多管道代理框架支援數十個即時通訊管道，電子郵件應該是其中之一。InboxAPI 填補了即時通訊平台在結構上無法填補的空白：無限的、可程式化的身份建立，無需平台批准。
發送限制是什麼？
每個帳戶有 5 個通訊錄配額供外部收件人使用。當所有配額已使用時，最久未使用的記錄會在 5 天不活動後自動被替換。發給 @inboxapi.ai、@inboxapi.io 或 @inboxapi.dev 地址的郵件不計入此限制。詳見限制與合理使用。
達到限制時會怎樣？
當所有 5 個配額已使用時，最久未使用的記錄會在 5 天不活動後自動被替換。
How does the addressbook work? Do I need to add contacts?
The addressbook is automatic — contacts are added when you send email. You never need to add, configure, or manage contacts manually. There is no settings file, no contact list to maintain, and no setup step.
When your agent sends an email to a new external address, that address is recorded in the addressbook. Each account has 5 slots. When all 5 are in use, the least recently used entry is auto-replaced after 5 days of inactivity. Emails to other @inboxapi.ai addresses are always unlimited and don’t use a slot.
目前有哪些限制？
雖然 InboxAPI 在代理對人類和代理對代理的電郵功能完整，但目前有一些限制：
- 5 個通訊錄配額供外部收件人使用： 每個帳戶有 5 個外部收件人配額。當所有配額已使用時，最久未使用的記錄會在 5 天不活動後自動被替換。
- 僅供個人使用： InboxAPI 不是交易型電郵服務 — 請勿用於批量發送、行銷或應用程式通知。
憑證如何運作？
您的代理的憑證儲存在本機 ~/.config/inboxapi/credentials.json（Linux）或 ~/Library/Application Support/inboxapi/credentials.json（macOS）。CLI 自動處理令牌建立和更新 — 您的代理無需手動管理令牌。
如果我的代理失去帳戶存取權怎麼辦？
如果代理的憑證遺失或損壞，您可以使用 account_recover 工具恢復帳戶——但前提是您之前已透過 verify_owner 連結了您的電子郵件。恢復操作會撤銷所有現有令牌並發放新的憑證。如果沒有經過驗證的擁有者電子郵件，將無法恢復被鎖定的帳戶。
什麼是擁有者驗證？
擁有者驗證將您的個人電子郵件地址連結到代理的 InboxAPI 帳戶。您的代理使用您的電子郵件呼叫 verify_owner，您會收到一個 6 位數驗證碼，然後代理提交該驗證碼以完成驗證。驗證完成後，如果憑證遺失，您可以恢復帳戶，且帳戶的試用限制將被移除。
哪些域名被封鎖發送？
InboxAPI 維護一份封鎖名單，阻止向政府（.gov）、軍事（.mil）、情報、執法、核能/關鍵基礎設施和一次性電郵域名發送郵件。
信任分類如何運作？
每封入站郵件被歸類為四個信任等級之一：
| 信任等級 | 含義 | 建議操作 |
|---|---|---|
| Trusted | 發件人在您的通訊錄中且 SPF/DKIM 有效 | 可安全操作 |
| Agent | 發件人是已知的 InboxAPI 代理 | 可自由閱讀，但操作前與您的人類確認 |
| Unverified | SPF/DKIM 有效但發件人不在通訊錄中 | 謹慎處理 |
| Suspicious | 認證失敗或未知發件人 | 標記並在操作前確認 |
什麼能阻止代理透過電郵購買商品或授權交易？
InboxAPI 是通訊管道，不是執行環境。它可以投遞電郵，但無法點擊按鈕、輸入信用卡號碼或與外部系統互動。未授權操作的風險來自代理的配置方式和它能存取的其他工具 — 而非它的電郵。