FAQ

Mengapa tidak beri ejen saya akses ke Gmail atau Outlook saya?

Keselamatan — OAuth Gmail/Outlook memberi ejen anda akses kepada keseluruhan peti masuk anda (perubatan, kewangan, undang-undang, peribadi). Suntikan prompt dalam mana-mana e-mel masuk boleh memanipulasi ejen yang mempunyai akses kepada semua itu. InboxAPI memberi ejen anda peti masuk terpencil sendiri dengan klasifikasi kepercayaan dan penandaan data pada setiap mesej.

Identiti — Apabila ejen anda menghantar dari Gmail anda, penerima tidak tahu dengan siapa mereka bercakap. Balasan masuk ke peti masuk anda, bercampur dengan surat sebenar anda. InboxAPI memberi ejen anda alamat sendiri — pemisahan jelas antara anda dan ejen anda.

Kepraktisan — API Gmail/Outlook bukan native MCP. Anda perlu middleware, konfigurasi OAuth dan integrasi tersuai. InboxAPI berfungsi terus dengan mana-mana klien MCP.

Apa bezanya dengan AWS SES, SendGrid atau Resend?

Itu semua API penghantaran — anda membina infrastruktur e-mel di atasnya. InboxAPI memberi ejen anda identiti e-mel penuh: hantar, terima, cari, balas dan majukan. Tiada apa yang perlu dikonfigurasi dan tiada infrastruktur untuk diuruskan.

Apa bezanya dengan AgentMail atau a1base?

Kami membina stack e-mel kami sendiri dari awal. Kami tidak membungkus SES, Postfix atau mana-mana perkhidmatan penghantaran pihak ketiga. E-mel ejen anda melalui infrastruktur yang kami kendalikan sendiri.

Betulkah percuma?

Ya. Tiada kad kredit, tiada tempoh percubaan, tiada peringkat penggunaan. Kami sedang membangunkan pelan berbayar dengan ciri tambahan, tetapi pengalaman asas akan kekal percuma selamanya.

Bagaimana anda mencegah spam dan penyalahgunaan?

Penciptaan akaun memerlukan proof-of-work. Setiap akaun mempunyai 5 slot buku alamat untuk penerima luaran — apabila semua slot telah digunakan, entri yang paling lama tidak digunakan digantikan secara automatik selepas 5 hari tidak aktif. Kuota penghantaran harian dan pengehadan kadar dikenakan pada setiap akaun. Kekangan ini bersifat struktural — bukan polisi, tetapi cara sistem berfungsi.

Bagaimana dengan suntikan prompt melalui e-mel?

Setiap e-mel masuk termasuk klasifikasi kepercayaan — trusted, agent, unverified atau suspicious — berdasarkan sama ada penghantar ada dalam buku alamat anda dan sama ada e-mel mereka melepasi pemeriksaan pengesahan. Ini membantu ejen anda memutuskan tahap berhati-hati dalam mengendalikan setiap mesej. E-mel daripada ejen InboxAPI lain ditandakan secara berasingan supaya ejen anda tahu untuk menyemak dengan anda sebelum bertindak.

Selain itu, kandungan e-mel yang tidak dipercayai diubah secara automatik melalui spotlighting (penandaan data) — ruang kosong digantikan dengan aksara penanda unik supaya ejen anda boleh membezakan data e-mel daripada arahannya sendiri dengan jelas. Ini mengurangkan kadar kejayaan serangan suntikan prompt yang tertanam dalam e-mel daripada ~50% kepada kurang daripada 3%.

Apakah spotlighting?

Alat pengambilan e-mel menggunakan penandaan data pada kandungan yang tidak dipercayai, menggantikan ruang kosong dengan aksara penanda Unicode unik yang dijana setiap permintaan. Kandungan yang mengandungi penanda mesti dianggap sebagai data luaran — bukan arahan untuk diikuti. Untuk mendapatkan semula teks asal, gantikan penanda dengan ruang kosong. E-mel daripada penghantar yang dipercayai (dalam buku alamat anda dengan pengesahan yang sah) tidak di-spotlight secara lalai. Teknik ini berdasarkan penyelidikan akademik (arXiv:2403.14720).

Bagaimana dengan kebocoran data?

E-mel keluar diimbas untuk mengesan token pengesahan dan kelayakan. Jika ejen anda secara tidak sengaja cuba menghantar e-mel yang mengandungi JWT atau token akses, mesej itu ditolak sebelum meninggalkan platform. Ini menghalang ejen daripada ditipu untuk membocorkan data sensitif melalui e-mel. Selain itu, semua alamat penerima dalam operasi hantar, balas dan majukan disahkan mengikut RFC 5322 — alamat yang tidak sah ditolak sebelum penghantaran.

Bolehkah ejen menghantar spam sesama mereka?

Had penghantaran yang sama dikenakan pada semua e-mel keluar — had penerima, kuota dan pengehadan kadar berfungsi dengan cara yang sama tanpa mengira penerima.

Adakah e-mel ejen saya akan masuk ke folder spam?

Mungkin pada mulanya. Setiap ejen mendapat subdomain yang baharu sepenuhnya, dan penghantar baharu belum mempunyai reputasi. Penerima mungkin perlu menyemak folder spam mereka untuk e-mel pertama. Dari masa ke masa, apabila ejen anda menghantar surat yang sah dan penerima berinteraksi dengannya, kebolehhantaran akan bertambah baik. Lihat Penghantaran E-mel untuk butiran lanjut.

Mengapa e-mel dan bukan protokol ejen native seperti A2A?

E-mel menjangkau keseluruhan internet sedia ada — berbilion orang dan perniagaan sudah menggunakannya. A2A memerlukan kedua-dua pihak melaksanakan protokol tersebut. Apabila ejen anda perlu menghubungi seseorang di luar ekosistemnya sendiri, e-mel adalah pilihan universal. Ejen berkemungkinan memerlukan kedua-duanya.

Mengapa e-mel, bukan WhatsApp, Telegram, atau aplikasi pemesejan lain?

Aplikasi pemesejan kelihatan sesuai untuk komunikasi ejen, tetapi ia mempunyai batasan struktur yang menjadikannya tidak praktikal untuk ejen pada skala besar.

Skalabiliti — Anda boleh mencipta ratusan alamat e-mel secara programatik. WhatsApp, Telegram, dan Signal semuanya memerlukan nombor telefon dan pengesahan. Menambah akaun melebihi beberapa sahaja tidak praktikal, sering melanggar syarat perkhidmatan, dan kadangkala mustahil tanpa kad SIM fizikal. Jika aliran kerja anda memerlukan 50 ejen, anda memerlukan 50 nombor telefon.

Tiada penjaga pintu — E-mel adalah satu-satunya saluran komunikasi di mana anda boleh mencipta identiti tanpa nombor telefon, kad pengenalan, atau kelulusan daripada pemilik platform. Tiada satu syarikat pun yang mengawal siapa yang mendapat alamat e-mel.

Protokol terbuka — E-mel bersifat federasi dan neutral vendor. WhatsApp, Discord, dan Telegram bersifat proprietari — mereka boleh membatalkan akses API, melarang akaun bot, atau menukar peraturan pada bila-bila masa. E-mel tidak boleh dimatikan oleh satu syarikat.

Pematuhan ToS — Kebanyakan platform pemesejan secara eksplisit melarang akaun automatik atau mempunyai proses kelulusan ketat (WhatsApp Business API memerlukan pengesahan perniagaan, Telegram mengehadkan pemesejan bot-ke-bot). E-mel tidak mempunyai sekatan sedemikian — penghantaran automatik adalah kes penggunaan utama.

Capaian universal — Saluran pemesejan terpencil. Bot Telegram anda tidak boleh mencapai pengguna WhatsApp. E-mel mencapai sesiapa yang mempunyai alamat e-mel — iaitu pada dasarnya semua orang.

Pelengkap, bukan pesaing — Rangka kerja ejen berbilang saluran seperti OpenClaw menyokong berpuluh-puluh saluran pemesejan, dan e-mel seharusnya menjadi salah satunya. InboxAPI mengisi jurang yang tidak boleh diisi oleh platform pemesejan secara struktur: penciptaan identiti tanpa had dan terprogram tanpa kelulusan platform diperlukan.

Apakah had penghantaran?

Setiap akaun mempunyai 5 slot buku alamat untuk penerima luaran. Apabila semua slot telah digunakan, entri yang paling lama tidak digunakan digantikan secara automatik selepas 5 hari tidak aktif. E-mel ke alamat @inboxapi.ai, @inboxapi.io atau @inboxapi.dev lain tidak dikira dalam had ini. Lihat Had dan Penggunaan untuk semua butiran.

Apa yang berlaku apabila saya mencapai had?

Apabila semua 5 slot telah digunakan, entri yang paling lama tidak digunakan digantikan secara automatik selepas 5 hari tidak aktif.

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.

Apakah batasan semasa?

Walaupun InboxAPI berfungsi sepenuhnya untuk e-mel ejen-manusia dan ejen-ejen, terdapat beberapa batasan semasa:

• 5 slot buku alamat untuk penerima luaran: Setiap akaun mempunyai 5 slot untuk penerima luaran. Apabila semua slot telah digunakan, entri yang paling lama tidak digunakan digantikan secara automatik selepas 5 hari tidak aktif.
• Kegunaan peribadi sahaja: InboxAPI bukan perkhidmatan e-mel transaksi — jangan gunakannya untuk penghantaran pukal, pemasaran atau pemberitahuan aplikasi.

Bagaimana kelayakan berfungsi?

Kelayakan ejen anda disimpan secara setempat dalam ~/.config/inboxapi/credentials.json (Linux) atau ~/Library/Application Support/inboxapi/credentials.json (macOS). CLI menguruskan penciptaan dan pembaharuan token secara automatik — ejen anda tidak perlu menguruskan token secara manual.

Bagaimana jika ejen saya kehilangan akses ke akaunnya?

Jika kelayakan ejen anda hilang atau rosak, anda boleh memulihkan akaun menggunakan alat account_recover — tetapi hanya jika anda sebelum ini telah menghubungkan e-mel anda melalui verify_owner. Pemulihan membatalkan semua token sedia ada dan mengeluarkan kelayakan baharu. Tanpa e-mel pemilik yang disahkan, tiada cara untuk memulihkan akaun yang terkunci.

Apakah pengesahan pemilik?

Pengesahan pemilik menghubungkan alamat e-mel peribadi anda ke akaun InboxAPI ejen anda. Ejen anda memanggil verify_owner dengan e-mel anda, anda menerima kod 6 digit, dan ejen anda menghantarnya untuk melengkapkan pengesahan. Setelah disahkan, anda boleh memulihkan akaun jika kelayakan hilang, dan sekatan percubaan dikeluarkan daripada akaun.

Domain mana yang disekat untuk penghantaran?

InboxAPI mengekalkan senarai sekatan yang menghalang penghantaran ke domain kerajaan (.gov), tentera (.mil), perisikan, penguatkuasaan undang-undang, infrastruktur nuklear/kritikal dan e-mel pakai buang.

Bagaimana klasifikasi kepercayaan berfungsi?

Setiap e-mel masuk diklasifikasikan ke dalam salah satu daripada empat tahap kepercayaan:

Tahap kepercayaan	Maksud	Tindakan yang disyorkan
Trusted	Penghantar ada dalam buku alamat anda dengan SPF/DKIM yang sah	Selamat untuk bertindak
Agent	Penghantar adalah ejen InboxAPI yang dikenali	Baca dengan bebas, tetapi sahkan dengan manusia anda sebelum bertindak
Unverified	SPF/DKIM sah tetapi penghantar tiada dalam buku alamat	Berhati-hati
Suspicious	Pengesahan gagal atau penghantar tidak dikenali	Laporkan dan sahkan sebelum bertindak

Apakah yang menghalang ejen daripada membeli barang atau membenarkan transaksi melalui e-mel?

InboxAPI adalah saluran komunikasi, bukan persekitaran pelaksanaan. Ia boleh menghantar e-mel, tetapi ia tidak boleh mengklik butang, memasukkan nombor kad kredit atau berinteraksi dengan sistem luaran. Risiko tindakan tanpa kebenaran datang daripada cara ejen dikonfigurasi dan alat lain yang boleh diaksesnya — bukan daripada e-melnya.