> For the complete documentation index, see [llms.txt](https://docs.resifactory.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.resifactory.net/imap/inbox-window.md).
# The inbox window
The **inbox window** limits an app password's IMAP view to mail received in the last *N* minutes. It is set per app password, and it slides — the cutoff moves forward with the clock, so "last 15 minutes" always means the last 15 minutes.
## Why it exists
A mailbox that has been collecting mail for months holds a lot of messages. When a tool connects over IMAP with no window, the server hands it the whole thing — and the tool then has to work through all of it to find the one code that arrived twenty seconds ago.
With a window, the same tool sees a small, recent slice. Every command it runs is proportionally faster, and the message it actually wants is right at the top.
{% hint style="success" %}
**New mail always arrives immediately, whatever the window.** The window trims the *back* of the view, never the front. A 15-minute window does not delay anything by 15 minutes — it simply stops the client being handed everything older than that.
{% endhint %}
## The presets
| Preset | Minutes | Use it for |
| ---------------------------- | ------- | ---------------------------------------------------------------------------------- |
| **Unlimited (all messages)** | — | Only when you genuinely need full history over IMAP, and the mailbox is small. |
| **Last 3 months** | 129,600 | A mail client you browse by hand and want real history in. |
| **Last 1 month** | 43,200 | A mail client you read daily. |
| **Last 14 days** | 20,160 | Order and delivery tracking — long enough to still hold the original confirmation. |
| **Last 7 days** | 10,080 | Order tracking on a faster cycle; general-purpose automation. |
| **Last 24 hours** | 1,440 | A busy client that only cares about today. |
| **Last 6 hours** | 360 | Verification codes with some slack. |
| **Last 1 hour** | 60 | Verification codes, tight. |
| **Last 15 minutes** | 15 | **Shikari** and any tool that polls hard for a code that is arriving right now. |
## Picking one
The question to ask is: **how old is the oldest message this tool needs to see?** Then pick the next preset up.
{% tabs %}
{% tab title="Codes and OTP" %}
### Last 15 minutes → Last 1 hour
A verification code is useful for a few minutes. Anything older is noise.
* [**Shikari**](https://shikari.tech) → **Last 15 minutes**. It polls continuously while waiting; a tight window is what keeps each poll instant.
* Other OTP tooling → **Last 1 hour** is a safe default if you are not sure how long it waits before giving up.
{% endtab %}
{% tab title="Order tracking" %}
### Last 7 days → Last 14 days
Shipping mail arrives in a chain: confirmation, then dispatch, then out for delivery, then delivered — often spread over a week or more.
If the window is shorter than that chain, your tool sees the delivery notice without ever having seen the order. **Last 14 days** covers almost all retail cycles. Go longer only if you buy things with long lead times.
{% endtab %}
{% tab title="Reading by hand" %}
### Last 1 month → Last 3 months
You want to scroll back through real history, but not wait for a full sync of everything ever received.
**Last 1 month** is comfortable. **Last 3 months** if you regularly look further back than that.
{% endtab %}
{% tab title="Unlimited" %}
### Rarely the right answer
Unlimited is correct when you are deliberately pulling complete history — a one-off archive, for instance — and you accept that the first sync will be slow.
For anything running continuously, a window is better. If a tool is behaving badly and you are not sure why, narrowing the window is the first thing to try.
{% endtab %}
{% endtabs %}
## Setting it
**When creating** an app password, choose it in the **Inbox window** field:
**On an existing** app password, right-click the row → **Edit inbox window…**:
Changes take effect on the very next command your client sends. No restart, no new credential.
## Different windows on the same mailboxes
The window belongs to the **credential**, not to the mailbox. Nothing stops you running several at once over the same mail:
| Credential | Window | Job |
| ---------------- | --------------- | ----------------------------------------- |
| `shikari-main` | Last 15 minutes | Catch codes the instant they land. |
| `order-tracking` | Last 14 days | Follow deliveries across the whole cycle. |
| `laptop` | Last 1 month | Read mail by hand in a normal client. |
Each sees exactly what it needs and nothing more.
## What the window does not do
* **It does not delete anything.** Mail outside the window is still stored, still searchable in the [web inbox](/the-console/inbox.md), and comes straight back if you widen the window.
* **It does not delay new mail.** New messages appear immediately.
* **It does not affect the web console.** The console always shows everything retained; the window is an IMAP-only setting.
* **It is not retention.** How long mail is *kept* is a separate server setting, visible on [Settings](/the-console/settings.md). The window only controls how much of what is kept a given credential is shown.
## Rule of thumb
{% hint style="success" %}
Start narrow. Widen only if a tool actually misses something.
A window that is too tight produces an obvious, fixable symptom — "it did not see the order confirmation". A window that is too wide produces a vague one — "it is slow sometimes" — which is much harder to chase.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.resifactory.net/imap/inbox-window.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.