Email attachments on a disposable address: limits and safety

What arrives as an attachment

A message is a tree of parts, and only some of them are files. The rule here is deliberately generous, because the alternative — trusting a sender to label things properly — quietly loses attachments a mail client would have shown:

Anything marked as one

A part whose Content-Disposition says attachment. The ordinary case, and the one every mail client agrees on.

Anything carrying a filename

A part with a filename on it, however it is otherwise labelled. Senders mislabel constantly, and a file with a name is a file.

Named parts that are not text

A part with a name whose type is not text/…. That is what catches the logo in an HTML signature — so a message can arrive with attachments you did not expect and the sender never thought of as attachments.

The count you see is therefore often higher than the count the sender had in mind. Twenty is the most any one message keeps; a message carrying more parts with filenames than that keeps the first twenty and drops the rest, which is worth knowing before you build anything on it.

A filename from the wire is never used as a path. The file is written under a generated name and the original is carried alongside it as data, so a sender cannot choose where their file lands by calling it something with a slash in it.

The size ceiling, and where it really falls

The published number is 5 MB, and it is worth being exact about what it measures: the whole encoded message. Not the attachment, not the sum of the attachments — everything the sending server hands over, after MIME encoding has already made it bigger.

Base64 — how a binary crosses a protocol built for text — turns every three bytes into four. Add the line breaks it needs and a file arrives about a third larger than it was on disk, a little more once those are counted. Working backwards from 5 MB, that puts the real limit at a file of roughly 3.5 MB, and lower again for a message with a signature and an HTML part.

What is measured

Headers, the text part, the HTML part and every attachment, all after encoding.

Attachments per message

Twenty. In practice the size ceiling arrives first.

Text parts

Kept up to 2 MiB each after decoding. A body longer than that is stored truncated — which no ordinary mail comes close to, though a generated report might.

What happens when a file is too big

It is refused at the door, during the SMTP conversation, before anything is stored. A sending server that announces the size up front is turned away immediately, and the exchange ends about like this:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

That matters more than it looks. A service that accepted the message and dropped it afterwards would leave the sender believing it had been delivered and you waiting for something that was never going to appear. A refusal at SMTP time is a real failure reported to a real person: the sender gets a bounce with the reason in it.

A sender that does not announce the size in advance gets the same answer at the end of the message instead, once the mail server has counted the bytes for itself. Either way nothing lands in the mailbox and nothing arrives truncated.

Getting a file out of the inbox

In the browser it is where you would expect. Open the message and the attachments are listed under it, each with the name the sender gave it and the size that actually arrived.

1. Open the message. The list refreshes on its own, so a file that lands while you are looking at the mailbox appears without a reload.
2. Read the name and the size before you click. Both are facts about what arrived, and they are the last thing you see before the file is on your machine.
3. Click it. The file downloads. It never opens in the browser, whatever it claims to be — the next section explains why that is a feature rather than a shortcoming.

Remote images in the message body are blocked until you ask for them, and that is a different thing from an attachment: a blocked image is fetched from the sender's own server the moment you allow it, while an attachment came with the message and is fetched from nobody.

Downloading from the API

Reading a message returns its attachments as a list, and each one arrives with the URL already built for it:

"attachments": [
  {
    "id":       "01JR8W2K4QATT1",
    "filename": "invoice.pdf",
    "mime":     "application/pdf",
    "size":     184320,
    "url":      "/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"
  }
]

That URL is a plain GET with the mailbox as a query parameter, and on the public domains it needs nothing else — no key, no session, no account:

curl -OJ "https://grabmail.io/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"

-OJ tells curl to save the file under the name the server sends rather than under the id. The endpoint answers one of three things: the file, a 404 if there is no such attachment in that mailbox or it has expired, or a 429 if you are asking more than once a second.

An attachment id is scoped to its mailbox, so an id from one address is a 404 at another. There is no endpoint that lists attachments on their own — they arrive with their message and are read from it. The API reference has the full shape of a message response.

Why every file downloads as a binary

Whatever the sender said their file was, it comes back as application/octet-stream and it downloads instead of opening. That is not carelessness about content types — it is the only safe answer when the file came from a stranger.

The sender's type is never echoed back

Someone who labels their file text/html and gets it rendered on our origin is running their page as us, in your session, with whatever that lets them reach. So the label is dropped and the caller decides what the file is from the metadata beside it.

Always a download, never a view

Content-Disposition: attachment on every response, so nothing renders in place, however it is labelled.

No sniffing, and nothing may run

X-Content-Type-Options: nosniff stops the browser guessing a type back, and a Content-Security-Policy of default-src 'none'; sandbox means that even if something did render, it could load nothing and run nothing.

The filename cannot become a header

The name is encoded rather than pasted into the response, so a file named with a newline in it cannot add a header of its own choosing.

The file itself is untouched — byte for byte what the sender sent. It is the framing around it that is deliberately boring. It is also stored outside the web root, so guessing a path is not a way in: the mailbox has to be resolved and authorised before the file is read at all.

Nothing here scans the file

There is no antivirus, no sandbox detonation and no reputation check. That is a stated limit rather than an oversight, and it changes what you can safely do with what arrives:

• Anyone can send to a public address. They do not need to know you — they need to know the address, and short ones get guessed. A file in a public mailbox has an unknown author by default.
• Executables and scripts are exactly as dangerous here as anywhere. Nothing is filtered by extension, and nothing looks inside an archive to see what is in it.
• Documents that can run things are the common case. Macro-enabled office files and PDFs with embedded actions are how most of this actually happens, not obvious executables.
• The name tells you nothing. A file called invoice.pdf is whatever its bytes say it is, and the extension was chosen by whoever sent it.

Files leave when the message leaves

An attachment has no life of its own. It belongs to its message, and it goes when the message goes:

After 5 days

Deleted with the message, read or not, on a clock that started when it arrived. There is no archive and no export.

When you delete the message

Immediately, and the URL becomes a 404. It is the same call whether you delete from the inbox or through the API.

There is no way back

No undelete, no grace period and no support mailbox to ask. Anything you will want tomorrow has to be downloaded today.

When email is the wrong pipe

Some of what people try to do with attachments here is not a limit to work around — it is the wrong tool for the job:

• A file over the ceiling. Nothing raises it. Send a link instead.
• Something you will need next month. 5 days is a hard limit enforced by a job, not a setting. Fetch it now, or use a real mailbox.
• Anything you would mind a stranger reading. On a public domain the address is the only lock on the door, and it is a short one.

A domain of your own changes the third of those and neither of the first two: the ceiling and the retention are exactly the same, but the address sits on a name that appears nowhere on this site, so nobody is sending files to it by guesswork. One MX record does it:

MX record for your domain10 smtp.grabmail.ioCopy

The full walk-through is here — the record, what publishing it proves, and the honest limits of a mailbox with no password on it.

Questions