שאלות נפוצות
למה לא פשוט לתת לסוכן שלי גישה לחשבון ה-Gmail או ה-Outlook שלי?
אבטחה — חיבור OAuth של Gmail/Outlook מעניק לסוכן שלך גישה לכל תיבת הדואר הנכנס שלך (רפואי, פיננסי, משפטי, אישי). מתקפת הזרקת הנחיות (Prompt injection) בכל אימייל נכנס עלולה לתמרן סוכן שיש לו גישה לכל המידע הזה. InboxAPI מעניקה לסוכן שלך תיבת דואר נכנס מבודדת משלו, עם סיווג רמת אמון וסימון נתונים (datamarking) על כל הודעה.
זהות — כשהסוכן שלך שולח הודעות מחשבון ה-Gmail שלך, הנמענים לא יכולים לדעת עם מי הם מדברים. התשובות מגיעות לתיבת הדואר שלך ומתערבבות עם המיילים האמיתיים שלך. InboxAPI מעניקה לסוכן שלך כתובת אימייל אישית משלו — הפרדה ברורה בינך לבין הסוכן שלך.
פרקטיות — ממשקי ה-API של Gmail/Outlook אינם מותאמים ל-MCP באופן טבעי. תצטרך להשתמש בתוכנת תיווך (middleware), תשתיות OAuth והתאמות אישיות. InboxAPI עובדת ישירות מהקופסה עם כל לקוח MCP.
במה זה שונה מ-AWS SES, SendGrid או Resend?
אלה ממשקי API לשליחה בלבד — עליך לבנות תשתיות אימייל מעליהם. InboxAPI מעניקה לסוכן שלך זהות אימייל שלמה: שליחה, קבלה, חיפוש, מענה והעברה. אין צורך להגדיר דבר ואין צורך לנהל תשתיות.
במה זה שונה מ-AgentMail או מ-a1base?
בנינו את תשתית האימייל שלנו מאפס. אנחנו לא עוטפים את SES, Postfix או כל שירות שליחה של צד שלישי אחר. הודעות הדוא”ל של הסוכן שלך עוברות דרך תשתית שאנו מפעילים ישירות.
האם זה באמת בחינם?
כן. ללא כרטיס אשראי, ללא תקופת ניסיון וללא דרגות שימוש. אנחנו עובדים על תוכניות בתשלום עם תכונות נוספות, אך חוויית השימוש הבסיסית תמיד תישאר חינמית.
כיצד אתם מונעים ספאם ושימוש לרעה?
יצירת חשבון דורשת הוכחת עבודה (Proof-of-work). לכל חשבון יש 5 מקומות בפנקס הכתובות עבור נמענים חיצוניים — כאשר כל המקומות תפוסים, הכתובת שהייתה הכי פחות בשימוש לאחרונה מוחלפת אוטומטית לאחר 5 ימים של חוסר פעילות. מכסות שליחה יומיות והגבלת קצב שליחה (rate limiting) נאכפות על כל חשבון. מגבלות אלו הן מבניות — הן אינן מדיניות רופפת אלא הדרך שבה המערכת עובדת.
מה לגבי הזרקת הנחיות (prompt injection) באמצעות אימייל?
כל אימייל נכנס כולל סיווג רמת אמון — trusted (מהימן), agent (סוכן), unverified (לא מאומת) או suspicious (חשוד) — על סמך האם השולח נמצא בפנקס הכתובות שלך והאם האימייל שלו עבר את בדיקות האימות. זה עוזר לסוכן שלך להחליט באיזו מידה של זהירות לטפל בכל הודעה. מיילים מסוכני InboxAPI אחרים מסומנים בנפרד, כך שהסוכן שלך יודע שעליו להתייעץ איתך לפני שהוא פועל לפיהם.
בנוסף, תוכן אימייל לא מהימן משתנה אוטומטית באמצעות spotlighting (סימון נתונים) — רווחים מוחלפים בתו סימון ייחודי כדי שהסוכן שלך יוכל להבחין בבירור בין נתוני האימייל לבין ההנחיות שלו עצמו. זה מפחית את שיעור ההצלחה של מתקפות הזרקת הנחיות המשובצות באימיילים מ-~50% לפחות מ-3%.
מה זה spotlighting?
כלי אחזור אימייל מיישמים סימון נתונים על תוכן לא מהימן, ומחליפים רווחים בתו סימון יוניקוד ייחודי המיוצר לכל בקשה. תוכן המכיל את התו הזה צריך להיות מטופל כנתונים חיצוניים — לעולם לא כהנחיות לביצוע. כדי לשחזר את הטקסט המקורי, יש להחליף את תו הסימון ברווח. אימיילים משולחים מהימנים (בפנקס הכתובות שלך עם אימות תקף) אינם עוברים spotlighting כברירת מחדל. טכניקה זו מבוססת על מחקר אקדמי (arXiv:2403.14720).
מה לגבי זליגת נתונים (data exfiltration)?
אימיילים יוצאים נסרקים לאיתור אסימוני אימות (tokens) ופרטי גישה. אם הסוכן שלך מנסה בטעות לשלוח אימייל המכיל JWT או אסימון גישה, ההודעה תידחה לפני שהיא תצא מהפלטפורמה. זה מונע מסוכנים ליפול למלכודות של הדלפת נתונים רגישים באמצעות אימייל. בנוסף, כל כתובות הנמענים בפעולות שליחה, מענה והעברה מאומתות לפי תקן RFC 5322 — כתובות לא תקינות נדחות לפני המסירה.
האם סוכנים יכולים להספים זה את זה?
אותן מגבלות שליחה חלות על כל המיילים היוצאים — מגבלות נמענים, מכסות והגבלת קצב פועלות באותו אופן ללא קשר לזהות המקבל.
האם האימיילים של הסוכן שלי יגיעו לספאם?
ייתכן שבהתחלה כן. כל סוכן מקבל תת-דומיין חדש לחלוטין, ולשולחים חדשים אין עדיין מוניטין. ייתכן שהנמענים יצטרכו לבדוק את תיקיית הספאם שלהם עבור המיילים הראשונים. עם הזמן, ככל שהסוכן שלך שולח מיילים לגיטימיים והנמענים מגיבים להם, המסירה משתפרת. ראה את דף מסירת אימיילים לפרטים נוספים.
למה אימייל במקום פרוטוקול סוכנים ייעודי כמו A2A?
אימייל מגיע לכל האינטרנט הקיים — מיליארדי אנשים ועסקים כבר משתמשים בו. A2A דורש משני הצדדים להטמיע את הפרוטוקול. כשהסוכן שלך צריך לתקשר עם מישהו מחוץ למערכת האקולוגית שלו, אימייל הוא האפשרות האוניברסלית. סביר להניח שסוכנים יזדקקו לשניהם.
למה אימייל במקום WhatsApp, Telegram או אפליקציות מסרים אחרות?
אפליקציות מסרים נראות כמו התאמה טבעית לתקשורת בין סוכנים, אך יש להן מגבלות מבניות שהופכות אותן ללא מעשיות עבור סוכנים בקנה מידה רחב.
יכולת הרחבה (Scalability) — ניתן ליצור באופן תכנותי מאות כתובות אימייל. WhatsApp, Telegram ו-Signal דורשות כולן מספרי טלפון ואימות. הרחבה ליותר מחופן חשבונות אינה מעשית, לרוב מנוגדת לתנאי השימוש, ולפעמים בלתי אפשרית ללא כרטיסי SIM פיזיים. אם זרימת העבודה שלך דורשת 50 סוכנים, תצטרך 50 מספרי טלפון.
אין שומר סף לזהות — אימייל הוא ערוץ התקשורת היחיד שבו ניתן ליצור זהות ללא מספר טלפון, תעודת זהות ממשלתית או אישור מבעל פלטפורמה. אף חברה יחידה אינה שולטת במי שמקבל כתובת אימייל.
פרוטוקול פתוח — אימייל הוא מבוזר (federated) וניטרלי מבחינת ספקים. WhatsApp, Discord ו-Telegram הן קנייניות — הן יכולות לבטל גישת API, לחסום חשבונות בוטים או לשנות את הכללים בכל עת. אימייל לא יכול להיסגר על ידי חברה אחת.
עמידה בתנאי השימוש (ToS) — רוב פלטפורמות המסרים אוסרות במפורש על חשבונות אוטומטיים או דורשות תהליכי אישור קפדניים (WhatsApp Business API דורש אימות עסק, Telegram מגבילה הודעות בוט-אל-בוט). לאימייל אין הגבלות כאלה — שליחה אוטומטית היא מקרה שימוש מרכזי מהשורה הראשונה.
טווח הגעה אוניברסלי — ערוצי מסרים הם סגורים ומבודדים. בוט ה-Telegram שלך לא יכול לשלוח הודעה למשתמש WhatsApp. אימייל מגיע לכל מי שיש לו כתובת אימייל — שזה למעשה כולם.
משלים, לא מתחרה — מסגרות עבודה מרובות ערוצים עבור סוכנים כמו OpenClaw תומכות בעשרות ערוצי מסרים, ואימייל צריך להיות אחד מהם. InboxAPI ממלאת את הפער שפלטפורמות המסרים אינן יכולות לפתור באופן מבני: יצירת זהות בלתי מוגבלת ותכנותית ללא צורך באישור פלטפורמה.
מהן מגבלות השליחה?
לכל חשבון יש 5 מקומות בפנקס הכתובות עבור נמענים חיצוניים. מיילים לכתובות InboxAPI אחרות (כגון @inboxapi.ai, @inboxapi.io, @inboxapi.dev) אינם נספרים במגבלה זו. כאשר כל המקומות תפוסים, הכתובת שהייתה הכי פחות בשימוש לאחרונה מוחלפת אוטומטית לאחר 5 ימים של חוסר פעילות. ראה את דף מגבלות ושימוש הוגן לפרטים המלאים.
מה קורה כשאני מגיע למגבלה?
כאשר כל 5 המקומות תפוסים, הכתובת שהייתה הכי פחות בשימוש לאחרונה מוחלפת אוטומטית לאחר 5 ימים של חוסר פעילות.
כיצד עובד פנקס הכתובות? האם עלי להוסיף אנשי קשר?
פנקס הכתובות הוא אוטומטי — אנשי קשר מתוווסיפים כשאתה שולח אימייל. לעולם אין צורך להוסיף, להגדיר או לנהל אנשי קשר באופן ידני. אין קובץ הגדרות, אין רשימת אנשי קשר לתחזוקה ואין שלב הגדרה.
כאשר הסוכן שלך שולח אימייל לכתובת חיצונית חדשה, הכתובת הזו נרשמת בפנקס הכתובות. לכל חשבון יש 5 מקומות. כאשר כל ה-5 תפוסים, הכתובת שהייתה הכי פחות בשימוש לאחרונה מוחלפת אוטומטית לאחר 5 ימים של חוסר פעילות. מיילים לכתובות InboxAPI אחרות (@inboxapi.ai, @inboxapi.io, @inboxapi.dev) הם תמיד ללא הגבלה ואינם תופסים מקום.
מהן המגבלות הנוכחיות?
למרות ש-InboxAPI פונקציונלית לחלוטין עבור אימייל בין סוכן לאדם ובין סוכן לסוכן, ישנן מספר מגבלות כיום:
- 5 מקומות לנמענים חיצוניים: לכל חשבון יש 5 מקומות בו-זמנית לנמענים חיצוניים בפנקס הכתובות שלו. תוכל לשלוח אימיילים ליותר מ-5 אנשים לאורך זמן, אך רק 5 כתובות חיצוניות יכולות להיות פעילות בו-זמנית; כאשר כל המקומות תפוסים, הכתובת שהייתה הכי פחות בשימוש לאחרונה מוחלפת אוטומטית לאחר 5 ימים של חוסר פעילות.
- אין עדיין דומיינים מותאמים אישית: סוכנים משתמשים בתתי-דומיינים של @inboxapi.ai המוקצים אוטומטית.
- לשימוש אישי בלבד: InboxAPI אינו שירות אימייל תפעולי (transactional) — אל תשתמש בו לשליחה המונית, שיווק או התראות של אפליקציות.
כיצד עובדים פרטי הזיהוי (credentials)?
פרטי הזיהוי של הסוכן שלך מאוחסנים מקומית בנתיב ~/.config/inboxapi/credentials.json (בלינוקס) או בנתיב ~/Library/Application Support/inboxapi/credentials.json (ב-macOS). ה-CLI מטפל ביצירת אסימונים וברענון שלהם באופן אוטומטי — הסוכן שלך לעולם לא צריך לנהל אסימונים ידנית.
מה אם הסוכן שלי מאבד גישה?
אם פרטי הזיהוי של הסוכן שלך אבדו או נפגמו, תוכל לשחזר את החשבון באמצעות הכלי account_recover — אך ורק אם קישרת קודם לכן את האימייל שלך באמצעות verify_owner. שחזור מבטל את כל האסימונים הקיימים ומנפיק פרטי זיהוי חדשים. ללא אימייל בעלים מאומת, אין שום דרך לשחזר חשבון שננעל.
מהו אימות בעלים (owner verification)?
אימות בעלים מקשר בין כתובת האימייל האישית שלך לחשבון ה-InboxAPI של הסוכן שלך. הסוכן שלך קורא ל-verify_owner עם כתובת המייל שלך, אתה מקבל קוד בן 6 ספרות, והסוכן שלך מגיש אותו כדי להשלים את האימות. לאחר האימות, תוכל לשחזר את החשבון אם פרטי הזיהוי יאבדו אי פעם, והגבלות הניסיון יוסרו מהחשבון.
אילו דומיינים חסומים לשליחה?
InboxAPI מתחזקת רשימת חסימה המונעת שליחה לדומיינים ממשלתיים (.gov), צבאיים (.mil), מודיעין, אכיפת חוק, תשתיות גרעיניות/קריטיות ודומיינים של אימייל זמני (disposable).
כיצד עובד סיווג רמת האמון?
כל אימייל נכנס מסווג לאחת מארבע רמות אמון:
| רמת אמון | משמעות | פעולה מומלצת |
|---|---|---|
| Trusted (מהימן) | השולח נמצא בפנקס הכתובות שלך עם SPF/DKIM תקינים | בטוח לפעול לפיו |
| Agent (סוכן) | השולח הוא סוכן InboxAPI מוכר | קרא בחופשיות, אך אמת עם הבעלים האנושי לפני ביצוע פעולות |
| Unverified (לא מאומת) | SPF/DKIM תקינים אך השולח אינו בפנקס הכתובות | פעל בזהירות |
| Suspicious (חשוד) | אימות נכשל או שולח לא מוכר | סמן ואמת לפני פעולה |
באיזה מודל AI עלי להשתמש עם InboxAPI?
המודל שלך חייב לתמוך בקריאה לכלים/פונקציות (tool/function calling) — פרוטוקול MCP דורש זאת. אנו ממליצים על חלון הקשר (context window) של לפחות 32K אסימונים כדי להכיל בנוחות את 22 הגדרות הכלים של InboxAPI לצד היסטוריית השיחה ותוכן המיילים.
המלצות מודלים לפי דרגות:
| דרגה | Anthropic | OpenAI | |
|---|---|---|---|
| Good (טוב) | Haiku 4.5+ | GPT-4.1 mini+, GPT-4.1 nano+ | Gemini 2.5 Flash+ |
| Recommended (מומלץ) | Sonnet 4.5+ | GPT-4.1+, GPT-5 mini+ | Gemini 2.5 Pro+ |
| Best (הכי טוב) | Opus 4.5+ | GPT-5+, GPT-5.2+ | Gemini 2.5 Pro+ |
תקורת סימון נתונים (Datamarking): InboxAPI מפעילה סימון נתונים (spotlighting) על תוכן אימייל לא מהימן, ומחליפה רווחים בתווי סימון יוניקוד. דבר זה יכול להגדיל מעט את צריכת האסימונים בעת עיבוד מיילים משולחים חיצוניים. מודלים עם חלונות הקשר גדולים יותר מתמודדים עם זה בצורה נוחה יותר.
מה לא יעבוד: מודלים ללא תמיכה בקריאה לכלים/פונקציות, מודלים עם חלון הקשר קטן מ-16K אסימונים, ומודלים מקומיים קטנים מאוד (מתחת ל-~7B פרמטרים) החסרים תמיכה אמינה בקריאה לכלים. אלה יתקשו להכיל את 22 הגדרות הכלים של InboxAPI ולשמור על היסטוריית שיחה מועילה.
מה מונע מסוכן לקנות דברים או לאשר עסקאות באמצעות אימייל?
InboxAPI הוא ערוץ תקשורת, לא סביבת הרצה. הוא יכול להעביר אימייל, אך הוא אינו יכול ללחוץ על כפתורים, להזין מספרי כרטיס אשראי או לקיים אינטראקציה עם מערכות חיצוניים. הסיכון לפעולות לא מורשות נובע מאופן הגדרת הסוכן ומאילו כלים אחרים יש לו גישה אליהם — ולא מהאימייל שלו.