Email address

From Wikipedia, the free encyclopedia
  (Redirected from E-mail address)
Jump to: navigation, search

An email address identifies an email box to which email messages are delivered. An example format of an email address is lewis@example.net which is read as lewis at example dot net. Many earlier email systems used different address formats.

Contents

[edit] Overview

Transport of email across the Internet uses the Simple Mail Transfer Protocol (SMTP), which is defined in Internet standards RFC 5321 and RFC 5322, while mailboxes are most often accessed with the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP).

Email addresses, such as jsmith@gmail.com, have two parts. The part before the @ sign is the local-part of the address, often the username of the recipient (jsmith), and the part after the @ sign is a domain name to which the email message will be sent (gmail.com).

An SMTP server looks up the domain name using the Domain Name System, which is a distributed database. A server queries the DNS for any mail exchanger records (MX records) to find the host name of a designated mail transfer agent (MTA) for that address. That way, the organization holding the delegation for a given domain —the mailbox provider— can define which are the target hosts for all email destined to its domain. The mail exchanger does not need to be located in the domain of the destination mail box, it must simply accept mail for the domain. The target hosts are configured with a mechanism to deliver mail to all destination mail boxes. The local-part of an address, is defined to be opaque to intermediate mail relay systems except the final mailbox host. For example, it must not be assumed to be case-insensitive.

Multiple email addresses may point to the same mailbox. Conversely, a single email address may be an alias and have a distribution function to many mailboxes. Email aliases, electronic mailing lists, sub-addressing, and catch-all addresses, the latter being mailboxes that receive messages irrespectively of the local part, are common patterns for achieving such results.

The addresses found in the header fields of an email message are not the ones used by SMTP servers to deliver the message. Servers use the so-called message envelope to route mail. While envelope and header addresses may be equal, forged email 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 information: Email authentication, Anti-spam techniques

To indicate whom 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 <john.smith@example.com>.

Earlier forms of email 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.

[edit] Syntax

The format of email addresses is formally defined in RFC 5322 (sections 3.2.3 and 3.4.1) and by RFC 5321. An email address is a string of a subset of ASCII characters (see however the internationalized addresses below) separated into 2 parts by an "@" (at sign), a "local-part" and a domain, that is, local-part@domain.

The local-part of an email address may be up to 64 characters long and the domain name may have a maximum of 253 characters. However, the maximum length of a forward or reverse path length of 256 characters restricts the entire email address to be no more than 254 characters.[1] Some mail protocols, such as X.400, may require larger objects, however. The SMTP specification recommends that software implementations impose no limits for the lengths of such objects.

The local-part of the email address may use any of these ASCII characters RFC 5322 Section 3.2.3:

Additionally, quoted-strings (e.g., "John Doe"@example.com) are permitted, thus permitting characters otherwise prohibited, however this form is not commonly used. 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" (sic).

The local-part is case sensitive, therefore jsmith@example.com and JSmith@example.com specify different mailboxes. This practice is discouraged by RFC 5321, however. Only the authoritative mail servers of a domain may evaluate the distinction. The only exception of this rule is for a local-part value of "postmaster" which is case-insensitive, and should be forwarded to the server's administrator.

Within the rules set out in the RFCs, organizations are free to restrict the forms of their own email addresses as desired, e.g., many organizations do not use certain characters (space, ?, and ^) and most organizations treat uppercase and lowercase letters as equivalent. Windows Live Hotmail, for example, only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).[2]

Systems that send mail must be capable of handling outgoing mail for all addresses. Contrary to the relevant standards, some defective systems treat certain legitimate addresses as invalid and fail to handle mail to these addresses. Hotmail, for example, refuses to send mail to any address containing any of the following standards-permissible characters: ! # $ % * / ? ^ ` { | } ~

The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, consisting of letters, digits, hyphens and dots. In addition, the domain part may be an IP address literal, surrounded by square braces, such as jsmith@[192.168.2.1], although this is rarely seen except in email spam.

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 3696 errata.

[edit] Invalid email addresses

[edit] Common local-part semantics

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.". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.

[edit] Local-part normalization

Interpretation of the local-part of an email address is dependent on the conventions and policies implemented in the mail server. For example, case-sensitivity may distinguish mailboxes differing only in capitalization of characters of the local-part, although this is not very common.[3] GMail (Google Mail) ignores all dots in the local-part for the purposes of determining account identity.[4] This prevents the creation of user accounts your.user.name or yourusername when the account your.username already exists.

[edit] Address tags

Some mail services allow a user to append a tag to his email address (e.g., joeuser+tag@example.com). The text of tag may be used to apply filtering and to create single-use addresses.[5][6][7] However, some mail servers 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 (+). On the other hand, most installations of the qmail and Courier Mail Server products support the use of a hyphen '-' as a separator within the local-part, such as joeuser-tag@example.com or joeuser-tag-sub-anything-else@example.com. This allows qmail through .qmail-default or .qmail-tag-sub-anything-else files to sort, filter, forward, or run an application based on the tagging system established. It is also quite common for web forms to either refuse to accept the plus sign as a part or the username or to even misbehave in an undetermined manner[citation needed]. Disposable email addresses of this form, using various separators between the base name and the tag are supported by several email services, including Runbox (plus and hyphen), Google Mail (plus),[8] Yahoo! Mail Plus (hyphen),[9] Apple's MobileMe (plus), FastMail.FM (plus and Subdomain Addressing),[10] and MMDF (equals). The name sub-addressing is the generic term (used for plus-addressing and hyphen-addressing) found in some IETF standards-track documents, such as RFC 5233.

[edit] Validation

Not only are email addresses used in a mail client or on a mail server, but also used in websites where a user-supplied email address is often validated.

An email address is generally recognized as having two parts joined with an at-sign (@); this in itself is a basic form of validation. However, the technical specification detailed in RFC 822 and subsequent RFCs go far beyond this, offering very complex and strict restrictions.[11]

Trying to match these restrictions is a complex task, often resulting in long regular expressions.[12]

This means that many mail servers adopt very relaxed validation that allows and handles email addresses that are disallowed according to the RFC and instead verify the email address against relevant systems such as DNS for the domain part or using callback verification to check if the mailbox exists.[13]

Conversely, many websites check email addresses much more strictly than the standard specifies, rejecting addresses containing valid characters like + or / signs, or setting arbitrary length limitations (e.g., 30 characters). RFC 3696 was written to give specific advice for validating internet identifiers, including email addresses.[14]

[edit] Internationalization

The IETF conducts a technical and standards working group devoted to internationalization issues of email addresses, entitled Email Address Internationalization (EAI, also known as IMA - Internationalized Email Address).[15] This group has published the informational 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. Experimental RFC 5335 describes internationalized email headers, including a UTF8-based address specification. The list of valid examples below is thus expected to undergo significant additions.

The basic EAI concepts involve exchanging mail in UTF-8. Though the original proposal included a downgrading mechanisms for legacy systems this has now been dropped.[16] The local servers are responsible for the "local" part of the address, whereas the domain portion would be restricted by the rules of internationalized domain names, though still transmitted in UTF-8. The mail server is also responsible for any mapping mechanism between the IMA form and any ASCII alias.

When EAI is standardized, users will likely have a localized address in a native language script or character set, as well as an ASCII form for communicating with legacy systems or for script-independent use. Applications that recognize internationalized domain names and mail addresses must have facilities to convert these representations.

[edit] Internationalization Examples

These addresses are not compliant with RFC 5322 and will therefore not work with many of the current generation of email servers and clients.

[edit] See also

[edit] References

  1. ^ RFC 5321, section 4.5.3.1. Size Limits and Minimums explicitly details protocol limits.
  2. ^ The character limitation is written in plain English in the subscription page "Sign up for Windows Live". https://signup.live.com/newuser.aspx?mkt=en-us. Retrieved 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.
  3. ^ Are Email Addresses Case Sensitive? by Heinz Tschabitscher
  4. ^ Google Mail - help center article
  5. ^ "Instant disposable Gmail addresses" by Gina Trapani 2005
  6. ^ 'E-mail with a "Plus"' by Jim Leous 2005
  7. ^ "Gmail: how to use 'plus' sign for filtering mails"
  8. ^ Using an address alias
  9. ^ help.yahoo.com
  10. ^ FastMail's subdomain addressing
  11. ^ I Knew How To Validate An Email Address Until I Read The RFC
  12. ^ Mail::RFC822::Address
  13. ^ SMTP based check to verify existence of a mailbox
  14. ^ RFC 3696
  15. ^ "Eai Status Pages". Email Address Internationalization (Active WG). IETF. http://tools.ietf.org/wg/eai/. Retrieved 2008-07-26. 
  16. ^ "Email Address Internationalization (eai)". IETF. http://datatracker.ietf.org/wg/eai/charter/. Retrieved 2010-11-30. 

[edit] External links

The Wikibook Coding Cookbook has a page on the topic of
The Wikibook JavaScript has a page on the topic of
Retrieved from "http://en.wikipedia.org/wiki/Email_address"
Personal tools
Namespaces
Variants
Actions
Navigation
Interaction
Toolbox
Print/export
Languages