Initially, this was just brought over from Review Board, but I plan to be expanding this function in a future change to handle some encoding issues for some headers.
formataddr has some usage warts (having to pass a tuple instead of using actual parameters), but its biggest problem is that if passed Unicode strings, it returns Unicode strings. Shouldn't be an issue, except that the underlying e-mail message code won't handle this correctly.
That code wants to be able to deal with Unicode strings, but it also wants proper e-mail addresses (like Full Name <user@example.com>). The result of formataddr((u'Christián Hammönd', u'<chipx86@example.com>')) will be u'Christián Hammönd <chipx86@example.com>', which will turn into =?utf-8?b?Q2hyaXN0acOhbiBIYW1tw7ZuZCA8Y2hpcHg4NkBleGFtcGxlLmNvbT4=?= in an e-mail message instead of the more correct =?utf-8?q?Christi=C3=A1n_Hamm=C3=B6nd?= <chipx86@example.com>.
Django tries to work around this by going through our recipients (To/BCC/CC, in our case), deserializing, parsing the address, properly serializing each component, and then using those values. That only works for those fields, however. We don't have this for others.
While it doesn't appear to strictly be a requirement for other headers, it does make it harder to read/debug headers when in a fully-encoded form. We should be doing the same thing with Sender, X-Sender, Reply-To, In-Reply-To, etc. One of the approaches I'm looking at is to add an optional parameter to build_email_address and friends for returning a properly-encoded e-mail address for use in a header.
I'm also going to be rolling up another change into this one that reverses the parameter orders (email and then full_name) as preparation for that other work, so that one could make a call along the lines of build_email_address(some_email, encode_for_header=True)