E-mail address

An e-mail address identifies a location to which e-mail messages can be delivered. An e-mail address on the modern Internet looks like, for example, [e-mail] and is usually read as "jsmith at example dot com". Many earlier e-mail systems had different formats for e-mail addresses and because modern e-mail systems are partially based on, and compatible with these older systems, the exact format of an e-mail address is complicated and frequently misunderstood.

Overview

Most e-mail on the internet uses the Simple Mail Transfer Protocol (SMTP), which is defined in the internet standards RFC 5321 and RFC 5322.

E-mail addresses, such as [e-mail], have two parts. The part before the @ sign is the local-part of the address, often the username of the recipient, and the part after the @ sign is the domain which is a hostname where the e-mail will be sent. Roughly speaking, the hostname is looked up in the Domain Name System to find the mail transfer agent or Mail eXchangers (MXs) accepting e-mail for that address.

The domain may have semantic meaning for any mail-system handling the address; the meaning is well-defined and changes to meaning involve changing every mail-server in existence. The local-part, by contrast, is supposed to be opaque to every mail-system except the system which is authoritative for the domain. This is what makes e-mail a federated system.

When a host receives an e-mail, it will be delivered to an e-mail mailbox. Some hosts allow more than one e-mail address to be sent to the same mailbox via an e-mail alias or even allow a catch-all address where the local-part can be undefined and e-mail would be delivered to a configured and existing e-mail address.

Often, the domain of an e-mail address is that of an e-mail service, such as Google's Gmail, Microsoft's Hotmail, etc. The domain can also be the domain name of the organization that the recipient represents, or of the recipient's personal site.

Addresses found in the header fields of e-mail should not be considered authoritative, because SMTP has no generally-required mechanisms for authentication. Forged e-mail addresses are often seen in spam, phishing, and many other internet-based scams; this has led to several initiatives which aim to make such forgeries easier to spot. Further|E-mail authentication, Anti-spam techniques (e-mail)

To indicate who the message is intended for, a user can use the "display name" of the recipient followed by the address specification surrounded by angled brackets, for example: John Smith .

Earlier forms of e-mail addresses included the somewhat verbose notation required by X.400, and the UUCP "bang path" notation, in which the address was given in the form of a sequence of computers through which the message should be relayed. This was widely used for several years, but was superseded by the generally more convenient SMTP form.

RFC specification

E-mail addresses are formally defined in RFC 5322 (mostly section 3.4.1) and to a lesser degree RFC 5321. An e-mail address is a string of a subset of ASCII characters separated into 2 parts by an "@" (at sign), a "local-part" and a domain, that is, local-part@domain.

The "local-part" of an e-mail address can be up to 64 characters and the domain name a maximum of 255 characters. Clients may attempt to use larger objects, but they must be prepared for the server to reject them if they cannot be handled by it. [RFC 5321, section 4.5.3.1. "Size Limits and Minimums" explicitly details protocol limits.]

The local-part of the e-mail address may use any of these ASCII characters:

* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 through 9
* Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
* Character . provided that it is not the first nor last character, nor may it appear two or more times consecutively.

Additionally, quoted-strings (ie: "John Doe"@example.com) are permitted, thus allowing characters that would otherwise be prohibited, however they do not appear in common practice. RFC 5321 also warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form".

The local-part is case sensitive, so "[e-mail]" and "[e-mail]" may be delivered to different people. This practice is, however, discouraged by RFC 5321. However, only the authoritative mail-servers for a domain may make that decision.

Notwithstanding the addresses permitted by these standards, some systems impose more restrictions on e-mail addresses, both in e-mail addresses created on the system and in e-mail addresses to which messages can be sent. Hotmail, for example, only allows creation of e-mail addresses using alphanumerics, dot (.), underscore (_) and hyphen (-), and will not allow sending mail to any e-mail address containing ! # $ % * / ? | ^ { } ` ~ [The character limitation is written in plain English in the subscription page cite web |url=https://signup.live.com/newuser.aspx?mkt=en-us |title=Sign up for Windows Live |accessdate=2008-07-26 . However, the phrase is hidden, thus one has to either check the availability of an invalid ID, e.g. "me#1", or resort to alternative displaying, e.g. "no-style" or source view, in order to read it.] .The domain name is much more restricted, as they must match the requirements for a hostname, basically letters, digits, hyphens and dots. In addition, the domain may be an IP address literal, surrounded by square braces, such as jsmith@ [192.0.2.1] , although this is rarely used in practice, except by spammers.

The informational RFC 3696 written by the author of RFC 5321 explains the details in a readable way, with a few minor errors noted in the [http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3696 3696 errata] .

Email Address Internationalization

Email Address Internationalization is an IETF working group devoted to internationalization issues in email addresses [cite web |url=http://tools.ietf.org/wg/eai/ |title=Eai Status Pages |accessdate=2008-07-26 |work=Email Address Internationalization (Active WG) |publisher=IETF] . The only published RFC to date is RFC 4952, envisioning "changes to the mail header environment to permit the full range of Unicode characters" and "an SMTP Extension to permit UTF-8 mail addressing", among other things. The list of valid examples below is thus expected to undergo significant additions.

RFC examples

RFC Valid e-mail addresses
* [e-mail]
* [e-mail]
* [e-mail]
* [e-mail]
* [e-mail]
* [e-mail]
* abc+mailbox/department=[e-mail]
* !#$%&'*+-/=?^_`.{~@example.com (all of these characters are allowed)
* "abc@def"@example.com (anything goes inside quotation marks)
* "Fred "quota" Bloggs"@example.com (however, quotes need escaping)

RFC invalid e-mail addresses
* Abc.example.com (character @ is missing)
* [e-mail] (character dot(.) is last in local part)
* [e-mail] (character dot(.) is double)
* A@b@[e-mail] (only one @ is allowed outside quotations marks)
* () [] ;:,<>@example.com (none of the characters before the @ is allowed outside quotation marks)

Sub-addressing (aka plus-addressing, minus-addressing)

According to RFC 5321 2.3.11 "Mailbox and Address," "...the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.".

Plus addressing is one of the benefits of this limitation. Some mail services allow a user to append a "+tag" qualifier to their e-mail address (e.g., "[e-mail]"). The text of "tag" can be used to apply filtering.

Some systems violate RFC 5322, and the recommendations in RFC 3696, by refusing to send mail addressed to a user on another system merely because the local-part of the address contains the plus sign (+). Users of these systems cannot use plus addressing.

On the other hand, most qmail and courier installations support the use of a dash '-' as a separator within the local-part, such as "[e-mail]" or "[e-mail]". This allows qmail through ".qmail-default" or ".qmail-tag-sub-anything-else" files to sort, filter, forward, or run application based on the tagging system established.

Disposable e-mail addresses of this form, using various separators between the base name and tag are supported by several e-mail services, including Runbox (plus and minus), Google Mail (plus), Yahoo! Mail Plus (minus) [ [http://help.yahoo.com/us/tutorials/cg/mail/cg_addressguard2.html help.yahoo.com] ] , and FastMail (plus) [ [http://www.fastmail.fm/docs/faqparts/Aliases.htm#SubDomain FastMail FAQ] ] .

The name sub-addressing is the generic term, used in some IETF standards-track documents, such as RFC 5233.

Local-part normalization

Any mail-domain is free to ascribe any meaning to the local-parts within that domain. Sub-addressing is fairly common, case-insensitivity is extremely common (but not universal).

Another fairly unusual example of normalizing a local-part to an account-name is provided by Google Mail, which ignores all dots in the local-part for the purposes of determining account identity. See the first item in [http://mail.google.com/support/bin/answer.py?answer=10313&topic=14822 the help-center article] . So if one person creates the account your.username then nobody else can create the accounts your.user.name or yourusername and those addresses all belong to the one account.

In short, a remote mail-server or administrator can make no assumptions about the meaning of another site's local-parts, but a given site is has complete authority to do as they think best within their own domain.

Validation

It's easy to forget that e-mail addresses aren't only used on a mail client or mail server, often e-mail addresses are seen to be used outside of this system. Thus, when using an e-mail address in another system (such as a website), the user data (entered via an online form) must be validated.

An e-mail address is generally recognised as being two parts separated by the at-sign, this in itself is a basic form of validation. However, the technical specification detailed in RFC 822, and subsequent RFCs goes far beyond this, offering very complex and strict restrictions. [ [http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx I Knew How To Validate An Email Address Until I Read The RFC ] ]

Trying to match these restrictions is an extremely difficult and complex task [ [http://www.hm2k.com/posts/what-is-a-valid-email-address HM2K.com » What is a valid email address? ] ] , often resulting in long regular expressions that is too hard to actually be practical. [ [http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html Mail::RFC822::Address ] ] RFC 2822 introduced the notion of "obsolete syntax" (reinforced by the subsequent RFC 5322) in an attempt to explicitly define the gap between the more liberal syntax that a server is willing to accept and interpret and the more conservative one that it is committed to generate. An application of Postel's Law.

Practicality plays a major role once you discover that many mail servers have very relaxed validation, that allow and handle e-mail addresses that are disallowed according to the RFC. Because of this, we are forced to take a different approach, adopting relaxed validation and instead verifying the e-mail address and its various parts against the relevant systems (such as DNS for the domain part).

References

* RFC 5321: Simple Mail Transfer Protocol
* RFC 5322: Internet Message Format
* RFC 3696: Application Techniques for Checking and Transformation of Names
* RFC 2142: Mailbox names for common services, roles and functions

Footnotes

ee also

* Bounce address
* E-mail client