http://wiki.qmailtoaster.org:80/index.php?action=history&feed=atom&title=Attachment_size_limitations 2026-04-29T12:39:16Z Revision history for this page on the wiki MediaWiki 1.41.0 http://wiki.qmailtoaster.org:80/index.php?title=Attachment_size_limitations&diff=133&oldid=prev 2024-03-16T16:28:17Z

<p>Created page with &quot;===Attachment size limitations=== The default setting for &#039;databytes&#039; is 20971520 which is a sane, default number. But MIME overhead is fairly high, so that 20m limit means you may not be able to receive attachments larger that 12-15m. That may seem to not be a problem, but if you host a domain that deals in large attachments for data transfer, you may need to increase that number in /var/qmail/control/databytes. You could set that to 0 (not advisable) to accept atta...&quot;</p> <p><b>New page</b></p><div>===Attachment size limitations===<br /> <br /> The default setting for &#039;databytes&#039; is 20971520 which is a sane, default number. But MIME overhead is fairly high, so that 20m limit means you may not be able to receive attachments larger that 12-15m. That may seem to not be a problem, but if you host a domain that deals in large attachments for data transfer, you may need to increase that number in /var/qmail/control/databytes. You could set that to 0 (not advisable) to accept attachments regardless of size, or figure out what is the largest attachment you will recieve, then double that in the databytes file. Yes, ftp would be a better answer for moving that chunk of data around. Do you really want to have to talk the sender through a filezilla download, install, configure, connect, and upload, or worse, a command session? Point is that email is more widely known than the venerable ftp, and most everybody has an email client already installed and knows how to use it.<br /> <br /> ==[[User Tips &amp; Tricks]]==</div>

Ebroch