Rate Limiting

Protect your inbox from runaway scripts, mail loops, and abusive senders. Scitor applies a sliding-window rate limit per (installation, sender email). When a sender exceeds either limit, further emails are dropped and an optional one-time-per-day notice is posted on their most recent ticket.

Defaults

inbound:
  rate_limit:
    max_per_minute: 5
    max_per_hour: 30

Setting either bound to 0 disables that bound. Setting both to 0 effectively turns rate limiting off.

How it works

1. Every accepted inbound email increments a counter bucketed by 60-second window for the sender.
2. After incrementing, Scitor sums the buckets that fall inside the sliding 60s and 3600s windows.
3. If either sum exceeds the configured maximum, the email is dropped (no ticket, no comment).
4. Once per UTC day per sender, Scitor finds that sender’s most recent ticket and posts a short rate-limit notice with a rate-limited label so you know it happened.
5. Counters older than 25 hours are pruned by the daily scheduled cleanup.

Why a sliding window?

Fixed windows have a known burst-on-the-boundary problem (twice the limit can land in a few seconds across two windows). The 60-second buckets give us O(1) writes while still summing across the actual sliding window for the limit decision.

Tuning

• Tickets from a high-volume customer? Raise max_per_hour for the whole installation, or whitelist specific addresses by adding them to your CRM with VIP status.
• Newsletter / mailing-list traffic? Combine rate limiting with Blocked Senders for the offending list address.
• Mail-loop scenario (auto-responder ping-pong)? The default limits will catch most loops within a minute and post a single notice to alert you.

Notes

• Rate limiting runs after the spam/block checks but before any AI or GitHub work, so dropped emails consume minimal compute.
• The notice comment is best-effort: if posting fails (e.g. the ticket is locked), the email is still dropped.
• Per-day notice deduplication uses an INSERT OR IGNORE on (installation, sender_hash, day) so each sender sees at most one notice per day.