MeridianMERIDIAN

Email Address

identity.person.email

Standard email address (RFC 5322 simplified). Format: local@domain. Universal format but may include internationalized domain names (IDN).

Worked samples

DuckDB 1.5.5 · finetype 0.6.64

ValueAs VARCHARdomainlocal
john.smith@example.comjohn.smith@example.comexample.comjohn.smith
user+tag@domain.orguser+tag@domain.orgdomain.orguser+tag
test123@company.co.uktest123@company.co.ukcompany.co.uktest123
Personal data
Yes — treat as PII

Shape

Length 5 to 254 characters.

Pattern
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$
ValueLengthShape
john.smith@example.com22matches
user+tag@domain.org19matches
test123@company.co.uk21matches

Told apart

Going the other way, this type's own rule accepts 2 of 3 samples of Password.

Background

Origin

RFC 5322, Internet Message Format, published in October 2008, defines the syntax of an address specification, or addr-spec.[1] RFC 5322 obsoletes RFC 2822.[1] RFC 5322 describes an addr-spec as a locally interpreted string followed by the at-sign character, followed by an Internet domain.[1] The local-part may be written as a dot-atom or as a quoted-string, and the dot-atom form should be used whenever the string can be represented that way.[1]

RFC 5321, the Simple Mail Transfer Protocol, sets the maximum length of a local-part at 64 octets.[2] RFC 5321 sets the maximum length of a domain name at 255 octets.[2] A verified erratum to RFC 3696 says the upper limit on address lengths should normally be considered to be 254.[3] The erratum explains that the 256-octet path limit includes the angle brackets, which leaves 254 characters for the address itself.[3]

RFC 6531, published in February 2012, specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses.[4] The extension is announced with the EHLO keyword SMTPUTF8.[4] RFC 6532 allows use of Unicode in mail addresses and most header field content.[5]

Use

The HTML Standard defines its own valid email address syntax for form inputs.[6] The HTML Standard calls that definition a willful violation of RFC 5322.[6] Its stated reason is that the RFC 5322 syntax is too strict before the @, too vague after it, and too lax in allowing comments, whitespace and quoted strings.[6]

Many organisations treat uppercase and lowercase letters in the local-part as equivalent.[7]

Subaddressing, also known as plus addressing, tagged addressing or mail extensions, treats an address as an alias to a prefix of its local-part.[7] Gmail says that emails sent to any dotted version of a Gmail address will only go to the same account holder.[8] Gmail notes that for work, school or other organisation accounts, dots do change the address.[8] When you count unique people from an email column, decide up front whether tags after a plus sign and dots in Gmail local-parts should be folded together, and record that choice, because it changes the answer. (Meridian's view)

The Frictionless Table Schema specification gives string fields an email format, defined as a valid email address.[9]

Detection notes

v1 migration: Was person.email. Transform lowercases for canonical form. Decompose extracts local and domain parts. Pattern uses simplified RFC 5322.

Use it

CLI · DuckDB
$ finetype infer -i "john.smith@example.com" --mode column
→ identity.person.email

SELECT ft_infer('john.smith@example.com');
-- → 'identity.person.email'
Cast expression
LOWER(CAST({col} AS VARCHAR))

Schema

https://meridian.online/schemas/identity.person.email · Frictionless type string · email

finetype taxonomy identity.person.email -o json-schema

Aliases

email_address

Type Registry