jordan-wright/email — pull request #14 by ichinaski (2014-11-19 19:57:16+00:00)
Title: 'Q' encode non US-ASCII header values(RFC 2047)

Hi @jordan-wright,

First off, many thanks for this awesome library. It is indeed quite handy!

After some usage, I have realised `email` does not support non US-ASCII headers, for example the *Subject*, *From*, and *To* ones, unless the corresponding fields are properly escaped beforehand. I believe this is a bit of a nuisance for any external application's scope, and could instead be automatically handled in `email`.

This PR includes a generic UTF-8 "Q" encoder for any *encodable* header, according to [RFC 2047](https://www.ietf.org/rfc/rfc2047.txt). *Subject* headers for instance, will be automatically encoded, if the underlying string is not pure US-ASCII:

```
UTF-8 email subject. It can contain é, ñ, or £. Long subject headers will be split in multiple lines!
```
will be encoded to

```
=?UTF-8?Q?UTF-8_email_subject._It_c?=
=?UTF-8?Q?an_contain_=C3=A9,_=C3=B1,_or_=C2=A3._Lo?=
=?UTF-8?Q?ng_subject_headers_will_be_split_in_multiple_lines!?=
```

That being said, this patch does not fix the issue when it comes to UTF-8 email addresses in the *To*, *Bcc*, *Cc*, and *From* fields, for this attributes already expect a RFC 5322 address. That is, the call to [mail.ParseAddress()](https://github.com/jordan-wright/email/blob/master/email.go#L201) will return an error if the value is UTF-8 encoded. A solution for this is to enforce external apps to use `net/mail`'s Address.String(), which accordingly escapes the name attribute if necessary:

```
addr := &mail.Address{"Iñigo", "inigo@example.com"}
e := email.NewEmail()
e.From = addr.String() // Safe to use.
e.From = "Iñigo " Here be dragons.
```

I wonder is this was indeed the usage you had in mind? Or should the library manage the encoding as well? I guess a reliably fix could be to use an `Address` struct for these fields, instead of a plain string, in order to leverage the aforementioned String() function. However, this wouldn't be backwards compatible unfortunately.

Let me know what you think about this.

Cheers,
Iñigo