International/unicode text in mail headers #33

Pike opened this Issue Jun 9, 2012 · 13 comments


None yet
2 participants

Pike commented Jun 9, 2012

From my limited testing, emailjs doesn't do any quoted-printable escaping for mail headers that are non US-ASCII, right?

I'd have code to grab from my utterly complex multi-daemon setup that I'd like to replace with emailjs at


eleith commented Jun 10, 2012

correct. this feature sounds useful. is this mainly for non-ascii in the subject line?

are you interested in submitting a patch? it seems pretty simple enough though.

however, is there a way to avoid the 'maybeQuoted' function? we could just make it explicit...

Pike commented Jun 10, 2012

This affects all headers, that is, subject, and the email addresses. Where international domain names need different escaping, alas, punycode. See also

The maybeQuoted function is there to make plain US-ASCII headers just stay as is, which I personally prefer. There are also tools that don't deal with quoted-printable well, like postini spam report messages.

Re writing a patch, I was hoping I could get away ... :-) . I'm just rewriting the rest of the tool that I have to send emails, so I'd probably only get to that afterwards.


eleith commented Jun 10, 2012

ok, i'll look into integrating it on a separate branch if you'll test it out.

i just want to consider all the different ways this can be done

  1. user could manually format their headers in quoted-printable format before passing it into emailjs
  2. user could add the headers and somehow indicate the encoding, this would trigger a quoted-printable function
  3. emailjs integrates maybeQuoted and quotedPrintable and runs them on every header added to the message

any other options to consider?

Pike commented Jun 10, 2012

I wouldn't know more options.

From my scenario, I'd favor option 3. I'd also consider the whole 7 bit stuff an artifact of the SMTP protocol that users shouldn't need to know about, really.


eleith commented Jun 10, 2012

to/from/bcc/cc will accept a string or an array of strings

haven't tested it, but integrated the functions from the file you linked to earlier. this is just a first stab at it to see if it integrates smoothly.

i'll want to do more cleaning/integrating/making-more-explicit before i consider moving into master

Pike commented Jun 21, 2012

Sorry for not getting back to you sooner. I finally got around to test this, and it worked fine for the most part.

I just found a spacing issue when putting the emails back together,


Pike commented Jun 29, 2012

I ran into some issues with multiple addresses and escapes, I'm going to dive in to reproduce


eleith commented Jun 29, 2012

ok. i'll wait for your feedback and then address it and the spacing issue you reported earlier sometime next week


eleith commented Jul 2, 2012


spacing should be preserved. let me know what additional problems you find.


eleith commented Aug 3, 2012


Pike commented Sep 3, 2012

I tried to add tests to your branch, and realized that my perception wasn't really correct. Turns out that mail headers use something related to quoted-printable, q-encoded. Doh. I found that because the tests use mailreader, which uses mimelib, which, oh, right, has functions to encode stuff, too.

So I created a branch that uses mimelib, otherwise it's really close to the code you had.

I'm not yet 100% happy with the code, I'm pondering to encode single words only.

Also, would you be OK with changing the transfer encoding to be utf-8 8 bit instead of 7bit?


eleith commented Oct 14, 2012

utf-8 sounds good to me.

eleith closed this Apr 6, 2014


eleith commented Apr 7, 2014

went ahead and resolved this by using mimelib quoted-printable function

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment