E-mail address
295032
225961641
2008-07-16T05:48:46Z
Antilived
261133
remove dubious and unsourced assertion
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, <tt>jsmith@example.com</tt> and is usually read as "jsmith at example dot com". Many [[E-mail#Origin|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 standard]]s RFC 2821 and RFC 2822.
E-mail addresses, such as <tt>jsmith@example.com</tt>, 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. The hostname is looked up in the [[Domain Name System]] to find the [[mail transfer agent]] or [[MX record|Mail eXchangers]] (MXs) accepting e-mail for that address.
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 (Mail)|catch-all]] address where the local-part can be undefined and email would be delivered to a configured and existing email 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 organisation that the recipient represents, or of the recipient's [[Personal Web Site|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 [[E-mail spam|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: <code>John Smith <john.smith@example.com></code>.
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 2822 (mostly section 3.4.1) and to a lesser degree RFC 2821. An email 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, <code>local-part@domain</code>.
The "local-part" of an e-mail address can be up to 64 characters (however servers are encouraged to not limit themselves to accepting only 64 characters) and the [[domain name]] a maximum of 255 characters.
The local-part of the e-mail address may use any of these ASCII characters:
* Uppercase and lowercase letters
* Digits <code>0</code> through <code>9</code>
* Characters <code>! # $ % * / ? | ^ { } ` ~ & ' + - = _</code>
* Character <code>.</code> provided that it is not the first nor last character, nor may it appear two or more times consecutively.
Additionally, quoted-strings (ie: <code>"John Doe"@example.com</code>) are permitted, thus allowing characters that would otherwise be prohibited, however they do not appear in common practice. RFC 2821 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 "jsmith@example.com" and "JSmith@example.com" may be delivered to different people. This practice is, however, discouraged by RFC 2821.
Notwithstanding the addresses permitted by these standards, some systems impose more restrictions on email addresses, both in email addresses created on the system and in email addresses to which messages can be sent. [[Windows Live Hotmail|Hotmail]], for example, only allows creation of email addresses using alphanumerics, dot (<code>.</code>), underscore (<code>_</code>) and hyphen (<code>-</code>), and will not allow sending mail to any email address containing <code>! # $ % * / ? | ^ { } ` ~</code>. {{Fact|date=November 2007}}
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 <tt>jsmith@[192.0.2.1]</tt>, although this is rarely used in practice, except by [[spammer]]s.
The informational RFC 3696 written by the author of RFC 2821 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].
=== RFC Examples ===
'''RFC Valid e-mail addresses'''
* abc@example.com
* Abc@example.com
* aBC@example.com
* abc.123@example.com
* 1234567890@example.com
* _______@example.com
* abc+mailbox/department=shipping@example.com
* !#$%&'*+-/=?^_`.{|}~@example.com (all of these characters are allowed)
* "abc@def"@example.com (anything goes inside quotation marks)
* "Fred Bloggs"@example.com
'''RFC Invalid e-mail addresses'''
* Abc.example.com (character @ is missing)
* Abc.@example.com (character dot(.) is last in local part)
* Abc..123@example.com (character dot(.) is double)
* A@b@c@example.com (only one @ is allowed outside quotations marks)
* ()[]\;:,<>@example.com (none of the characters before the @ is allowed outside quotation marks)
== Plus (or Minus) addressing ==
According to RFC 2821 2.3.10 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 ''+tag'' to their email address (''joeuser+tag@example.com''). The text of ''tag'' can be used to apply filtering.
Some systems violate RFC 2822, 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]] installations support the use of a dash '-' 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 application based on the tagging system established.
[[Disposable e-mail address]]es of this form, using various separators between the base name and tag are supported by several email services, including [[Runbox]] (plus and minus), [[GMail|Google Mail]] (plus), [[Yahoo Mail|Yahoo! Mail Plus]] (minus)<ref>[http://help.yahoo.com/us/tutorials/cg/mail/cg_addressguard2.html help.yahoo.com]</ref>, and [[FastMail]] (plus)<ref>[http://www.fastmail.fm/docs/faqparts/Aliases.htm#SubDomain FastMail FAQ]</ref>.
== Validation ==
<!-- DO NOT CHANGE WITHOUT COMMENTING IN THE DISCUSSION SECTION -->
It's easy to forget that email addresses aren't only used on an mail client or mail server, often email 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 [[Data validation|validated]].
Most people can recognise that an email address has two parts separated by the [[at-sign]] - this in itself is a basic form of validation.
However, the technical specification detailed in RFC 822, RFC 2822, RFC 3696 goes far beyond this, offering very complex and strict restrictions. <ref>http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx</ref>
Trying to match these restrictions is an extremely difficult and complex task<ref>http://www.hm2k.com/posts/what-is-a-valid-email-address</ref>, ultimately resulting in something too long to actually be practical. <ref>http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html</ref>
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 [[Domain Name System|DNS]] for the domain part).
== References ==
{{Wikibookspar|JavaScript|Best Practices}}
{{Wikibookspar|Coding Cookbook|Validate Email Address}}
* RFC 2821: Simple Mail Transfer Protocol
* RFC 2822: Internet Message Format
* RFC 3696: Application Techniques for Checking and Transformation of Names
* RFC 2142: Mailbox names for common services, roles and functions
=== Footnotes ===
<references/>
==See also==
* [[Bounce address]]
* [[E-mail client]]
[[Category:E-mail|Address]]
[[cs:E-mailová adresa]]
[[da:E-mail-adresse]]
[[de:E-Mail-Adresse]]
[[fr:Adresse électronique]]
[[id:Alamat surat elektronik]]
[[lv:E-pasta adrese]]
[[ja:メールアドレス]]
[[pl:Adres e-mail]]
[[ru:Адрес электронной почты]]
[[sk:Elektronická adresa]]
[[wo:Màkkaanub mbëjfeppal]]