I cut this section, then User:IanM restored it. I'm cutting it again because it still has many errors. I don't object to something like this being in the article, but it should be correct.
None of the listed activities require an e-mail address. Most online retailers and some web sites require you to have an e-mail address in order to sign up for their services. But some retailers and most web sites don't. For example, you don't need an e-mail address to edit Wikipedia. So this needs to be rewritten with specifics. How exactly not having an e-mail address disadvantage a person? Which governments are untaking which initiatives? Gdr 10:20, 2004 Jul 9 (UTC)
Maybe "Making online purchases..." should be replaced with "In many cases making online purchases..."? Paul Carpenter 14:59, 23 Apr 2005 (UTC)
Insightful and informative (a few things a geek like me didn't know, also). Keep. -- Primetime 20:54, 19 January 2006 (UTC)
Keep. Email addresses are different to Email itself, in that this article discusses the actual address. You can't combine that with email.
Under "Invalid email addresses" it says
But http://tools.ietf.org/html/rfc3696 says
For example Abc\@def@example.com is a valid form of an email address. Blank spaces may also appear, as in Fred\ Bloggs@example.com The backslash character may also be used to quote itself, e.g., Joe.\\Blow@example.com
So is the article right or not?
This article currently doesn't explain the complexity of email addresses, in that they may take many forms, many of which would not be recognized as valid email addresses by the average internet user. As evidenced by the EBNF for email addresss (I may have missed some as I copy-pasted from RFC 2822 the parts I could find that were needed):
address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list address-list = (address *("," address)) / obs-addr-list addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair dtext = NO-WS-CTL / ; Non white space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; characters not including "[", ; "]", or "\" FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space obs-FWS ctext = NO-WS-CTL / ; Non white space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-126 ; ")", or "\" ccontent = ctext / quoted-pair / comment comment = "(" *([FWS] ccontent) [FWS] ")" CFWS = *([FWS] comment) (([FWS] comment) / FWS) NO-WS-CTL = %d1-8 / ; US-ASCII control characters %d11 / ; that do not include the %d12 / ; carriage return, line feed, %d14-31 / ; and white space characters %d127 specials = "(" / ")" / ; Special characters used in "<" / ">" / ; other parts of the syntax "[" / "]" / ":" / ";" / "@" / "\" / "," / "." / DQUOTE quoted-pair = ("\" text) / obs-qp text = %d1-9 / ; Characters excluding CR and LF %d11 / %d12 / %d14-127 / obs-text atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]
this is a much better example of a email regex patern http://nikic.github.io/2012/06/15/The-true-power-of-regular-expressions.html — Preceding unsigned comment added by 84.55.110.220 ( talk) 15:32, 5 March 2015 (UTC)
And the following regex for validating emails, from Perl's RFC2822 package:
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*)
porges 01:27, 4 April 2006 (UTC)
The following was found at the end of the "plus (or minus) addressing" section:
I couldn't figure out who originally added it. It looks more like a (poorly formatted) general comment than anything that belongs in the article, so I've moved it here in case anyone would like to discuss it. Pat 16:51, 26 May 2006 (UTC)
The Phrase "Through technical misuse of the word" should be removed. It is such a common usage that it could be said to be another meaning of the wordin it's own right.
The following is incorrect. The link is not RFC 2822 compliant because the input box only allows for up to 90 characters.
Verify email address: Verify the syntax & format, the domain name, a valid user and actual mailbox. (RFC 2822 compliant online free tool).
Similar to above, the last reference linked, "e-mail address validation: a Regular Expression that validates e-email addresses according to RFC 2822", is incorrect. It attempts to validate email addresses, but does not do so in accordance with RFC 2822. IMO, it's considerably further from RFC 2822 than most other examples I have seen and should be removed entirely. RevEng (James Cooper) 18:41, 17 January 2007 (UTC)
Is there a polite way to convince people to allow email addresses with plus signs, as required by the appropriate standards since 1982?
You could threaten to list them on the "plus haters page of shame".
This section of the article should be updated to explain how plus signs can be used to track down spammers and sellers of email addresses. 147.145.40.44 18:47, 25 January 2007 (UTC)
The plus haters page is nice. I suppose a registration is needed to be able to modify the page. I would be very tempted to create a wiki page here with a similar listing. Would that be acceptable? Products are compared with their features. It is a similar approach, isn't it? Patriiiiiiiiiick ( talk) 12:47, 29 March 2017 (UTC)
Some email clients—such as Google Mail’s web interface—writes out emails as "Full Name" <user@server.tld>. However this is an outdated method of adding comments to the name part. So the email standard says the address should be written as Full Name <user@server.tld>. Can anyone explain the difference of the two, and elaborate on why many choose to comment out the name using outdated standards? —Preceding unsigned comment added by 84.202.43.102 ( talk) 22:38, 10 January 2008 (UTC)
Would be useful if those able to translate a page into a language didn't have to read through the entire Wikipedia site in order to do so, wouldn't it? The language of my choice is not on the left pane list and the word languages is not clickable. Is all of wikipedia of this mindset? (no tilde on this keyboard, sorry, send money for new one!) — Preceding unsigned comment added by 213.244.194.207 ( talk) 00:55, 27 April 2008 (UTC)
Would be nice for someone to find a list of government e-mail-for-all initiatives or more of the cultural stuff, rather than just adding to the technical details. — Preceding unsigned comment added by IanM ( talk • contribs) 20:53, 12 August 2003 (UTC)
A note vis-a-vis allowed characters - despite me accidentally adding a period to the excluded characters list, the rest are from the RFC, so should be correct. If you see different it's because the standard is being broken. — Preceding unsigned comment added by IanM ( talk • contribs) 21:03, 12 August 2003 (UTC)
Otherwise , these comments may be deleted
Sanjiv swarup ( talk) 03:36, 8 June 2008 (UTC)
I think the section discussing validation should be merged with the limitations section as they both go hand in hand. -- Hm2k ( talk) 12:06, 6 June 2008 (UTC)
Kalivd ( talk) 14:46, 7 June 2008 (UTC)
Also the See Also section has only one link i would like to add a few more See Also links for easy navigation to other e-mail related articles. Kalivd ( talk) 14:46, 7 June 2008 (UTC)
"Actually trying to send email" is NOT a validation technique, it is a verification technique.
Validation is a check to ensure it is true to the specification (eg: is the number N digits long?). Not to be confused with verification which is a check to ensure it is correct within the intended system (eg: does the number work when phoned?). -- Hm2k ( talk) 09:27, 14 June 2008 (UTC)
I corrected the missing hyphenation in the spelling of “e-mail” in this article. A section in it said I was to comment here if I edited it. Why is this necessary and only for that section? Greta Hoostal ( talk) 02:21, 18 July 2008 (UTC)
Can someone explain why we're using contractions and first person in this article? Ten Pound Hammer and his otters • ( Broken clamshells • Otter chirps • HELP) 17:33, 17 October 2008 (UTC)
This article confuses validating an email from the point of an user with from the point of "how it must be structured inside the MIME". For example, it is perfectly ok for a mail client to accept [Full Name full.name@domain.dm] as a valid email as long as the email client can interpret the name part (Full Name) from the mailbox part (full.name@domain.dn)]. When the email client creates the corresponding mime it must use the syntax described in the RFCs. Microsoft Outlook does this, for example.
Another example of this is the usage of unicode characters on the name part. There are special mechanisms for encoding those characters in the MIME yet the users of a mail client do not need to know about them, and will only type the characters directly.
"€" <euro@europe.eu>
Any user will say that we are looking at a valid email address yet the corresponding utf-8 byte sequence is not a valid MIME address:
"%d226%d130%d172" <euro@europe.eu>
In a mime a correct ASCII sequence for the previous address may be:
=?windows-1252?Q?=22=80=22?= <euro@europe.eu>
Yet no one will try to explain this to a user. Another important thing to note for developers is that, due to this problem, a regular expression directly taken from the RFCs is not of any practical use, at least in an international point of view. This is because the regular expression will fail to parse any address that contains an unicode character. Such a regular expression may only be useful for parsing addresses directly from the MIME.
Developers of email clients should create a different regular expression to parse user inputed text, extract the relevant parts and convert the parsed address into the RFC format.
I think it is important, from an encyclopedia point of view, to differentiate the two topics.
From an encyclopedic view it suffices to exaplain that an email address is an electronic address used to deliver internet messages to an entity. This address is composed off an optional entity name and an entity mailbox. The mailbox is composed of an user part and an host part. The way this entities are encoded in MIME is irrelevant to the concept. Typically, similarly to physical addresses, this entity is a person and in such situations an email address is composed of of that person's name and a his mailbox.
However, the typical address format accepted by email clients should be documented, but not as if it was the RFC format itself. —Preceding unsigned comment added by João Graça da Nóbrega ( talk • contribs) 17:30, 9 January 2009 (UTC)
Where do you get the part of the restrictions? According to the RFC I cannot determine such limitations as dots are not allowed at begin of the local part, but still it is listed as a restriction? Can somebody point me to the right direction here or remove the restrictions from the section? If dots are not allowed at end or at beginning of the local part, it should be considered to explain this with and according to the RFC. SilverSurger ( talk) 08:51, 2 March 2010 (UTC)
In RFC:
[1]
local-part = dot-atom / quoted-string / obs-local-part
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
obs-local-part = word *("." word)
In dot-atom-text and obs-local-part it says a "atext" or a "word" comes first then other "atext"s and "word"s come after a ".". shAt ( talk) 06:34, 28 April 2014 (UTC)
But dots in any combination are allowed in quoted-string, and a quoted-string is allowed anywhere in local-part. The "/" in the grammar above means "or". The restriction on dots only makes sense in the context of unquoted text, where it's already obvious from the BNF grammar. The statement about consecutive dots appears to be lifted verbatim from RFC 3696, but that statement is discussing unquoted text. It's a misreading to interpret that statement as applying to the quoted strings of a local-part component. So, for example, "abc..123"@example.com is valid, but abc..123@example.com is not valid. — Preceding unsigned comment added by 38.99.63.178 ( talk) 23:02, 2 August 2016 (UTC)
Links to a non existing page. Should be removed. —Preceding unsigned comment added by 142.142.113.67 ( talk) 18:23, 28 July 2010 (UTC)
Reference 11 is also incredibly misleading. I suggest removing Outlook.com from the list of services that do this altogether. I am wiki-ignorant, otherwise I'd edit. Microsoft allows you to create individual aliases that link to a primary Live/Outlook.com account. Not ad-hoc usage of plus-tagging. — Preceding
unsigned comment added by
65.249.12.2 (
talk)
23:30, 23 June 2015 (UTC)
This sentence - "An SMTP server looks up the domain name using the Domain Name System" - is unclear (at least to me). I assume it means that when an SMTP server wants to *send* an email.... But that's not clear. Can I suggest that someone clarify this point? Omc ( talk) 18:31, 22 January 2011 (UTC)
From "Local part": "The restrictions for special characters are that they must be contained between quotation marks and that 3 special chars (The space, backslash \ and quotation mark " (ASCII: 32, 92, 34) must be preceded by a backslash \ (e.g. "\"\\\ ")." And in the linked webpage < http://tools.ietf.org/html/rfc3696> I read: "Blank spaces may also appear, as in
Fred\ Bloggs@example.com"
and "In addition to quoting using the backslash character, conventional double-quote characters may be used to surround strings. For example ... "Fred Bloggs"@example.com
are alternate forms of the first two examples above." Contradiction or not? Who is right? -- BuSchu ( talk) 14:26, 2 January 2012 (UTC)
Thanks! If I had read the line to the end ... ;-) -- BuSchu ( talk) 15:39, 2 January 2012 (UTC)
In RFC it called "quoted-pair":
quoted-pair = ("\" text) / obs-qp
obs-qp = "\" (%d0-127)
And it is allowed in these contents:
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]
qcontent = qtext / quoted-pair
shAt ( talk) 10:24, 23 April 2014 (UTC)
I've built a simple php validator (just been tinkering with the html) in order to test the examples. I've also read the rfc's but the php regex is spot on, so perfect for testing. I've purposefully made it totally plain and utterly non commercial. it contains no adverts, banners, links to anything etc. etc. The php source is shown on the page (and of course the html is available to anyone who wants to look at it). It's free and asks nothing. The site it is hosted on is currently redundant (this is the only script (index.php)) so I get no passing trade etc. etc.
Because of this, I was wondering if anyone would mind it being posted in the external links?
Review it yourself at
http://netw3rld.com (please don't over react to this link).
fredgandt
17:55, 2 January 2012 (UTC)
As far as I know, the following addresses are equivalent:
address@example.com "address(comment)"@example.com
Can someone explain in the article these possibilities? -- BuSchu ( talk) 17:13, 3 January 2012 (UTC)
comments are allowed with parentheses at either end of a quoted local-part; e.g. "john.smith"(comment)@example.com and (comment)"john.smith"@example.com are both equivalent to "john.smith"@example.com.
quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] local-part = dot-atom / quoted-string / obs-local-part
Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:11, 23 February 2020 (UTC)
The reason, why example
"(),:;<>[\]@example.com
is not correct, is wrong in my eyes: The true reason is the missing domain part: It starts with a quotation mark, and therefore all characters are legal, but the closing quotation mark is missing as is the domain part. Or am I wrong? BuSchu ( talk) 12:46, 4 January 2012 (UTC)
It says
(e.g. abc."defghi".xyz@example.com or "abcdefghixyz"@example.com are allowed. ...
are the two equivalent? That is abc."defghi".xyz = abcdefghixyz or does it = abc.defghi.xyz ? — Preceding unsigned comment added by OsamaBinLogin ( talk • contribs) 06:12, 9 March 2013 (UTC)
Elsewhere I read that this
"first..last"@iana.org
should be a correct address. But the article in mind I think this is not correct. BuSchu ( talk) 15:19, 4 January 2012 (UTC)
In the article I read
"The restrictions for special characters are that they must only be used when contained between quotation marks, and that 3 of them (The space, backslash \ and quotation mark " (ASCII: 32, 92, 34)) must also be preceded by a backslash \ (e.g. "\ \\\"")."
Where can I read in a RFC about the preceding backslash for the 3 special characters space, backslash and quotation mark? I read some RFCs but didn't find the source! BuSchu ( talk) 09:05, 8 February 2012 (UTC)
email@-domain.com
email@domain.web is valid or not
[huh?]
In the article I read
"The format of email addresses is local-part@domain where the local-part may be up to 64 characters long and the domain name may have a maximum of 253 characters – but the maximum 256 characters length of a forward or reverse path restricts the entire email address to be no more than 254 characters.[1] 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[2] and the associated errata."
Where the RFC says: "In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. Systems that handle email should be prepared to process addresses which are that long, even though they are rarely encountered."
Source: Last paragraph of RFC 3696 Section 3
Roncsak ( talk) 09:38, 24 August 2012 (UTC)
In the article, in the "Local Part" section, it lists and describes what is allowed for the part of an email that comes before the at sign (the "local" part). That list seems succinct and straight forward enough, and fairly restrictive. But then it mentions that hotmail doesn't allow users to send email to addresses which contain a list of special characters (namely, !#$%*/?^`{|}~), and says that those characters are "standards-permissible".
Nowhere in the description of what is allowed do those characters or any generalizations which might include those characters appear, as far as I can tell, so either that list of what is allowed must be missing some things, or it must be kind of unclear. Could someone add in the missing things, and/or clarify the generalization I'm misunderstanding which would include those special characters?
QuentinUK ( talk) 14:41, 14 November 2012 (UTC)
For non-roman characters, are those the only options? Would Arabic, Hangul, Hebrew, Thai, and/or Devanagari and other indic scripts also be supported? It also says "Japanese Characters", but only actually uses Chinese characters. Japanese characters also include Hiragana and Katakana. Maybe it should be renamed "Chinese Characters" or does RFC 6530 actually support those two syllabaries? Smettems ( talk) 23:57, 8 December 2012 (UTC)