Bug #128400 for MIME-tools: MIME::Decoder::Base64 encoder output overhead is too high

MIME::Decoder::Base64, as documented, encodes 45 bytes at a time.  This results in an output line length of 60 for full (encoded) lines. The optimal line length for base64 is 76, which is obtained by encoding 57 bytes at a time.  RFC2045 6.8 states that the line length of base64 data "must be represented in lines of *no more than* 76 characters each". MIME::Decoder::Base64's POD says "We chose 45 since it is a multiple of 3 and produces lines under 76 characters, as RFC 2045 specifies:".  This is a fencepost error.  The RFC language "no more than" requires lines less than OR EQUAL TO 76 characters.  The output produced by MIME::Decoder::Base64 is legal, but inefficient. The difference is about 0.7% in overhead, which doesn't sound like much - except that people seem to send a lot of large cat photos :-) Actually, it's 27% MORE overhead than necessary. Please update MIME::Decoder::Base64 to use a chunk size of 57, which will produce the maximum allowed line length of 76 and the minimum overhead. Supporting math: 2 EOL chars per 76 is 2.63% overhead.  2 EOL chars per 60 is 3.33% -- the absolute difference is 0.7%.  3.33/2.63 = 1.27 -- thus the overhead is 27% bigger than necessary. 76 = 57 * 4/3. MIME::Base64 recommends a chunk size of 57 bytes for this reason. (EXAMPLES => "If you want to encode a large file, you should encode it in chunks thatare a multiple of 57 bytes. ") RFC2045 doesn't explicitly state that the EOL characters are excluded from the line length of base64, but this is implied by the choice of 76 - which evenly divides by 4/3.  74 (76 - 2 EOL characters) does not. MIME::Decoder::Base64 with MIME::tools 5.509 (current at this writing) has the suboptimal behavior. Thanks!