Have you ever gone to send a document and found you could not attach it?
One file was 28.5 MB
We measured our catalogues. The largest came to 28,533,816 bytes — 28.5 MB. A document request goes out with several of them together, so the full set totals 33,244,104 bytes.
That will not go through as an attachment. Typical mail servers cap incoming messages somewhere between 10 MB and 25 MB, and 33 MB sits above that.
What makes it worse is that an attachment is larger than the file itself. Email can only carry text, so the file is converted into text before it travels. That conversion inflates it by roughly a third. What you thought was 33 MB is closer to 45 MB in transit.
Your sent folder says it went. The recipient never got it. That is the worst shape this failure takes.
And then the second email with the password
Large files usually drag another task along with them: zip the file with a password, then send the password in a separate email.
Something about that always bothered me. If you put the password in the same message, the lock has no purpose. If that one message reaches the wrong person, the key arrives with it. So you split it in two — which means the sender writes two messages, and the recipient has to go looking for two.
The cost on the receiving end is the part nobody sees. Once you are the one receiving, the email with the password has a way of disappearing into the pile.
We switched to links
We changed the method. Instead of attaching the file, we send a download link.
That disposes of the size problem. What we had not expected was the side effect: the separate password email became unnecessary.
The method we use sends a confirmation code automatically. When the recipient presses the button on the download page, a six-digit code is delivered only to the address registered when the link was issued. They enter it and the download starts.
That is the part that changed. The covering email is complete on its own. Not only is there no password to write in the body — there is no password at all. The key is the recipient's own email address. The entire job of conveying something through a second channel disappeared.
Links can expire, too. We set ours to three days, so nothing stays permanently downloadable by anyone who has the URL.
In summary
- Check the file size before you send. Attachments inflate by about a third in transit, so anything over 20 MB deserves a second thought
- Sent does not mean delivered. If the recipient's server rejects it, your own screen still says sent
- Switching to links can remove the separate password email as well. With a method that sends a confirmation code automatically, one message is enough
All we wanted was to be able to send large files. Not having to write that second message every time turned out to be the bigger relief.