Question: mime-mail and base64 encoding

Hi all, I've gotten a request for the mime-mail package that I'd like some input on. Right now, there's the ability to fully specify whether or not to base64-encode each part in a message, but the included simpleMail function defaults to non-encoded parts for both its HTML and plain text alternatives. This has apparently caused some issues where long HTML strings have been word-wrapped at bad locations, causing breakage in the meaning of the markup. The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients? Thanks, Michael

On 7 December 2010 13:42, Michael Snoyman
Hi all,
I've gotten a request for the mime-mail package that I'd like some input on. Right now, there's the ability to fully specify whether or not to base64-encode each part in a message, but the included simpleMail function defaults to non-encoded parts for both its HTML and plain text alternatives. This has apparently caused some issues where long HTML strings have been word-wrapped at bad locations, causing breakage in the meaning of the markup.
The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients?
What does the wrapping here? My understanding of the symptom is that newlines are sometimes inserted between the < and / of a closing HTML tag, breaking the tag and leaving stray markup in the file. Would it be possible to either not do the wrapping, or to avoid putting newlines inside a tag? Conrad.

On Mon, Dec 6, 2010 at 8:42 PM, Michael Snoyman
The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients?
The way I've seen it done before was to: - calculate the size of the body in quoted-printable and base64 encoding - select the smaller encoded form of the two quoted-printable is fairly human readable. This strategy also works for encoding headers, particularly Subject: lines (substituting q-encoding for qp). -n

On Mon, 6 Dec 2010 22:21:35 -0800, Nathan Howell
On Mon, Dec 6, 2010 at 8:42 PM, Michael Snoyman
wrote: The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients?
The way I've seen it done before was to: - calculate the size of the body in quoted-printable and base64 encoding - select the smaller encoded form of the two
quoted-printable is fairly human readable. This strategy also works for encoding headers, particularly Subject: lines (substituting q-encoding for qp).
I would prefer quoted-printable as well, at least for the text alternative. -- Nicolas Pouillard http://nicolaspouillard.fr

On Tue, Dec 7, 2010 at 8:21 AM, Nathan Howell
On Mon, Dec 6, 2010 at 8:42 PM, Michael Snoyman
wrote: The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients?
The way I've seen it done before was to: - calculate the size of the body in quoted-printable and base64 encoding - select the smaller encoded form of the two
quoted-printable is fairly human readable. This strategy also works for encoding headers, particularly Subject: lines (substituting q-encoding for qp).
Seems like quoted-printable *is* the correct answer here. I've implemented both that and encoded-word for headers, and the code seems to work just fine. Of course, testing by everyone else is always welcome; the code is in my github repo[1]. Now I have some design questions for everyone: * There does not appear to be a way to encode MIME header *keys*, so it's entirely possible that mime-mail will generate invalid messages. Is this something to worry about? It basically means the user shot him/herself in the foot by putting non-ASCII data in the key, but even so it feels wrong that the type system isn't helping us at all here. * Internally the header values all get converted to Text values for processing. Does it make sense to just make all the records in the Mail and Part datatypes use Text instead of String? Especially given OverloadedStrings it should not hurt usability too much, and in theory will help performance a bit. Since I have breaking changes in the API from a previous commit, the new version will be mime-mail 0.1.0. As long as we're breaking things, does anyone have anything else they'd like to throw in? Michael [1] https://github.com/snoyberg/mime-mail

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/7/10 01:21 , Nathan Howell wrote:
The way I've seen it done before was to: - calculate the size of the body in quoted-printable and base64 encoding - select the smaller encoded form of the two
quoted-printable is fairly human readable. This strategy also works for encoding headers, particularly Subject: lines (substituting q-encoding for qp).
"Quoted-Printable: a standard for mangling Internet messages Quoted-Unreadable: the result of applying said standard Unquoted-Unprintable: the comments from the recipients of the above" (me, in alt.sysadmin.recovery. I'm not sure how someone converted "Brandon S Allbery KF8NH" into "bf8" but that's the universal attribution.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+87kACgkQIn7hlCsL25U+FQCgzV+47Rl5KB7ZreKMyRx4kDhb 6kMAmgJy8TW0omQyDuSMp5oaYOctnSDh =Si8I -----END PGP SIGNATURE-----
participants (5)
-
Brandon S Allbery KF8NH
-
Conrad Parker
-
Michael Snoyman
-
Nathan Howell
-
Nicolas Pouillard