The first inbound email with a 20 MB PDF is the day the queue starts backing up. The message is fetched, decoded, and written into the same row as the parsed body — and now every query that lists the inbox drags the attachment with it.
What actually arrives
An attachment is a MIME part with a filename in Content-Disposition and a type in Content-Type. Its bytes are encoded with base64 (usually), which inflates the payload by about a third. A 7 MB PDF becomes roughly 9.5 MB of text in the message body. If your webhook payload includes the raw message, that entire string is in the request body that your framework parses into memory before your handler runs.
The shape that scales
Store a reference, not the bytes. Decode the part, stream it to object storage under a key derived from the message id plus a part index, and keep filename, size, content type and checksum in the database. The inbox listing then costs the same whether the message had no attachments or nine.
The checksum is worth keeping: a customer who forwards the same invoice three times produces three byte-identical parts, and deduplicating on the hash saves storage and prevents the agent from processing the same document three times.
Limits you should set before you need them
- A maximum accepted message size, enforced at the SMTP or API boundary.
- A maximum number of parts, because a zip bomb is just a multipart message.
- A per-mailbox storage quota, so one account cannot fill the bucket.
Volanea hands inbound attachments over as URLs with the size and checksum already resolved, so the handler never touches the encoded bytes.
Top comments (0)