Attachments

Files sent to a temporary address are handled more strictly than in an ordinary mailbox, and deliberately so. Here is what gets through, what does not, and the reasoning.

What is accepted

Ordinary documents and media: images, PDFs, spreadsheets, text files, archives of them. Anything up to five megabytes per file. Larger files are skipped, and the message itself still arrives without them.

The whole message, including everything attached, must be under ten megabytes. Beyond that the message is refused at the door and never reaches us at all.

What is refused

Executable file types are dropped before anything is stored. That includes programs, scripts, installers, shortcuts and the various formats that exist mainly to run code on the machine that opens them.

This is not negotiable and there is no setting to change it. A disposable mailbox receives mail from strangers by definition, and an executable attachment from a stranger has no legitimate use that justifies the risk.

If a colleague genuinely needs to send you a program, that is a conversation for a real mailbox with a real relationship behind it.

How files are stored and served

Accepted files are held in object storage separate from the application, under a key that cannot be guessed. They are deleted along with the message, on the same schedule as everything else.

When you download one, it is always served as a download and never displayed in place, with a content type that prevents the browser from interpreting it. Even a file that is technically a web page cannot execute in the context of this site, because it is never treated as one.

The download link is signed and short lived. It works for five minutes and then stops, which means a link copied out of the page cannot be shared or reused later.

Attachments require an account

Guest mailboxes receive messages but not files. This is one of the three things an account adds, along with private domains and multiple mailboxes.

The reason is practical rather than commercial. Storing files costs money and carries risk, and tying that to an account means there is somebody to hold responsible if it is misused. A completely anonymous file store attached to a disposable mailbox would be abused within a week, and then blocked everywhere, which helps nobody.

Still treat them with suspicion

Everything above reduces the risk. None of it makes an unexpected attachment safe.

A document from an unknown sender can still contain a hostile macro. A PDF can still carry an exploit. An archive can still expand into something unpleasant. The only defence that reliably works is not opening files you did not expect from people you do not know.

If you are using a disposable address, you almost certainly asked for exactly one thing and know what it should be. Anything else that arrives is not for you.

What a hostile attachment actually does

Worth understanding, because "be careful with attachments" is advice nobody acts on without knowing why.

Macro documents. A spreadsheet or text document containing a small program that runs when you allow it. The message will urge you to enable content, usually claiming the document was created in a newer version.

Archives hiding an executable. A zip file is not dangerous by itself, but it can contain a program with an icon that looks like a document. The extension is often hidden by default on desktop systems, which is what the trick relies on.

Documents exploiting the reader. Rarer and more serious: a file that compromises the program opening it, with no action from you beyond opening. These depend on the reader being out of date, which is the practical reason to keep software updated.

The pattern common to all three: the attachment arrives unexpected, and the message gives you a reason to open it quickly.

Deciding in five seconds

Did you ask for this file? If you just requested an export, an invoice or a ticket, and the file matches what you asked for, it is almost certainly fine.

Does the file type match the description? A message about an invoice with a program attached is not an invoice.

Is there urgency in the wording? Urgency exists to stop you thinking. It is the single most reliable signal.

Do you recognise the sender? At a disposable address the answer is usually "I recognise the service I just signed up to", and anything else is unexpected by definition.

What we do and do not check

We refuse file types that exist to run code, and we cap sizes. That removes a whole category of problem before it reaches you.

We do not scan file contents for malware, and no honest service should claim otherwise for every file type. Detection is imperfect, and a scanner that reports clean gives false confidence that leads people to open things they would otherwise have hesitated over.

The two measures that reliably work are the ones above: refusing executables outright, and not opening what you did not ask for.

The exact rule, and what it misses

The refusal is by file extension, and the list runs to roughly three dozen entries. Programs and installers: exe, msi, dmg, apk, app, com, jar. Scripts and script hosts: bat, cmd, ps1, vbs, vbe, js, jse, wsf, wsh, hta, reg. Shortcuts, libraries and disk images: lnk, pif, scr, dll, cpl, iso. If the filename ends in one of them, the file is dropped and nothing about it is stored.

Two honest gaps follow from doing it this way.

Archives are not opened. A zip file is not on the list, and we do not look inside it, so a blocked file type can travel in one. That is the reason the section above singles out archives.

Renaming defeats the check. An executable sent as something.txt passes, because the check reads the name it was given. It also arrives useless, since nothing will run it under that name, and it only becomes a problem if somebody renames it back deliberately.

The extension list removes the careless and automated cases, which is most of them. It is not a claim to have stopped a determined sender.

What the sender is told

Nothing, in every case.

A message over ten megabytes is discarded at the receiving edge without a reply. That silence is deliberate: a bounce would confirm to whoever sent it that the address exists, which is exactly what an address is probed for.

The practical effect is worth knowing. If somebody says they sent you a file and it is not here, they are usually telling the truth, and their mail client shows it as sent. Either the whole message was too large, or the file exceeded five megabytes and was skipped while the message itself arrived, which is why an empty looking message is the more useful clue of the two.

Ask for a link to the file instead. That works within the limits, and it means neither of you is guessing.

If a file did not arrive

Check the size first: over five megabytes and it was skipped, over ten and the whole message was refused. Check the type second: if it was an executable, it was dropped deliberately. Check third that you are signed in, because attachments are one of the things an account adds. If none of that applies, the sender may simply not have attached it, which happens more often than any of the technical explanations.