The file you send, and the file you share

Every proposal, contract and deck reaches the same small fork in the road. You can put the file inside the message, or you can put a link to the file inside the message. It looks like a question about size, and it is mostly a question about what you will know afterwards.

One route ends in a copy you no longer hold. The other ends in a document you still own, with a view record that Google and Microsoft both describe in public, including the parts that limit what you get to see.

An attachment is a copy that leaves

The header that carries a file through email is defined by RFC 2183, a standards track document from 1997. A sender gets two presentation choices, inline or attachment, plus optional parameters for a suggested filename, some dates and an approximate size in octets. That is the entire vocabulary.

Notice how much of it is a suggestion. The specification opens by saying the header is optional, and that in its absence the receiving mail client may use whatever presentation method it deems suitable. Whether your PDF arrives as a preview or a paperclip is settled on the other side, and that decision never travels back to you.

Why a file that fits can still be too big

Mail was built to carry text, so a binary file has to be re-encoded into printable characters to survive the trip. The usual encoding is base64, and RFC 2045 is precise about the cost: the encoded data are consistently about 33 percent larger than the unencoded data. A 20 MB file is not 20 MB in flight.

That matters against a published ceiling. Google gives the limit for Gmail attachments as 25 MB on personal accounts, set by the administrator on work and school accounts, and states its own remedy plainly: if the total attachment size is greater than the limit, Gmail removes the attachment and adds it as a Google Drive link in the email. Google does not publish whether that 25 MB is measured before or after encoding, so leave the headroom, or send the link deliberately rather than letting a size check decide for you.

Machines open the file before your recipient does

An attachment landing in a corporate mailbox is rarely delivered untouched. Microsoft documents Safe Attachments as opening files in a virtual environment to see what happens, a process it calls detonation, before the message reaches the recipient. Its own guidance says the scan typically finishes within fifteen minutes and sometimes takes longer.

One delivery mode is worth knowing by name. Dynamic Delivery sends the message through immediately but replaces the attachments with placeholders until scanning is complete, so somebody can open your email and find nothing where the contract should be. A recipient reporting a missing file may be describing exactly that.

What a shared link reports, and who can turn it off

A link points at something you still control, which is why it can report anything at all. Google's Activity dashboard shows the owner of a Docs, Sheets or Slides file who has viewed it, and Google is careful about the boundaries. It exists only for files owned by a work or school account, and if a file is not owned through one, Google says plainly that nobody can see the view history. It records signed in people, so an unauthenticated fetch is not what it reports.

The viewer holds the switch. Any signed in person can turn their view history off for one document or for all of them, and once it is off they will not appear in the Activity dashboard for anybody's files. Google adds the detail that settles it: views that happened while view history was off will never show, even if the setting is turned back on afterwards.

Microsoft keeps a similar record on the file card that appears when you point at a file in OneDrive or SharePoint. It lists viewers by name and picture alongside the total number of views, and only people who already have access to the file can see it. Viewers is on by default in OneDrive, while a SharePoint site owner has to activate it as a site feature, and only if the organization's administrator has allowed it. The history rule runs the other way from Google's: if the feature is switched off and later switched back on, views from the quiet period do appear.

Views that happened while view history was off will never show. Google wrote that rule for its own dashboard, and it is the clearest statement anywhere of who a view really belongs to.

The first open may not be a person

Something else happens to a link before your recipient touches it. Microsoft's Safe Links documentation says that while the protection is on, URLs are scanned prior to message delivery whether or not they are rewritten, and that URLs without a valid reputation are detonated asynchronously in the background. A share link you made ten minutes ago has no reputation at all.

An event landing seconds after you press send deserves a raised eyebrow rather than a follow up. The visit that means something is usually the second one, at a human hour, with time spent.

Sending a file in practice

• Choose the route on purpose. If the document still matters after it is sent, share a link, because an attachment stops reporting once it is delivered.
• Leave room under the size limit. Base64 adds roughly a third, and the ceiling applies to the message rather than to the file on your desk.
• Expect the placeholder. If a recipient reports a missing attachment, ask whether they see a placeholder before you resend anything.
• Read an empty viewer list as nothing at all. The person may have opted out, may not be signed in, or may sit outside the account type it covers.

This is the register Fast Mail Tracker works in. It keeps document opens next to the open, click and reply history for the thread they belong to, so a view arrives with the conversation around it, and it can lock a shared link down when a document should not travel past the person you sent it to.

Attaching and sharing are both legitimate, and the difference between them is how much you get to know afterwards. Worth choosing on purpose, while the choice is still yours.