The 37 per cent rule
SMTP has always carried text. Binary files are therefore encoded in Base64, where every three bytes become four — a surcharge of roughly 33 per cent, plus line breaks. In practice:
A provider stating “25 MB” almost always means the message on the wire, not the file in your file manager. As a rule of thumb an attachment fits up to about three quarters of the stated limit.
The smallest limit along the path wins
Between you and the recipient's mailbox there are often several stations: your outgoing server, a filtering service, the actual target server. Every station has its own limit, and the smallest number wins. That is why a mail that gets through to one recipient fails at the same size with the next.
Well-configured servers reject as early as MAIL FROM, because the client announces its size in advance through the ESMTP SIZE extension. If the rejection only arrives after the end of data, the full 27 MB were transferred and then discarded — annoying, but a hint: the sender did not announce the size.
On your own server
On Postfix the limit hangs on two settings, and the second is almost always forgotten:
mailbox_size_limit caps the size of the destination store and must be at least as large as message_size_limit, otherwise mail is accepted and then not delivered. The value 0 removes the cap. A reload is required after the change.
Worth noting: a high limit invites large attachments that still fail further along the path. It only helps where your own server genuinely is the bottleneck.
The reliable route
- Store the file and link to it. A link burdens no size limit and can be withdrawn — an attachment cannot.
- Compress where it pays. Already-compressed formats such as image-heavy PDFs, JPEG or video gain almost nothing in an archive. With PDFs, downsampling the embedded images achieves far more.
- Do not split blindly. Multi-part archives fail against filters that cannot inspect the content, and then produce an entirely different error.