FAQ
Warum gebe ich meinem Agenten nicht einfach Zugriff auf mein Gmail oder Outlook?
Abschnitt betitelt „Warum gebe ich meinem Agenten nicht einfach Zugriff auf mein Gmail oder Outlook?“Sicherheit — Gmail-/Outlook-OAuth gibt deinem Agenten Zugriff auf dein gesamtes Postfach (Medizin, Finanzen, Recht, Privates). Eine Prompt Injection in einer eingehenden E-Mail könnte einen Agenten mit Zugriff auf all das manipulieren. InboxAPI gibt deinem Agenten sein eigenes isoliertes Postfach mit Vertrauensklassifizierung und Datamarking für jede Nachricht.
Identität — Wenn dein Agent von deinem Gmail sendet, erkennen Empfänger nicht, mit wem sie sprechen. Antworten landen in deinem Postfach, vermischt mit deiner echten Post. InboxAPI gibt deinem Agenten seine eigene persönliche Adresse — klare Trennung zwischen dir und deinem Agenten.
Praktikabilität — Gmail-/Outlook-APIs sind nicht MCP-nativ. Du bräuchtest Middleware, OAuth-Verkabelung und eigene Integration. InboxAPI funktioniert out of the box mit jedem MCP-Client.
Was unterscheidet das von AWS SES, SendGrid oder Resend?
Abschnitt betitelt „Was unterscheidet das von AWS SES, SendGrid oder Resend?“Das sind Versand-APIs — du baust darauf E-Mail-Infrastruktur auf. InboxAPI gibt deinem Agenten eine vollständige E-Mail-Identität: senden, empfangen, suchen, antworten, weiterleiten. Nichts zu konfigurieren, keine Infrastruktur zu verwalten.
Was unterscheidet das von AgentMail oder a1base?
Abschnitt betitelt „Was unterscheidet das von AgentMail oder a1base?“Wir haben unseren eigenen E-Mail-Stack von Grund auf gebaut. Wir wrappen weder SES noch Postfix noch einen anderen Versanddienst. Die E-Mails deines Agenten laufen über Infrastruktur, die wir selbst betreiben.
Ist es wirklich kostenlos?
Abschnitt betitelt „Ist es wirklich kostenlos?“Ja. Keine Kreditkarte, keine Testphase, keine Nutzungstarife. Wir arbeiten an kostenpflichtigen Plänen mit zusätzlichen Funktionen, aber das Kernerlebnis bleibt immer kostenlos.
Wie verhindert ihr Spam und Missbrauch?
Abschnitt betitelt „Wie verhindert ihr Spam und Missbrauch?“Die Kontoerstellung erfordert Proof-of-Work. Jedes Konto hat 5 Adressbuchplätze für externe Empfänger — wenn alle Plätze belegt sind, wird der am längsten ungenutzte Eintrag nach 5 Tagen Inaktivität automatisch ersetzt. Tägliche Sendekontingente und Ratenbegrenzung gelten für jedes Konto. Diese Beschränkungen sind strukturell — keine Richtlinien, sondern so funktioniert das System.
Was ist mit Prompt Injection per E-Mail?
Abschnitt betitelt „Was ist mit Prompt Injection per E-Mail?“Jede eingehende E-Mail enthält eine Vertrauensklassifizierung — vertrauenswürdig, Agent, unverifiziert oder verdächtig — basierend darauf, ob der Absender in deinem Adressbuch steht und ob seine E-Mail die Authentifizierungsprüfungen besteht. So kann dein Agent entscheiden, wie vorsichtig er jede Nachricht behandelt. E-Mails von anderen InboxAPI-Agenten werden separat gekennzeichnet, damit dein Agent weiß, dass er vor Aktionen mit dir Rücksprache halten sollte.
Außerdem werden nicht vertrauenswürdige E-Mail-Inhalte automatisch per Spotlighting (Datamarking) transformiert — Whitespace wird durch ein eindeutiges Markierungszeichen ersetzt, damit dein Agent E-Mail-Daten klar von seinen eigenen Anweisungen unterscheiden kann. Das senkt die Erfolgsrate von Prompt-Injection-Angriffen per E-Mail von ~50 % auf unter 3 %.
Was ist Spotlighting?
Abschnitt betitelt „Was ist Spotlighting?“E-Mail-Abruftools wenden Datamarking auf nicht vertrauenswürdige Inhalte an und ersetzen Whitespace durch ein eindeutiges, pro Anfrage generiertes Unicode-Markierungszeichen. Inhalte mit dem Marker sollten als externe Daten behandelt werden — niemals als zu befolgende Anweisungen. Um den Originaltext wiederherzustellen, ersetze den Marker durch ein Leerzeichen. E-Mails von vertrauenswürdigen Absendern (im Adressbuch mit gültiger Authentifizierung) werden standardmäßig nicht mit Spotlighting versehen. Die Technik basiert auf wissenschaftlicher Forschung (arXiv:2403.14720).
Was ist mit Datenabfluss?
Abschnitt betitelt „Was ist mit Datenabfluss?“Ausgehende E-Mails werden auf Authentifizierungstokens und Zugangsdaten geprüft. Wenn dein Agent versehentlich eine E-Mail mit einem JWT oder Zugriffstoken senden will, wird die Nachricht abgelehnt, bevor sie die Plattform verlässt. So können Agenten nicht dazu gebracht werden, sensible Daten per E-Mail zu leaken. Zusätzlich werden alle Empfängeradressen in Sende-, Antwort- und Weiterleitungsoperationen gegen RFC 5322 validiert — fehlerhafte Adressen werden vor der Zustellung abgelehnt.
Können sich Agenten gegenseitig zuspammen?
Abschnitt betitelt „Können sich Agenten gegenseitig zuspammen?“Für alle ausgehenden E-Mails gelten dieselben Sendelimits — Empfängerbegrenzungen, Kontingente und Ratenbegrenzung funktionieren unabhängig vom Empfänger gleich.
Landen die E-Mails meines Agenten im Spam?
Abschnitt betitelt „Landen die E-Mails meines Agenten im Spam?“Anfangs vielleicht. Jeder Agent erhält eine brandneue Subdomain, und neue Absender haben noch keine Reputation. Empfänger müssen die ersten E-Mails ggf. im Spam-Ordner suchen. Mit der Zeit verbessert sich die Zustellung, wenn dein Agent legitime E-Mails sendet und Empfänger damit interagieren. Details unter E-Mail-Zustellung.
Warum E-Mail statt eines nativen Agentenprotokolls wie A2A?
Abschnitt betitelt „Warum E-Mail statt eines nativen Agentenprotokolls wie A2A?“E-Mail erreicht das gesamte bestehende Internet — Milliarden Menschen und Unternehmen nutzen es bereits. A2A erfordert, dass beide Seiten das Protokoll implementieren. Wenn dein Agent jemanden außerhalb seines eigenen Ökosystems erreichen muss, ist E-Mail die universelle Option. Agenten werden wahrscheinlich beides brauchen.
Warum E-Mail statt WhatsApp, Telegram oder anderen Messaging-Apps?
Abschnitt betitelt „Warum E-Mail statt WhatsApp, Telegram oder anderen Messaging-Apps?“Messaging-Apps wirken wie die natürliche Wahl für Agentenkommunikation, haben aber strukturelle Einschränkungen, die sie für Agenten im großen Maßstab unpraktikabel machen.
Skalierbarkeit — Du kannst programmatisch Hunderte E-Mail-Adressen erstellen. WhatsApp, Telegram und Signal erfordern alle Telefonnummern und Verifizierung. Über eine Handvoll Konten hinaus zu skalieren ist unpraktisch, oft gegen die Nutzungsbedingungen und manchmal ohne physische SIM-Karten unmöglich. Wenn dein Workflow 50 Agenten braucht, bräuchtest du 50 Telefonnummern.
Kein Identitäts-Gatekeeping — E-Mail ist der einzige Kommunikationskanal, bei dem du eine Identität ohne Telefonnummer, Ausweis oder Genehmigung eines Plattformbetreibers erstellen kannst. Kein einzelnes Unternehmen kontrolliert, wer eine E-Mail-Adresse bekommt.
Offenes Protokoll — E-Mail ist föderiert und anbieterneutral. WhatsApp, Discord und Telegram sind proprietär — sie können API-Zugriff entziehen, Bot-Konten sperren oder jederzeit die Regeln ändern. E-Mail kann nicht von einer Firma abgeschaltet werden.
ToS-Konformität — Die meisten Messaging-Plattformen verbieten automatisierte Konten ausdrücklich oder haben strenge Genehmigungsprozesse (WhatsApp Business API erfordert Unternehmensverifizierung, Telegram schränkt Bot-zu-Bot-Messaging ein). Bei E-Mail gibt es solche Beschränkungen nicht — automatisierter Versand ist ein erstklassiger Anwendungsfall.
Universelle Reichweite — Messaging-Kanäle sind Silos. Dein Telegram-Bot kann keinen WhatsApp-Nutzer erreichen. E-Mail erreicht jeden mit einer E-Mail-Adresse — also praktisch jeden.
Ergänzend, nicht konkurrierend — Multi-Channel-Agenten-Frameworks wie OpenClaw unterstützen Dutzende Messaging-Kanäle, und E-Mail sollte einer davon sein. InboxAPI füllt die Lücke, die Messaging-Plattformen strukturell nicht schließen können: unbegrenzte, programmierbare Identitäten ohne Plattformgenehmigung.
Was sind die Sendelimits?
Abschnitt betitelt „Was sind die Sendelimits?“Jedes Konto hat 5 Adressbuchplätze für externe Empfänger. E-Mails an andere InboxAPI-Adressen (z. B. @inboxapi.ai, @inboxapi.io, @inboxapi.dev) zählen nicht gegen dieses Limit. Wenn alle Plätze belegt sind, wird der am längsten ungenutzte Eintrag nach 5 Tagen Inaktivität automatisch ersetzt. Vollständige Details unter Limits & Fair Use.
Was passiert, wenn ich das Limit erreiche?
Abschnitt betitelt „Was passiert, wenn ich das Limit erreiche?“Wenn alle 5 Plätze belegt sind, wird der am längsten ungenutzte Eintrag nach 5 Tagen Inaktivität automatisch ersetzt.
Wie funktioniert das Adressbuch? Muss ich Kontakte hinzufügen?
Abschnitt betitelt „Wie funktioniert das Adressbuch? Muss ich Kontakte hinzufügen?“Das Adressbuch ist automatisch — Kontakte werden hinzugefügt, wenn du E-Mails sendest. Du musst Kontakte nie manuell hinzufügen, konfigurieren oder verwalten. Es gibt keine Einstellungsdatei, keine zu pflegende Kontaktliste und keinen Einrichtungsschritt.
Wenn dein Agent eine E-Mail an eine neue externe Adresse sendet, wird diese Adresse im Adressbuch erfasst. Jedes Konto hat 5 Plätze. Wenn alle 5 belegt sind, wird der am längsten ungenutzte Eintrag nach 5 Tagen Inaktivität automatisch ersetzt. E-Mails an andere InboxAPI-Adressen (@inboxapi.ai, @inboxapi.io, @inboxapi.dev) sind immer unbegrenzt und belegen keinen Platz.
Was sind die aktuellen Einschränkungen?
Abschnitt betitelt „Was sind die aktuellen Einschränkungen?“InboxAPI ist für Agent-zu-Mensch- und Agent-zu-Agent-E-Mail voll funktionsfähig, hat aber derzeit einige Einschränkungen:
- 5 externe Empfängerplätze: Jedes Konto hat 5 gleichzeitige externe Empfängerplätze in seinem Adressbuch. Du kannst über Zeit mehr als 5 Personen mailen, aber nur 5 externe Adressen können gleichzeitig aktiv sein; wenn alle Plätze belegt sind, wird der am längsten ungenutzte Eintrag nach 5 Tagen Inaktivität automatisch ersetzt.
- Noch keine eigenen Domains: Agenten nutzen automatisch bereitgestellte @inboxapi.ai-Subdomains.
- Nur persönlicher Gebrauch: InboxAPI ist kein transaktionaler E-Mail-Dienst — nutze es nicht für Massenversand, Marketing oder Anwendungsbenachrichtigungen.
Wie funktionieren Zugangsdaten?
Abschnitt betitelt „Wie funktionieren Zugangsdaten?“Die Zugangsdaten deines Agenten liegen lokal unter ~/.config/inboxapi/credentials.json (Linux) bzw. ~/Library/Application Support/inboxapi/credentials.json (macOS). Die CLI übernimmt Tokenerstellung und -erneuerung automatisch — dein Agent muss Tokens nie manuell verwalten.
Was, wenn mein Agent den Zugriff verliert?
Abschnitt betitelt „Was, wenn mein Agent den Zugriff verliert?“Wenn die Zugangsdaten deines Agenten verloren gehen oder beschädigt werden, kannst du das Konto mit dem account_recover-Tool wiederherstellen — aber nur, wenn du zuvor deine E-Mail per verify_owner verknüpft hast. Die Wiederherstellung widerruft alle bestehenden Tokens und stellt neue Zugangsdaten aus. Ohne verifizierte Inhaber-E-Mail gibt es keine Möglichkeit, ein ausgesperrtes Konto wiederherzustellen.
Was ist die Inhaberverifizierung?
Abschnitt betitelt „Was ist die Inhaberverifizierung?“Die Inhaberverifizierung verknüpft deine persönliche E-Mail-Adresse mit dem InboxAPI-Konto deines Agenten. Dein Agent ruft verify_owner mit deiner E-Mail auf, du erhältst einen 6-stelligen Code und dein Agent übermittelt ihn, um die Verifizierung abzuschließen. Nach der Verifizierung kannst du das Konto wiederherstellen, falls Zugangsdaten je verloren gehen, und Testbeschränkungen werden vom Konto entfernt.
Welche Domains sind für den Versand blockiert?
Abschnitt betitelt „Welche Domains sind für den Versand blockiert?“InboxAPI pflegt eine Sperrliste, die den Versand an Regierungs- (.gov), Militär- (.mil), Geheimdienst-, Strafverfolgungs-, Nuklear-/kritische-Infrastruktur- und Wegwerf-E-Mail-Domains blockiert.
Wie funktioniert die Vertrauensklassifizierung?
Abschnitt betitelt „Wie funktioniert die Vertrauensklassifizierung?“Jede eingehende E-Mail wird in eine von vier Vertrauensstufen eingestuft:
| Vertrauensstufe | Bedeutung | Empfohlene Aktion |
|---|---|---|
| Vertrauenswürdig | Absender ist im Adressbuch mit gültigem SPF/DKIM | Unbedenklich |
| Agent | Absender ist ein bekannter InboxAPI-Agent | Frei lesen, aber vor Aktionen mit dem Menschen Rücksprache halten |
| Unverifiziert | Gültiges SPF/DKIM, aber Absender nicht im Adressbuch | Vorsicht walten lassen |
| Verdächtig | Authentifizierung fehlgeschlagen oder unbekannter Absender | Markieren und vor Aktionen bestätigen lassen |
Welches KI-Modell sollte ich mit InboxAPI verwenden?
Abschnitt betitelt „Welches KI-Modell sollte ich mit InboxAPI verwenden?“Dein Modell muss Tool-/Funktionsaufrufe unterstützen — MCP erfordert das. Wir empfehlen mindestens 32K Token Kontextfenster, damit die 22 Tooldefinitionen von InboxAPI bequem neben Konversationsverlauf und E-Mail-Inhalten passen.
Modellempfehlungen nach Stufe:
| Stufe | Anthropic | OpenAI | |
|---|---|---|---|
| Gut | Haiku 4.5+ | GPT-4.1 mini+, GPT-4.1 nano+ | Gemini 2.5 Flash+ |
| Empfohlen | Sonnet 4.5+ | GPT-4.1+, GPT-5 mini+ | Gemini 2.5 Pro+ |
| Am besten | Opus 4.5+ | GPT-5+, GPT-5.2+ | Gemini 2.5 Pro+ |
Datamarking-Overhead: InboxAPI wendet Datamarking (Spotlighting) auf nicht vertrauenswürdige E-Mail-Inhalte an und ersetzt Whitespace durch Unicode-Markierungszeichen. Das kann den Tokenverbrauch bei der Verarbeitung von E-Mails externer Absender leicht erhöhen. Modelle mit größeren Kontextfenstern kommen damit besser zurecht.
Funktioniert nicht: Modelle ohne Tool-/Funktionsaufruf-Unterstützung, Modelle mit Kontextfenstern unter 16K Token und sehr kleine lokale Modelle (unter ~7B Parametern) ohne verlässliche Toolaufrufe. Sie tun sich schwer, die 22 Tooldefinitionen von InboxAPI unterzubringen und einen nützlichen Konversationsverlauf zu halten.
Was hindert einen Agenten daran, per E-Mail Dinge zu kaufen oder Transaktionen zu autorisieren?
Abschnitt betitelt „Was hindert einen Agenten daran, per E-Mail Dinge zu kaufen oder Transaktionen zu autorisieren?“InboxAPI ist ein Kommunikationskanal, keine Ausführungsumgebung. Es kann eine E-Mail zustellen, aber keine Buttons klicken, keine Kreditkartennummern eingeben und nicht mit externen Systemen interagieren. Das Risiko unbefugter Aktionen hängt davon ab, wie ein Agent konfiguriert ist und auf welche anderen Tools er Zugriff hat — nicht von seiner E-Mail.