> Remember too that Base64 encoding increases file size by 33%. We really shouldn't have to use an encoding scheme that has that kind of overhead. According t

> Remember too that Base64 encoding increases file size by 33%. We really shouldn't have to use an encoding scheme that has that kind of overhead. According to the SMTP RFC 5321 section 3.1.1.4 [1], data sent during the DATA phase may contain any of the 128 ASCII characters (though control characters should be avoided). Based on my testing with a couple of commercial SMTP servers I have accounts on, it appears that it will allow almost all characters (0 - 255) through unaltered or escaped except for NUL, CR, LF, and . (in the first column only). Interestingly enough, the binary newsgroup hierarchy uses an encoding termed yEnc [2] that actually uses almost all ascii characters (other than the ones I mentioned above) to encode binaries and puts the resulting data directly in the body of the news article. It appears that it would work just as well over SMTP and only has roughly a 2% overhead compared to the original file size. Unfortunately, that encoding is just a defacto standard and has not, to my knowledge, ever been submitted as an RFC or used outside of binary newsgroups. [1] https://tools.ietf.org/html/rfc5321 https://tools.ietf.org/html/rfc5321 [2] http://www.yenc.org/yenc-draft.1.3.txt http://www.yenc.org/yenc-draft.1.3.txt