When Attachments Are Fine: A Pragmatic Small-File Policy

This series has spent five articles cataloguing what email does badly as a file transfer system — the multiplying copies, the impossible recall, the stacked size limits, the scanners and quarantines, the malware door. All of it is true. And yet if you walked out of here and banned attachments outright, you would be wrong, and your users would know it before lunch.

Because sometimes an attachment is simply the correct engineering choice. A one-page agenda sent to four colleagues an hour before a meeting has no revocation problem, no audit requirement, no size risk, and no better home than the thread where the meeting is being discussed. Forcing that file through upload ceremony helps nobody — it just teaches people that the policy was written without looking at their work.

This article is the honest counterpoint that makes the rest of our Email Attachments series credible: where email genuinely is the right tool, how to draw the size line and the sensitivity line so anyone can apply them in five seconds, and a one-page policy template you can adapt — short enough to be read, reasonable enough to be followed.

Why the Honest Counterpoint Matters

Users evaluate policy the same way you evaluate vendor claims: against their own experience, one rule at a time. The moment a policy forbids something obviously harmless — attaching a lunch menu, say — the reader concludes the authors were not serious, and quietly downgrades the entire document to wallpaper. The rules that mattered, the ones about payroll exports and customer data, sink with the ship. Absolutism does not buy extra safety; it spends the credibility that safety depends on.

There is an operational cost, too. Every trivial file pushed through a heavyweight channel consumes a little time, a little patience, and a little goodwill — and goodwill is the fuel your genuinely important rules run on. A policy that says "yes, obviously, attach the small stuff" is not a concession to laziness. It is accuracy. It tells users the authors understand their day, which is precisely what earns compliance on the rules with teeth.

So the goal of a small-file policy is not to minimize attachments. It is to make the boundary so clear, and so obviously sensible, that people apply it without asking — and route the sends that matter through the channel built for them.

What Email Does Genuinely Well

Recall the strengths from the opening article of this series: email reaches everyone, needs no setup on the far end, holds the file inside the conversation that explains it, and works while the recipient sleeps. For a certain class of file, those strengths are exactly what the job needs, and the weaknesses never come into play. Concretely, attachments earn their keep in sends like these:

• The meeting agenda or one-page brief, sent to the people in the thread, useful for a day.
• The screenshot attached to a support ticket or a "is this what you're seeing?" message.
• The photo of the physical world — the broken hinge for facilities, the whiteboard after the workshop.
• The small public document — a flyer, a published price sheet, a conference itinerary.
• The log snippet or config extract a vendor asked for (scrubbed of secrets, naturally).
• The final small deliverable a client expects in their inbox — where the relationship, not the architecture, sets the format.

Look at what these have in common, because the pattern is the policy: each file is small (well under the size where limits and encoding growth bite), non-sensitive (nothing anyone would regret duplicating into a dozen mailboxes), sent to few recipients, and done the moment it arrives — no versions to reconcile, no access to audit, no need to ever take it back. When all four hold, email's weaknesses are irrelevant and its convenience is decisive. Attach away.

One more property is worth naming because it explains the pull users feel: the thread is the filing system. When the file rides with the conversation, "search my mail" finds the decision, the discussion, and the document together, years later, with zero effort at filing time. For send-and-done files that self-archiving is a genuine feature — and for living documents it is exactly the trap, because the thread preserves every stale version with equal devotion. The policy's job is to keep the feature and fence off the trap.

The Two Questions: How Big and How Sensitive

Four properties make a tidy analysis but a clumsy checklist. In practice, two questions catch nearly everything, and they are questions any user can answer in five seconds.

Question one: how big?

Draw the size line well below the point of failure. Message limits commonly sit somewhere around the tens of megabytes, they stack across every system in the path, and — as our size limits article explains — email's text encoding inflates every file by roughly a third in transit, measured against the whole message, not each file. You do not want users doing that arithmetic. Give them bands instead: up to a few megabytes, attach freely; beyond that, reach for a link; never near the tens of megabytes. The exact numbers matter less than having numbers — pick conservative ones, publish them, and the bounce tickets fade.

Question two: how sensitive?

Size is mechanical; sensitivity is the line with consequences. If your organization has no formal data classification — a shared vocabulary for how much protection information needs — the policy is a fine place to introduce a minimal one:

• Public: already published or meant to be — brochures, price lists, open documentation. Attach freely.
• Internal: everyday working material that would cause mild awkwardness, not harm, if it leaked — drafts, agendas, routine reports. Attach when small.
• Confidential: information that would cause real damage loose — contracts under negotiation, personnel matters, financials, customer lists. Never by attachment: this is exactly where the multiplying, unrecallable, unaudited copies described in why email falls short become a liability with a name on it.
• Regulated: data a law or contract explicitly governs — personal data, health records, cardholder data. Only through the approved channel, no exceptions, because "who accessed this?" must have an answer.

Notice the asymmetry between the two questions. Oversize attachments fail loudly — a bounce tells everyone. Oversensitive attachments fail silently, months later, in a mailbox you have never seen. That is why the sensitivity line, not the size line, is the one your policy should defend hardest.

The Decision Matrix

Cross the two questions and the whole policy fits in one table — the five-second lookup version:

"Link" throughout means the sanctioned alternative: the file goes to your transfer server, the recipient gets an HTTPS link and downloads in a browser. "Approved channel" for regulated data is the same mechanism plus whatever your compliance rules add — named accounts, access logging, retention. The size bands are deliberately conservative and deliberately round; adjust them to your environment, then defend them.

The Tripwires Beyond Size and Sensitivity

Two questions catch most cases. A short list of tripwires catches the rest — situations where a file passes both tests and email is still the wrong vehicle:

• A large audience. Attaching even a small file to an all-company message duplicates it into every mailbox and every backup at once. Past a handful of recipients, send a link and let the interested click.
• A file that will change. Attachments fork documents — every recipient gets an independent copy and version chaos follows. Anything with revisions ahead of it belongs in one authoritative place, with the link shared instead.
• A recurring send. The same file to the same partner every week is not correspondence; it is an unautomated job. Schedule it as a proper transfer — this is exactly the niche where a tool like Sysax FTP Automation replaces a human ritual with a logged, retried, scheduled job.
• A need for proof. If anyone will ever ask "did they receive it, and when?" — deliveries with contractual weight, audit evidence — use the channel that writes an access log. Email's silence on this point is absolute.
• A type the scanners hate. Executables, scripts, encrypted archives: even legitimate ones get stripped or quarantined, as covered in attachment security. Send a link and skip the fight with the gateway.

Finally, give users a tiebreaker for the borderline calls, because borderline calls are where policies die of overthinking. The tiebreaker rests on an asymmetry: a link used where an attachment would have been fine costs a few seconds; an attachment used where a link was needed can cost a bounce, a stripped file, or an unrecallable copy of something sensitive. The two mistakes are not the same size. So the tiebreaker is simply: when in doubt, send the link. It is never wrong — merely, occasionally, slightly slower.

The One-Page Policy Template

Here is the centerpiece: a complete small-file policy that fits on one page, written in the language of the people who will follow it. Replace the bracketed values, delete what does not apply, and resist every urge to let it grow — the single page is the feature. It works because it permits the reasonable, forbids the dangerous, and puts the alternative in the same breath as every "no."

SENDING FILES AT [ORGANIZATION] -- ONE PAGE, THE WHOLE POLICY

WHY THIS EXISTS
  Email copies every attachment into many mailboxes and backups,
  cannot take a file back, and keeps no record of who opened it.
  For most small everyday files that is fine. For big or
  sensitive files it is not. This page tells you which is which.

ATTACH FREELY when ALL of these are true:
  [ ] The file(s) total under [4 MB]
  [ ] Nothing in them is confidential, personal, or regulated
      (rule of thumb: you would not mind it being forwarded)
  [ ] You are sending to a few people, not a distribution list
  [ ] It is a one-off -- no revisions or approvals to follow

SEND A LINK from the transfer server -- [link to your server] --
when ANY of these is true:
  [ ] Files total over [4 MB] (over [15 MB] a link is REQUIRED --
      email will bounce somewhere anyway)
  [ ] The content is confidential, personal, or regulated
  [ ] Many recipients, or people outside [ORGANIZATION]
      getting sensitive material
  [ ] The document will be revised again
  [ ] You may ever need proof of who downloaded it, or the
      ability to take it back
  [ ] It is a program, script, or password-protected archive
      (email security will strip it anyway)

HOW TO SEND A LINK (under a minute):
  1. Sign in at [server address] and upload the file
  2. [Create/copy] the download link [per your server's steps]
  3. Paste the link into your email instead of attaching

RECURRING SENDS (same file, same place, every week/month):
  Ask IT to schedule it as an automatic transfer -- it will run
  on time, retry on failure, and be logged. You stop doing it
  by hand.

EXCEPTIONS
  A client or partner who insists on attachments for small,
  non-sensitive files: fine -- note it and carry on. Anything
  else: ask [contact], we will find a way that works.

HELP
  Stuck, unsure which side of the line you are on, or sent
  something you should not have? Contact [help desk] -- fast
  questions are always welcome, and telling us early is always
  the right call.

  Owner: [name/role]   Reviewed: [quarterly]

Three design choices in the template deserve a comment, because they carry the philosophy of this whole series. The "rule of thumb: you would not mind it being forwarded" line does more work than any classification table, because it converts an abstract label into a feeling every user already has. The exceptions clause is deliberately generous on trivia and deliberately open-ended on everything else — "we will find a way that works" keeps people asking instead of improvising. And the final section invites confession without penalty, which — as the security article argues at length — is the single most valuable reflex a policy can protect.

Rolling It Out and Keeping It Honest

A policy on one page still needs a working "link" path behind it, or the whole structure collapses back into attachments within a month. The requirements are the ones this series keeps returning to: the sender's steps must be few, and the recipient must need nothing but a browser. In practice that means a transfer server with a web interface over HTTPS — a Windows deployment of Sysax Multi Server fits this shape, with per-user accounts, browser downloads for external recipients with no client install, and an activity log that quietly answers the proof-of-delivery tripwire. The mechanics of browser-based transfer are covered in our HTTP and HTTPS file transfer series.

Then treat the policy as a living tool. Publish it where people actually look — the help desk portal, the onboarding pack, the answer the search box returns for "send large file." Walk it through team meetings once, with the matrix on a slide and the tone of "this is here to save you bounce messages," not "this is here to catch you." Review it on the cadence the template states: are the size bands still right, are the exceptions still justified, did bounce tickets actually fall? And when a rule proves wrong in practice, change the rule — publicly. Nothing builds policy credibility like visible willingness to correct it. For the full adoption craft — pilots, metrics, holdouts — see weaning users off attachments.

The Line in One Sentence

Small, non-sensitive, few recipients, one-off: attach with a clear conscience — email earned that job fairly. Big, sensitive, wide, versioned, recurring, or provable: put the file on the server and send the link. That is the entire policy, and every article in this series is ultimately a footnote to it: the structural case explains the sensitive half, the size limits guide explains the big half, and the honest permission in the middle is what makes users trust both.

Frequently Asked Questions