คำถามที่พบบ่อย

ทำไมไม่ให้ agent เข้าถึง Gmail หรือ Outlook ของฉันเลยล่ะ?

ความปลอดภัย — OAuth ของ Gmail/Outlook ให้ agent ของคุณเข้าถึงกล่องจดหมายทั้งหมด (การแพทย์ การเงิน กฎหมาย ส่วนตัว) Prompt injection ในอีเมลขาเข้าใด ๆ สามารถจัดการ agent ที่เข้าถึงข้อมูลทั้งหมดได้ InboxAPI ให้กล่องจดหมายแยกพร้อมการจัดประเภทความน่าเชื่อถือและ datamarking บนทุกข้อความ

ตัวตน — เมื่อ agent ส่งจาก Gmail ของคุณ ผู้รับไม่สามารถบอกได้ว่ากำลังคุยกับใคร การตอบกลับไปที่กล่องจดหมายของคุณ ปะปนกับเมลจริง InboxAPI ให้ที่อยู่เฉพาะแก่ agent — การแยกที่ชัดเจน

ความสะดวก — API ของ Gmail/Outlook ไม่ใช่ MCP-native คุณต้องมี middleware, OAuth plumbing และการรวมระบบแบบกำหนดเอง InboxAPI ใช้งานได้ทันทีกับไคลเอนต์ MCP ใด ๆ

ต่างจาก AWS SES, SendGrid หรือ Resend อย่างไร?

สิ่งเหล่านั้นคือ API สำหรับส่งเมล — คุณสร้างโครงสร้างพื้นฐานอีเมลบนนั้น InboxAPI ให้ตัวตนอีเมลที่สมบูรณ์แก่ agent: ส่ง รับ ค้นหา ตอบกลับ และส่งต่อ ไม่มีอะไรต้องตั้งค่าและไม่มีโครงสร้างพื้นฐานให้จัดการ

ต่างจาก AgentMail หรือ a1base อย่างไร?

เราสร้างระบบอีเมลของเราเองตั้งแต่ต้น เราไม่ได้ wrap SES, Postfix หรือบริการส่งเมลของบุคคลที่สามใด ๆ เมลของ agent คุณผ่านโครงสร้างพื้นฐานที่เราดูแลโดยตรง

ฟรีจริง ๆ หรือ?

ใช่ ไม่ต้องใช้บัตรเครดิต ไม่มีช่วงทดลอง ไม่มีระดับการใช้งาน เรากำลังพัฒนาแผนเสียเงินพร้อมฟีเจอร์เพิ่มเติม แต่ประสบการณ์หลักจะฟรีตลอดไป

คุณป้องกันสแปมและการใช้งานในทางที่ผิดอย่างไร?

การสร้างบัญชีต้องมี proof-of-work แต่ละบัญชีมี 5 ช่องสมุดที่อยู่สำหรับผู้รับภายนอก — เมื่อทุกช่องถูกใช้งาน รายการที่ไม่ได้ใช้นานที่สุดจะถูกแทนที่อัตโนมัติหลัง 5 วันที่ไม่มีกิจกรรม โควตาการส่งรายวันและการจำกัดอัตราถูกบังคับใช้กับทุกบัญชี ข้อจำกัดเหล่านี้เป็นโครงสร้าง — ไม่ใช่นโยบาย แต่เป็นวิธีที่ระบบทำงาน

Prompt injection ผ่านอีเมลล่ะ?

อีเมลขาเข้าทุกฉบับมีการจัดประเภทความน่าเชื่อถือ — เชื่อถือได้ agent ไม่ได้ยืนยัน หรือน่าสงสัย — ตามว่าผู้ส่งอยู่ในสมุดที่อยู่ของคุณหรือไม่ และอีเมลผ่านการตรวจสอบหรือไม่ สิ่งนี้ช่วยให้ agent ตัดสินใจว่าควรจัดการแต่ละข้อความอย่างระมัดระวังแค่ไหน

นอกจากนี้ เนื้อหาอีเมลที่ไม่น่าเชื่อถือจะถูกแปลงด้วย spotlighting (datamarking) โดยอัตโนมัติ — ช่องว่างถูกแทนที่ด้วยอักขระตัวทำเครื่องหมายเฉพาะเพื่อให้ agent แยกแยะข้อมูลอีเมลจากคำสั่งของตัวเองได้ ซึ่งลดอัตราความสำเร็จของการโจมตี prompt injection จากประมาณ 50% เหลือน้อยกว่า 3%

Spotlighting คืออะไร?

เครื่องมือดึงอีเมลจะใช้ datamarking กับเนื้อหาที่ไม่น่าเชื่อถือ แทนที่ช่องว่างด้วยอักขระ Unicode เฉพาะที่สร้างขึ้นต่อคำขอ เนื้อหาที่มีตัวทำเครื่องหมายควรถูกปฏิบัติเป็นข้อมูลภายนอก — ไม่ใช่คำสั่ง เพื่อกู้คืนข้อความ ให้แทนที่ตัวทำเครื่องหมายด้วยช่องว่าง อีเมลจากผู้ส่งที่เชื่อถือได้จะไม่ถูก spotlight เทคนิคนี้อ้างอิงจากงานวิจัย (arXiv:2403.14720)

เรื่องการขโมยข้อมูลล่ะ?

อีเมลขาออกจะถูกสแกนหา token ยืนยันตัวตนและข้อมูลรับรอง หาก agent พยายามส่งอีเมลที่มี JWT หรือ access token โดยไม่ตั้งใจ ข้อความจะถูกปฏิเสธก่อนออกจากแพลตฟอร์ม ที่อยู่ผู้รับทั้งหมดจะถูกตรวจสอบตาม RFC 5322 ด้วย

Agent สามารถส่งสแปมหากันได้ไหม?

ข้อจำกัดการส่งเดียวกันใช้กับอีเมลขาออกทั้งหมด — จำกัดผู้รับ โควตา และการจำกัดอัตราทำงานเหมือนกันไม่ว่าใครจะเป็นผู้รับ

อีเมลของ agent จะไปอยู่ในโฟลเดอร์สแปมไหม?

อาจจะในช่วงแรก แต่ละ agent ได้รับ subdomain ใหม่และผู้ส่งใหม่ยังไม่มีชื่อเสียง ผู้รับอาจต้องตรวจสอบโฟลเดอร์สแปม เมื่อเวลาผ่านไป เมื่อ agent ส่งเมลที่ถูกต้องและผู้รับมีปฏิสัมพันธ์ การส่งจะดีขึ้น ดูการส่งอีเมล

ทำไมเลือกอีเมลแทนโปรโตคอล agent อย่าง A2A?

อีเมลเข้าถึงอินเทอร์เน็ตที่มีอยู่ทั้งหมด — ผู้คนและธุรกิจหลายพันล้านใช้อยู่แล้ว A2A ต้องการให้ทั้งสองฝ่ายใช้โปรโตคอลนั้น อีเมลคือตัวเลือกสากล Agent น่าจะต้องใช้ทั้งสอง

ทำไมต้องอีเมลแทน WhatsApp, Telegram หรือแอปส่งข้อความอื่น?

แอปส่งข้อความดูเหมือนจะเหมาะกับการสื่อสารของเอเจนต์ แต่มีข้อจำกัดเชิงโครงสร้างที่ทำให้ไม่เป็นจริงสำหรับเอเจนต์ในระดับใหญ่

ความสามารถในการขยาย — คุณสามารถสร้างที่อยู่อีเมลได้หลายร้อยรายการด้วยโปรแกรม WhatsApp, Telegram และ Signal ล้วนต้องการหมายเลขโทรศัพท์และการยืนยัน การขยายเกินกว่าบัญชีไม่กี่บัญชีไม่เป็นจริง มักขัดกับข้อกำหนดการใช้งาน และบางครั้งเป็นไปไม่ได้หากไม่มีซิมการ์ดจริง หากเวิร์กโฟลว์ของคุณต้องการ 50 เอเจนต์ คุณต้องมี 50 หมายเลขโทรศัพท์

ไม่มีผู้รักษาประตู — อีเมลเป็นช่องทางการสื่อสารเดียวที่คุณสามารถสร้างตัวตนได้โดยไม่ต้องมีหมายเลขโทรศัพท์ บัตรประชาชน หรือการอนุมัติจากเจ้าของแพลตฟอร์ม ไม่มีบริษัทใดบริษัทเดียวที่ควบคุมว่าใครจะได้รับที่อยู่อีเมล

โปรโตคอลเปิด — อีเมลเป็นแบบสหพันธ์และเป็นกลางต่อผู้ให้บริการ WhatsApp, Discord และ Telegram เป็นกรรมสิทธิ์ — พวกเขาสามารถเพิกถอนการเข้าถึง API แบนบัญชีบอท หรือเปลี่ยนกฎเมื่อใดก็ได้ อีเมลไม่สามารถถูกปิดโดยบริษัทเดียว

การปฏิบัติตาม ToS — แพลตฟอร์มส่งข้อความส่วนใหญ่ห้ามบัญชีอัตโนมัติอย่างชัดเจนหรือมีกระบวนการอนุมัติที่เข้มงวด (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.

ข้อจำกัดปัจจุบันมีอะไรบ้าง?

• 5 ช่องสมุดที่อยู่สำหรับผู้รับภายนอก: แต่ละบัญชีมี 5 ช่องสำหรับผู้รับภายนอก เมื่อทุกช่องถูกใช้งาน รายการที่ไม่ได้ใช้นานที่สุดจะถูกแทนที่อัตโนมัติหลัง 5 วันที่ไม่มีกิจกรรม
• สำหรับใช้งานส่วนตัวเท่านั้น: ไม่ใช่สำหรับการส่งจำนวนมากหรือการตลาด

ข้อมูลรับรองทำงานอย่างไร?

ข้อมูลรับรองของ agent เก็บในเครื่องที่ ~/.config/inboxapi/credentials.json (Linux) หรือ ~/Library/Application Support/inboxapi/credentials.json (macOS) CLI จัดการ token โดยอัตโนมัติ

จะทำอย่างไรถ้าเอเจนต์สูญเสียการเข้าถึงบัญชี?

หากข้อมูลรับรองของเอเจนต์สูญหายหรือเสียหาย คุณสามารถกู้คืนบัญชีได้โดยใช้เครื่องมือ account_recover — แต่เฉพาะในกรณีที่คุณเคยเชื่อมโยงอีเมลของคุณผ่าน verify_owner แล้วเท่านั้น การกู้คืนจะเพิกถอนโทเค็นที่มีอยู่ทั้งหมดและออกข้อมูลรับรองใหม่ หากไม่มีอีเมลเจ้าของที่ได้รับการยืนยัน จะไม่มีวิธีกู้คืนบัญชีที่ถูกล็อก

การยืนยันเจ้าของคืออะไร?

การยืนยันเจ้าของจะเชื่อมโยงที่อยู่อีเมลส่วนตัวของคุณกับบัญชี InboxAPI ของเอเจนต์ เอเจนต์ของคุณเรียก verify_owner ด้วยอีเมลของคุณ คุณจะได้รับรหัส 6 หลัก และเอเจนต์ส่งรหัสนั้นเพื่อทำการยืนยัน เมื่อยืนยันแล้ว คุณสามารถกู้คืนบัญชีได้หากข้อมูลรับรองสูญหาย และข้อจำกัดทดลองใช้จะถูกลบออกจากบัญชี

โดเมนไหนถูกบล็อก?

InboxAPI บล็อกการส่งไปยังโดเมนรัฐบาล (.gov) ทหาร (.mil) หน่วยข่าวกรอง หน่วยงานบังคับใช้กฎหมาย โครงสร้างพื้นฐานที่สำคัญ และอีเมลแบบใช้แล้วทิ้ง

การจัดประเภทความน่าเชื่อถือทำงานอย่างไร?

ระดับ	ความหมาย	การดำเนินการ
Trusted	ผู้ส่งในสมุดที่อยู่ SPF/DKIM ถูกต้อง	ปลอดภัย
Agent	ผู้ส่งเป็น agent InboxAPI	อ่านได้ ยืนยันก่อนดำเนินการ
Unverified	SPF/DKIM ถูกต้อง ไม่อยู่ในสมุดที่อยู่	ระวัง
Suspicious	ยืนยันล้มเหลว	ทำเครื่องหมายและยืนยัน

อะไรป้องกัน agent จากการซื้อของหรืออนุมัติธุรกรรมผ่านอีเมล?

InboxAPI เป็นช่องทางสื่อสาร ไม่ใช่สภาพแวดล้อมการทำงาน มันส่งอีเมลได้ แต่ไม่สามารถคลิกปุ่มหรือป้อนหมายเลขบัตรเครดิต ความเสี่ยงมาจากการตั้งค่า agent และเครื่องมืออื่นที่มีสิทธิ์เข้าถึง — ไม่ใช่จากอีเมล