# Email with Display Name

Key: `identity.person.email_display`

Email address with a display name (RFC 5322 mailbox format). Format: "Display Name" \<local@domain\> or Display Name \<local@domain\>. Commonly used in email headers and contact lists.

Page: <https://meridian.online/docs/projects/finetype/types/identity/person/email_display>

Samples: `"John Doe" <john@example.com>`, `Jane Smith <jane@corp.com>`, `"Alice B. Johnson" <alice.j@company.org>`, `Support Team <support@example.com>`

## Background

### Origin

RFC 2822, published in April 2001 under the title Internet Message Format, superseded RFC 822.[[1]](https://www.rfc-editor.org/rfc/rfc2822) RFC 5322, also titled Internet Message Format, was published in October 2008 and obsoletes RFC 2822.[[2]](https://www.rfc-editor.org/rfc/rfc5322) In its grammar, name-addr is an optional display-name followed by an angle-addr, and display-name is defined as a phrase.[[2]](https://www.rfc-editor.org/rfc/rfc5322) A phrase is made of words, and each word is either an atom or a quoted-string.[[2]](https://www.rfc-editor.org/rfc/rfc5322) The comma, the period and the double quote are among the specials, which cannot appear in an atom.[[2]](https://www.rfc-editor.org/rfc/rfc5322) RFC 5322's obsolete syntax adds the period to the phrase because it is used in many messages in the display-name portion of addresses.[[2]](https://www.rfc-editor.org/rfc/rfc5322) That is why a name with an initial, such as Alice B. Johnson, is safest written in quotes. (Meridian's view)

### Use

RFC 2047, published in November 1996, lets an encoded-word replace a word within a phrase, for example one that precedes an address in a From, To, or Cc header.[[3]](https://www.rfc-editor.org/rfc/rfc2047) An encoded-word has the form =?charset?encoding?encoded-text?=.[[3]](https://www.rfc-editor.org/rfc/rfc2047) RFC 6532, Internationalized Email Headers, published in February 2012, extends the RFC 5322 syntax to allow UTF-8 content.[[4]](https://www.rfc-editor.org/rfc/rfc6532) A display name exported straight from mail headers may therefore arrive either as raw UTF-8 or still wrapped in =?utf-8?...?= encoding, and it is worth decoding the second kind before you compare names. (Meridian's view)

Python's email.utils.parseaddr splits a value such as a To or Cc field into its realname and email address parts.[[5]](https://docs.python.org/3/library/email.utils.html) When the parse fails, parseaddr returns the 2-tuple ('', '').[[5]](https://docs.python.org/3/library/email.utils.html) Since Python 3.13, parseaddr and getaddresses take a strict parameter and reject malformed inputs by default.[[5]](https://docs.python.org/3/library/email.utils.html) The inverse, formataddr, takes a (realname, email\_address) pair and returns a string suitable for a To or Cc header.[[5]](https://docs.python.org/3/library/email.utils.html) formataddr applies RFC 2047 encoding to the realname if it contains non-ASCII characters.[[5]](https://docs.python.org/3/library/email.utils.html) Prefer a tested address parser to a hand-written regular expression, and keep the rows it rejects for review rather than dropping them. (Meridian's view)

## Sources

1. [Internet Message Format](https://www.rfc-editor.org/rfc/rfc2822) — standard
2. [Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322) — standard
3. [MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047) — standard
4. [Internationalized Email Headers](https://www.rfc-editor.org/rfc/rfc6532) — standard
5. [email.utils: Miscellaneous utilities — Python 3.15.0 documentation](https://docs.python.org/3/library/email.utils.html) — documentation