Jump to content

Email address

From Wikipedia, the free encyclopedia

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

An email address, such as [email protected], is made up from a local-part, the symbol @, and a domain, which may be a domain name or an IP address enclosed in brackets. Although the standard requires the local-part to be case-sensitive,[1] it also urges that receiving hosts deliver messages in a case-independent manner,[2] e.g., that the mail system in the domain example.com treat John.Smith as equivalent to john.smith; some mail systems even treat them as equivalent to johnsmith.[3] Mail systems often limit the users' choice of name to a subset of the technically permitted characters; with the introduction of internationalized domain names, efforts are progressing to permit non-ASCII characters in email addresses.

Due to the ubiquity of email in today's world, email addresses are often used as regular usernames by many websites and services that provide a user profile or account.[4] For example, if a user wants to login to their Xbox Live video gaming profile, they would use their Microsoft account in the form of an email address as the username ID, even though the service in this case is not email.

Message transport

[edit]

An email address consists of two parts, a local-part (sometimes a user name, but not always) and a domain; if the domain is a domain name rather than an IP address then the SMTP client uses the domain name to look up the mail exchange IP address. The general format of an email address is local-part@domain, e.g. jsmith@[192.168.1.2], [email protected]. The SMTP client transmits the message to the mail exchange, which may forward it to another mail exchange until it eventually arrives at the host of the recipient's mail system.

The transmission of electronic mail from the author's computer and between mail hosts in the Internet uses the Simple Mail Transfer Protocol (SMTP), defined in RFC 5321 and 5322, and extensions such as RFC 6531. The mailboxes may be accessed and managed by applications on personal computers, mobile devices or webmail sites, using the SMTP protocol and either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP).

When transmitting email messages, mail user agents (MUAs) and mail transfer agents (MTAs) use the domain name system (DNS) to look up a Resource Record (RR) for the recipient's domain. A mail exchanger resource record (MX record) contains the name of the recipient's mailserver. In absence of an MX record, an address record (A or AAAA) directly specifies the mail host.

The local-part of an email address has no significance for intermediate mail relay systems other than the final mailbox host. Email senders and intermediate relay systems must not assume it to be case-insensitive, since the final mailbox host may or may not treat it as such. A single mailbox may receive mail for multiple email addresses, if configured by the administrator. Conversely, a single email address may be the alias to a distribution list to many mailboxes. Email aliases, electronic mailing lists, sub-addressing, and catch-all addresses, the latter being mailboxes that receive messages regardless of the local-part, are common patterns for achieving a variety of delivery goals.

The addresses found in the header fields of an email message are not directly used by mail exchanges to deliver the message. An email message also contains a message envelope that contains the information for mail routing. While envelope and header addresses may be equal, forged email addresses (also called spoofed 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 of fraudulent emails easier to spot.

https//www.youtube.com/rushe32 Embers Midi Blacker ^

Validation and verification

[edit]

Email addresses are often requested as input to website as validation of user existence. Other validation methods are available, such as cell phone number validation, postal mail validation, and fax validation.

An email address is generally recognized as having two parts joined with an at-sign (@), although technical specification detailed in RFC 822 and subsequent RFCs are more extensive.[5]

Syntactically correct, verified email addresses do not guarantee that an email box exists. Thus many mail servers use other techniques and check the mailbox existence against relevant systems such as the Domain Name System for the domain or using callback verification to check if the mailbox exists. Callback verification is an imperfect solution, as it may be disabled to avoid a directory harvest attack, or callbacks may be reported as spam and lead to listing on a DNSBL.

Several validation techniques may be utilized to validate a user email address. For example,[6]

  • Verification links: Email address validation is often accomplished for account creation on websites by sending an email to the user-provided email address with a special temporary hyperlink. On receipt, the user opens the link, immediately activating the account. Email addresses are also useful as means of delivering messages from a website, e.g., user messages, user actions, to the email inbox.
  • Formal and informal standards: RFC 3696 provides specific advice for validating Internet identifiers, including email addresses. Some websites instead attempt to evaluate the validity of email addresses through arbitrary standards, such as by rejecting addresses containing valid characters, such as and /, or enforcing arbitrary length limitations. Email address internationalization provides for a much larger range of characters than many current validation algorithms allow, such as all Unicode characters above U 0080, encoded as UTF-8.
  • Algorithmic tools: Large websites, bulk mailers and spammers require efficient tools to validate email addresses. Such tools depend upon heuristic algorithms and statistical models.[7]
  • Sender reputation: An email sender's reputation may be used to attempt to verify whether the sender is trustworthy or a potential spammer. Factors that may be incorporated into an assessment of sender reputation include the quality of past contact with or content provided by, and engagement levels of, the sender's IP address or email address.
  • Browser-based verification: HTML5 forms implemented in many browsers allow email address validation to be handled by the browser.[8]

Some companies offer services to validate an email address, often using an application programming interface, but there is no guarantee that it will provide accurate results.

Internationalization

[edit]

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 Mail Address).[9] This group produced RFC 6530, 6531, 6532 and 6533, and continues to work on additional EAI-related RFCs.

The IETF's EAI Working group published RFC 6530 "Overview and Framework for Internationalized Email", which enabled non-ASCII characters to be used in both the local-parts and domain of an email address. RFC 6530 provides for email based on the UTF-8 encoding, which permits the full repertoire of Unicode. RFC 6531 provides a mechanism for SMTP servers to negotiate transmission of the SMTPUTF8 content.

The basic EAI concepts involve exchanging mail in UTF-8. Though the original proposal included a downgrading mechanism for legacy systems, this has now been dropped.[10] The local servers are responsible for the local-part of the address, whereas the domain 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.

EAI enables users to 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.

Significant demand for such addresses is expected in China, Japan, Russia, and other markets that have large user bases in a non-Latin-based writing system.

For example, in addition to the .in top-level domain, the government of India in 2011[11] got approval for ".bharat", (from Bhārat Gaṇarājya), written in seven different scripts[12][13] for use by Gujrati, Marathi, Bangali, Tamil, Telugu, Punjabi and Urdu speakers. Indian company XgenPlus.com claims to be the world's first EAI mailbox provider,[14] and the Government of Rajasthan now supplies a free email account on domain राजस्थान.भारत for every citizen of the state.[15] A leading media house Rajasthan Patrika launched their IDN domain पत्रिका.भारत with contactable email.

The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:

See also

[edit]

References

[edit]
  1. ^ J. Klensin (October 2008). "General Syntax Principles and Transaction Model". Simple Mail Transfer Protocol. p. 15. sec. 2.4. doi:10.17487/RFC5321. RFC 5321. The local-part of a mailbox MUST BE treated as case sensitive.
  2. ^ J. Klensin (October 2008). "General Syntax Principles and Transaction Model". Simple Mail Transfer Protocol. p. 15. sec. 2.4. doi:10.17487/RFC5321. RFC 5321. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
  3. ^ "...you can add or remove the dots from a mail address without changing the actual destination address; and they'll all go to your inbox...", Google.com
  4. ^ Morrison, Sara (2021-09-06). "How a simple email address makes things complicated". Vox. Retrieved 2024-07-15.
  5. ^ "How Domino formats the sender's Internet address in outbound messages". IBM Knowledge Center. Retrieved 23 July 2019.
  6. ^ "M3AAWG Sender Best Common Practices, Version 3" (PDF). Messaging, Malware and Mobile Anti-Abuse Working Group. February 2015. Retrieved 23 July 2019.
  7. ^ Verification & Validation Techniques for Email Address Quality Assurance by Jan Hornych 2011, University of Oxford
  8. ^ "4.10 Forms — HTML5". w3.org.
  9. ^ "Eai Status Pages". Email Address Internationalization (Active WG). IETF. March 17, 2006 – March 18, 2013. Retrieved July 26, 2008.
  10. ^ "Email Address Internationalization (eai)". IETF. Retrieved November 30, 2010.
  11. ^ "2011-01-25 - Approval of Delegation of the seven top-level domains representing India in various languages". features.icann.org.
  12. ^ "Internationalized Domain Names (IDNs) | Registry.In". registry.in. Retrieved 2016-10-17.
  13. ^ "Now, get your email address in Hindi". The Economic Times. Retrieved 2016-10-17.
  14. ^ "Universal Acceptance in India". 15 February 2017.
  15. ^ "देश में पहला, प्रदेश के हर नागरिक के लिए मुफ्त ई-वॉल्ट और ई-मेल की सुविधा शुरू - वसुन्धरा राजे". वसुन्धरा राजे (in Hindi). 2017-08-18. Retrieved 2017-08-20.

Further reading

[edit]
  • RFC 821 Simple Mail Transfer Protocol (Obsoleted by RFCs 2821 and 5321)
  • RFC 822 Standard for the Format of ARPA Internet Text Messages (Obsoleted by RFC 2822) (Errata)
  • RFC 1035 Domain names, Implementation and specification (Errata)
  • RFC 1123 Requirements for Internet Hosts, Application and Support (Updated by RFC 2821, RFC 5321) (Errata)
  • RFC 2142 Mailbox Names for Common Services, Roles and Functions (Errata)
  • RFC 2821 Simple Mail Transfer Protocol (Obsoletes RFC 821, Updates RFC 1123, Obsoleted by RFC 5321) (Errata)
  • RFC 2822 Internet Message Format (Obsoletes RFC 822, Obsoleted by RFC 5322) (Errata)
  • RFC 3696 Application Techniques for Checking and Transformation of Names (Errata)
  • RFC 4291 IP Version 6 Addressing Architecture (Updated by RFC 5952) (Errata)
  • RFC 5321 Simple Mail Transfer Protocol (Obsoletes RFC 2821, Updates RFC 1123) (Errata)
  • RFC 5322 Internet Message Format (Obsoletes RFC 2822, Updated by RFC 6854) (Errata)
  • RFC 5598 Internet Mail Architecture
  • RFC 5952 A Recommendation for IPv6 Address Text Representation (Updates RFC 4291) (Errata)
  • RFC 6530 Overview and Framework for Internationalized Email (Obsoletes RFC 4952, 5504, 5825)
  • RFC 6531 SMTP Extension for Internationalized Email (Obsoletes RFC 5336)
  • RFC 6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields (Updates RFC 5322)
[edit]