notebooks/test.txt

+
+Syntax
+
+The format of email addresses is local-part@domain where the local part may be up to 64 characters long and the domain may have a maximum of 255 characters.[4] The formal definitions are in RFC 5322 (sections 3.2.3 and 3.4.1) and RFC 5321—with a more readable form given in the informational RFC 3696[5] and the associated errata. Note that unlike the syntax of RFC 1034,[6] and RFC 1035[7] there is no trailing period in the domain name.
+Local-part
+
+The local-part of the email address may use any of these ASCII characters:
+
+    uppercase and lowercase Latin letters A to Z and a to z;
+    digits 0 to 9;
+    printable characters others than letters and digit !#$%&'*+-/=?^_`{|}~;
+
+    dot ., provided that it is not the first or last character unless quoted, and provided also that it does not appear consecutively unless quoted (e.g. John..Doe@example.com is not allowed but "John..Doe"@example.com is allowed);[8]
+
+Note that some mail servers wildcard local parts, typically the characters following a plus and less often the characters following a minus, so fred+bah@domain and fred+foo@domain might end up in the same inbox as fred+@domain or even as fred@domain. This can be useful for tagging emails for sorting, see below, and for spam control. Braces { and } are also used in that fashion, although less often.
+
+    space and special characters "(),:;<>@[\] are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash);
+    comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com.
+
+In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict which characters to use when assigning local-parts.
+
+A local part is either a Dot-string or a Quoted-string; it cannot be a combination. Quoted strings and characters however, are not commonly used.[citation needed] 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 postmaster is treated specially—it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore jsmith@example.com and JSmith@example.com specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent. Indeed, RFC 5321 warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where ... the Local-part is case-sensitive".
+
+Despite the wide range of special characters which are technically valid, organisations, mail services, mail servers and mail clients in practice often do not accept all of them. For example, Windows Live Hotmail only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).[9] Common advice is to avoid using some special characters to avoid the risk of rejected emails.[10]
+Domain
+
+The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, a list of dot-separated DNS labels, each label being limited to a length of 63 characters and consisting of:[8]:§2
+
+    uppercase and lowercase Latin letters A to Z and a to z;
+    digits 0 to 9, provided that top-level domain names are not all-numeric;
+    hyphen -, provided that it is not the first or last character.
+
+This rule is known as the LDH rule (letters, digits, hyphen). In addition, the domain may be an IP address literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in email spam. Internationalized domain names (which are encoded to comply with the requirements for a hostname) allow for presentation of non-ASCII domains. In mail systems compliant with RFC 6531 and RFC 6532 an email address may be encoded as UTF-8, both a local-part as well as a domain name.
+
+Comments are allowed in the domain as well as in the local-part; for example, john.smith@(comment)example.com and john.smith@example.com(comment) are equivalent to john.smith@example.com.
+Examples
+
+Valid email addresses
+    simple@example.com
+    very.common@example.com
+    disposable.style.email.with+symbol@example.com
+    other.email-with-hyphen@example.com
+    fully-qualified-domain@example.com
+    user.name+tag+sorting@example.com (may go to user.name@example.com inbox depending on mail server)
+    x@example.com (one-letter local-part)
+    example-indeed@strange-example.com
+    admin@mailserver1 (local domain name with no TLD, although ICANN highly discourages dotless email addresses)
+    example@s.example (see the List of Internet top-level domains)
+    " "@example.org (space between the quotes)
+    "john..doe"@example.org (quoted double dot)
+
+Invalid email addresses
+    Abc.example.com (no @ character)
+    A@b@c@example.com (only one @ is allowed outside quotation marks)
+    a"b(c)d,e:f;g<h>i[j\k]l@example.com (none of the special characters in this local-part are allowed outside quotation marks)
+    just"not"right@example.com (quoted strings must be dot separated or the only element making up the local-part)
+    this is"not\allowed@example.com (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
+    this\ still\"not\\allowed@example.com (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
+    1234567890123456789012345678901234567890123456789012345678901234+x@example.com (local part is longer than 64 characters)
+
+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 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.
+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.[11] Gmail ignores all dots in the local-part for the purposes of determining account identity.[12] This prevents the creation of user accounts your.user.name or yourusername when the account your.username already exists.
+Subaddressing
+
+Some mail services support a tag included in the local-part, such that the address is an alias to a prefix of the local part. For example, the address joeuser+tag@example.com denotes the same delivery address as joeuser@example.com. RFC 5233, refers to this convention as sub-addressing, but it is also known as plus addressing or tagged addressing.
+
+Addresses of this form, using various separators between the base name and the tag, are supported by several email services, including Runbox (plus), Gmail (plus),[13] Rackspace Email (plus), Yahoo! Mail Plus (hyphen),[14] Apple's iCloud (plus), Outlook.com (plus),[15] ProtonMail (plus),[16] FastMail (plus and Subdomain Addressing),[17] MMDF (equals), Qmail and Courier Mail Server (hyphen).[18][19] Postfix allows configuring an arbitrary separator from the legal character set.[20]
+
+The text of the tag may be used to apply filtering,[18] or to create single-use, or disposable email addresses.[21]
+
+In practice, the form validation of some web sites may reject special characters such as "+" in an email address – treating them, incorrectly, as invalid characters. This can lead to an incorrect user receiving an e-mail if the "+" is silently stripped by a website without any warning or error messages. For example, an email intended for the user-entered email address foo+bar@example.com could be incorrectly sent to foobar@example.com. In other cases a poor user experience can occur if some parts of a site, such as a user registration page, allow the "+" character whilst other parts, such as a page for unsubscribing from a site's mailing list, do not.