@inboxapi/cli 0.2.5 → 0.2.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +117 -0
  2. package/package.json +6 -6
package/README.md CHANGED
@@ -10,6 +10,22 @@ Copy and paste this sentence into your agent:
10
10
  Install the `@inboxapi/cli` npm package globally and then register the `inboxapi` command as an MCP server named `inboxapi`.
11
11
  ```
12
12
 
13
+ <details>
14
+ <summary>Table of Contents</summary>
15
+
16
+ - [Technical details](#technical-details)
17
+ - [Good to know](#good-to-know)
18
+ - [Installation](#installation)
19
+ - [Getting Started](#getting-started)
20
+ - [Commands](#commands)
21
+ - [Usage with MCP Clients](#usage-with-mcp-clients)
22
+ - [Development](#development)
23
+ - [FAQ](#faq)
24
+ - [License](#license)
25
+ - [Disclaimer](#disclaimer)
26
+
27
+ </details>
28
+
13
29
  ### How it works
14
30
 
15
31
  1. Install the CLI
@@ -97,6 +113,30 @@ Displays the currently authenticated account and endpoint.
97
113
  inboxapi whoami
98
114
  ```
99
115
 
116
+ ### `reset`
117
+
118
+ Deletes stored credentials. Interactively offers to back up first, then asks for confirmation before deleting.
119
+
120
+ ```bash
121
+ inboxapi reset
122
+ ```
123
+
124
+ ### `backup`
125
+
126
+ Backs up credentials to a specified folder.
127
+
128
+ ```bash
129
+ inboxapi backup ./my-backup
130
+ ```
131
+
132
+ ### `restore`
133
+
134
+ Restores credentials from a backup folder. Validates backup integrity and offers to back up existing credentials before overwriting.
135
+
136
+ ```bash
137
+ inboxapi restore ./my-backup
138
+ ```
139
+
100
140
  ## Usage with MCP Clients
101
141
 
102
142
  InboxAPI CLI works as an MCP STDIO transport. Point your MCP client at the `inboxapi` binary:
@@ -170,6 +210,83 @@ cargo test # Run tests
170
210
  cargo fmt # Format code
171
211
  ```
172
212
 
213
+ ## FAQ
214
+
215
+ **How is this different from AWS SES, SendGrid, or Resend?**
216
+
217
+ Those are sending APIs — you build email infrastructure on top of them. InboxAPI gives your agent a complete email identity: send, receive, search, reply, and forward. There's nothing to configure and no infrastructure to manage.
218
+
219
+ **How is this different from AgentMail or a1base?**
220
+
221
+ We built our own email stack from the ground up. We don't wrap SES, Postfix, or any third-party sending service. Your agent's mail goes through infrastructure we operate directly.
222
+
223
+ **Is it really free?**
224
+
225
+ Yes. No credit card, no trial period, no usage tiers. We're working on paid plans with additional features, but the core experience will always be free.
226
+
227
+ **How do you prevent spam and abuse?**
228
+
229
+ Account creation requires proof-of-work. Each account can only email 5 unique external domains per week. Daily send quotas and rate limiting are enforced on every account. These constraints are structural — they're not policies, they're how the system works.
230
+
231
+ **What about prompt injection via email?**
232
+
233
+ Every inbound email includes a trust classification — trusted, agent, unverified, or suspicious — based on whether the sender is in your addressbook and whether their email passes authentication checks. This helps your agent decide how cautiously to handle each message. Emails from other InboxAPI agents are flagged separately so your agent knows to check with you before acting on them.
234
+
235
+ **What about data exfiltration?**
236
+
237
+ Outbound emails are scanned for authentication tokens and credentials. If your agent accidentally tries to send an email containing a JWT or access token, the message is rejected before it leaves the platform. This prevents agents from being tricked into leaking sensitive data via email.
238
+
239
+ **Can agents spam each other?**
240
+
241
+ The same send limits apply to all outbound email — recipient caps, quotas, and rate limiting work the same regardless of who's on the receiving end.
242
+
243
+ **Will my agent's emails land in spam?**
244
+
245
+ Maybe at first. Each agent gets a brand-new subdomain, and new senders don't have reputation yet. Recipients may need to check their spam folder for the first few emails. Over time, as your agent sends legitimate mail and recipients interact with it, delivery improves.
246
+
247
+ **Why email instead of a native agent protocol like A2A?**
248
+
249
+ Email reaches the entire existing internet — billions of people and businesses already use it. A2A requires both sides to implement the protocol. When your agent needs to reach someone outside its own ecosystem, email is the universal option. Agents will likely need both.
250
+
251
+ **What are the send limits?**
252
+
253
+ Each account can email up to 5 unique external domains per week. Emails to other @inboxapi.ai addresses don't count against this limit. The limit resets weekly.
254
+
255
+ **What happens when I hit the limit?**
256
+
257
+ When all 5 slots are in use, the least recently used entry is auto-replaced after 5 days of inactivity.
258
+
259
+ **Can I send attachments?**
260
+
261
+ Not yet. Attachment support is coming soon.
262
+
263
+ **Can I send HTML emails?**
264
+
265
+ HTML email support is coming soon. Currently emails are sent as plain text.
266
+
267
+ **How do credentials work?**
268
+
269
+ Your agent's credentials are stored locally at `~/.config/inboxapi/credentials.json` (Linux) or `~/Library/Application Support/inboxapi/credentials.json` (macOS). The CLI handles token creation and refresh automatically — your agent never needs to manage tokens manually.
270
+
271
+ **What domains are blocked from sending?**
272
+
273
+ InboxAPI maintains a denylist that blocks sending to government (.gov), military (.mil), intelligence, law enforcement, nuclear/critical infrastructure, and disposable email domains.
274
+
275
+ **How does the trust classification work?**
276
+
277
+ Every inbound email is classified into one of four trust levels:
278
+
279
+ | Trust Level | Meaning | Recommended Action |
280
+ |-------------|---------|-------------------|
281
+ | Trusted | Sender is in your addressbook with valid SPF/DKIM | Safe to act on |
282
+ | Agent | Sender is a known InboxAPI agent | Read freely, but confirm with your human before taking actions |
283
+ | Unverified | Valid SPF/DKIM but sender not in addressbook | Use caution |
284
+ | Suspicious | Authentication failed or unknown sender | Flag and confirm before acting |
285
+
286
+ **What stops an agent from buying things or authorizing transactions via email?**
287
+
288
+ InboxAPI is a communication channel, not an execution environment. It can deliver an email, but it can't click buttons, enter credit card numbers, or interact with external systems. The risk of unauthorized actions comes from how an agent is configured and what other tools it has access to — not from its email.
289
+
173
290
  ## License
174
291
 
175
292
  The source code in this repository is licensed under the [MIT License](LICENSE).
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@inboxapi/cli",
3
- "version": "0.2.5",
3
+ "version": "0.2.7",
4
4
  "description": "📧 Email for your AI 🤖",
5
5
  "main": "index.js",
6
6
  "bin": {
@@ -27,10 +27,10 @@
27
27
  "test": "cargo test"
28
28
  },
29
29
  "optionalDependencies": {
30
- "@inboxapi/cli-darwin-arm64": "0.2.5",
31
- "@inboxapi/cli-darwin-x64": "0.2.5",
32
- "@inboxapi/cli-linux-x64": "0.2.5",
33
- "@inboxapi/cli-linux-arm64": "0.2.5",
34
- "@inboxapi/cli-win32-x64": "0.2.5"
30
+ "@inboxapi/cli-darwin-arm64": "0.2.7",
31
+ "@inboxapi/cli-darwin-x64": "0.2.7",
32
+ "@inboxapi/cli-linux-x64": "0.2.7",
33
+ "@inboxapi/cli-linux-arm64": "0.2.7",
34
+ "@inboxapi/cli-win32-x64": "0.2.7"
35
35
  }
36
36
  }