This effectively involves two tasks: 1. When we're creating a new message header and setting the default headers, first decode the subject (and maybe the addressing headers) to UTF-8 before setting the value on the property. 2. When reading the property values, first do a simple check to see if it's in UTF-8 and lacks RFC 2047 encoding and don't bother calling the converter in that case. These takes mime conversion out of the fast path and also makes it less visible to end clients. XPConnect has a noticeable overhead, so while jsmime does detect the lack of a need to do conversion, there is overhead in communicating that need, and the ACString + UTF-8 decoding in JS adds a little bit of overhead. The danger here is if you wanted to send a subject of =?UTF-8?Q?A_request_to_send_a_valid_RFC_2047_encoded_header?=--we'd do a double-decode of that most likely. Another danger is if we guess wrong on 8-bit charsets, it would be hard to rectify.