e5e119528f
* adding exports to backend package, page icons update * Integrity report PDF generation * Fixed inline attachment images not displaying in the email preview by modifying `EmailPreview.svelte`. The email HTML references embedded images via `cid:` URIs (e.g., `src="cid:ii_19c6d5f8d5eee7bd6d91"`), but the component never resolved those `cid:` references to actual image data, even though `postal-mime` already parses inline attachments with their `contentId` and binary `content`. The `emailHtml` derived value now calls `resolveContentIdReferences()` before rendering, so inline/embedded images display correctly in the iframe preview. * feat: strip non-inline attachments from EML before storage Add nodemailer dependency and emlUtils helper to remove non-inline attachments from .eml buffers during ingestion. This avoids double-storing attachment data since attachments are already stored separately. * upload error handing for file based ingestion * Use Postgres for sync session management * Google workspace / MS 365 duplicate check, avoid extra API call when previous ingestion fails * OpenAPI specs for API docs * code formatting * ran duplicate check for IMAP import, optimize message listing * Version update
2.2 KiB
aside
| aside |
|---|
| false |
Rate Limiting
The API implements rate limiting as a security measure to protect your instance from denial-of-service (DoS) and brute-force attacks. This is a crucial feature for maintaining the security and stability of the application.
How It Works
The rate limiter restricts the number of requests an IP address can make within a specific time frame. These limits are configurable via environment variables to suit your security needs.
By default, the limits are:
- 100 requests per 1 minute per IP address.
If this limit is exceeded, the API will respond with an HTTP 429 Too Many Requests status code.
Response Body
When an IP address is rate-limited, the API will return a JSON response with the following format:
{
"status": 429,
"message": "Too many requests from this IP, please try again after 15 minutes"
}
Configuration
You can customize the rate-limiting settings by setting the following environment variables in your .env file:
RATE_LIMIT_WINDOW_MS: The time window in milliseconds. Defaults to60000(1 minute).RATE_LIMIT_MAX_REQUESTS: The maximum number of requests allowed per IP address within the time window. Defaults to100.
Handling Rate Limits
If you are developing a client that interacts with the API, you should handle rate limiting gracefully:
- Check the Status Code: Monitor for a
429HTTP status code in responses. - Implement a Retry Mechanism: When you receive a
429response, it is best practice to wait before retrying the request. Implementing an exponential backoff strategy is recommended. - Check Headers: The response will include the following standard headers to help you manage your request rate:
RateLimit-Limit: The maximum number of requests allowed in the current window.RateLimit-Remaining: The number of requests you have left in the current window.RateLimit-Reset: The time when the rate limit window will reset, in UTC epoch seconds.
Excluded Endpoints
Certain essential endpoints are excluded from rate limiting to ensure the application's UI remains responsive. These are:
/auth/status/settings/system
These endpoints can be called as needed without affecting your rate limit count.